Нюансы драйверов USB (Windows) Опции

[Dr.Alex]

Постараюсь сразу к делу::

Есть WinDriver.
Работает так (в моём понимании):
При инициализации я задаю размер буфера для IN пакетов, он может быть хоть гигабайт.
Ядрёная (kernel) часть драйвера выгребает заданный BULK ендпойнт САМА, без пинков от медленной юзерской программы.
А когда я в юзерской программе делаю чтение, то оно происходит уже из ядрёного буфера.

Есть libusb.
Работает так (в моём понимании):
Когда я вызываю чтение, то только тогда на шине инициируется IN-транзакция. Никаких буферов нет.
Поэтому когда прога работает, а я давлю "обновить" в браузере на каком-нить тяжёлом сайте,
то чтение прекращается на сотню миллисекунд, и не слишком длинный буфер в моём устройстве переполняется.

Вопросы::
- верно ли я понимаю ситуацию?
- может быть я неправильно использую libusb?
- может быть надо использовать libusbK или ещё что? Пробовать все существующие дрова самому в облом.

Виндрайвер использовать не хочется.
Хоть он и хорошо работает, но у юзеров инсталится и деинсталится с проблемами.
Тот же libusb в этом смысле образцовый.

[gerber]

Есть WinDriver.
Работает так (в моём понимании):
При инициализации я задаю размер буфера для IN пакетов, он может быть хоть гигабайт.
Ядрёная (kernel) часть драйвера выгребает заданный BULK ендпойнт САМА, без пинков от медленной юзерской программы.
А когда я в юзерской программе делаю чтение, то оно происходит уже из ядрёного буфера.

Не так. Если бы было так, как вы описали, то при открытии чтения из юзерской программы вы бы получали данные, выгребенные из устройства полчаса назад.
При открытии чтения драйвер (или цепочка драйверов) выделяет буфера и строит цепочку дескрипторов на заявленную длину чтения (которая может быть много больше размера эндпойнта), после чего практически не участвует в чтении (разве что обрабатывает прерывания) - обработку транзакций и слив данных в буфера производит USB-контроллер аппаратно, посредством DMA-механизма, согласно цепочке дескрипторов обмена.

Есть libusb.
Работает так (в моём понимании):
Когда я вызываю чтение, то только тогда на шине инициируется IN-транзакция. Никаких буферов нет.
Поэтому когда прога работает, а я давлю "обновить" в браузере на каком-нить тяжёлом сайте,
то чтение прекращается на сотню миллисекунд, и не слишком длинный буфер в моём устройстве переполняется.

Насколько я понимаю, libusb также опирается на kernel-драйвер, только расположенный ниже по иерархии, который предоставляет generic-доступ к устройству, то есть на уровне "осуществить bulk-чтение" в размере конечной точки. Поэтому, чтобы выгрести приличный объем данных, libusb вынуждена много раз "слазить" на уровень kernel и обратно, что довольно затратно для системы, ну и другие процессы тоже могут "перебивать" эту неспешную процедуру.

[Dr.Alex]

Если бы было так, как вы описали, то при открытии чтения из юзерской программы вы бы получали данные, выгребенные из устройства полчаса назад.

В Windriver оно ровно так и происходит. Насколько хватит заданного мной буфера.

Насколько я понимаю, libusb также опирается на kernel-драйвер

Да это и эжу понятно, что какой-то кернел есть.
Вопрос в том, как быть. Может эта коряга работать так как виндрайвер или нет. И если нет, то какую корягу взять.