Нюансы драйверов 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-драйвер

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

[Olej]

Может эта коряга работать так как виндрайвер или нет. И если нет, то какую корягу взять.

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

P.S. И чуть-чуть по поводу терминологии...
libusb - это серьёзно проработанный и массово используемый проект. Поэтому вряд ли к нему применим термин "коряга".
А "коряга" - это что-то такое, что вы будете писать, возможно используя libusb, а возможно и нет

[Dr.Alex]

libusb именно и сделан как юзерспейс подсистема, полностью выносящая обслуживание USB устройств из ядра (kernel часть реализуется внутри libusb, а внаружу торчит только юзерспейс). И сделано это так, чтобы не зависеть от операционной системы где это используется (т.е. именно скрыть детали kernel особенностей).

Рыбята, давайте так.
Кто знает по теме ещё меньше меня — не пишите сюда, ладно?
Не надо мне втирать тут банальшину, тем более ложную.