Linux Kernel Meet

const

Hello,

I'm a computer science undergraduate student studying Linux kernel USB device drivers.

While analyzing the skel_read() function in usb-skeleton.c, I noticed what seems like inconsistent retry logic. I'd appreciate your insights.

Current Behavior Analysis

The skeleton code operates as follows:

retry:
    if (dev->ongoing_read) {
        // Check O_NONBLOCK and wait
        if (file->f_flags & O_NONBLOCK)
            return -EAGAIN;
        wait_event_interruptible(dev->bulk_in_wait, (!dev->ongoing_read));
    }
    
    // Copy data
    chunk = min(available, count);
    copy_to_user(buffer, dev->bulk_in_buffer, chunk);
    
    // When data is insufficient
    if (available < count) {
        usb_do_read_io(dev, count - chunk);
        // No goto retry here!
    }
    return chunk;

The Inconsistency

On entry: Waits for ongoing_read (or returns -EAGAIN if O_NONBLOCK)
When data < count: Submits URB but returns immediately without waiting

These two behaviors seem inconsistent.

Proposed Modification

if (available < count) {
    usb_do_read_io(dev, count - chunk);
    goto retry;  // <- Add this
}

This would:

Handle O_NONBLOCK consistently at the retry label
Attempt to fulfill the requested count in blocking I/O mode
Allow signal interruption via wait_event_interruptible

Questions

Is the current behavior intentional, or is it simplified for educational purposes?
Am I missing any negative side effects of adding goto retry?
Is there a USB Bulk transfer characteristic that requires enforcing Short Reads?

I appreciate any advice. Thank you!

const

안녕하세요, 리눅스 커널 기반의 USB 디바이스 드라이버를 공부하고 있는 컴퓨터 공학과 학부생입니다.

현재 usb-skeleton.c의 skel_read() 함수 동작을 분석하던 중,
retry 로직에 일관성 없는 부분을 발견하여 조언을 구합니다.

현재 동작 분석

스켈레톤 코드는 다음과 같이 동작합니다:

retry:
    if (dev->ongoing_read) {
        // O_NONBLOCK 체크 후 대기
        if (file->f_flags & O_NONBLOCK)
            return -EAGAIN;
        wait_event_interruptible(dev->bulk_in_wait, (!dev->ongoing_read));
    }
    
    // 데이터 복사
    chunk = min(available, count);
    copy_to_user(buffer, dev->bulk_in_buffer, chunk);
    
    // 데이터 부족 시
    if (available < count) {
        usb_do_read_io(dev, count - chunk);
        // 여기서 goto retry가 없음!
    }
    return chunk;

의문점

처음 진입 시: ongoing_read가 있으면 대기 (또는 -EAGAIN 반환)
데이터 부족 시: URB 제출 후 대기 없이 즉시 반환

이 두 동작이 일관성이 없어 보입니다.

제안하는 수정

if (available < count) {
    usb_do_read_io(dev, count - chunk);
    goto retry;  // <- 추가
}

이렇게 하면:

O_NONBLOCK 처리가 retry 레이블에서 일관되게 처리됨
Blocking I/O 시 요청한 count를 최대한 채우려 시도
wait_event_interruptible로 시그널 인터럽트 가능

질문

현재 동작이 의도적인 설계인가요, 아니면 교육용 단순화인가요?
goto retry 추가 시 제가 놓치고 있는 문제가 있을까요?
USB Bulk transfer 특성상 Short Read를 강제해야 하는 이유가 있나요?

조언 부탁드립니다. 감사합니다!