현재 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로 시그널 인터럽트 가능

질문

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

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