USB 드라이버 read 구현 시 Internal Retry Loop vs Short Read 반환에 대한 설계 조언 부탁드립니다.
General Discussion
1
Posts
1
Posters
45
Views
1
Watching
-
안녕하세요, 리눅스 커널 기반의 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를 강제해야 하는 이유가 있나요?
조언 부탁드립니다. 감사합니다!