[Libusbx-devel] [libusb] Clarification of LibusbK windows driver architecture.

[Pradeepa Senanayake]

Hello all,

Thank you for all the explanations. So all in all the summary would be,

Eventhough ReadFile and WriteFile can communicate with any endpoint for
Bulk USB transfers it would not be of a significant advantage because
ReadFile/WriteFile will always use the drivers global buffering scheme.

And,

Since the current driver architecture is stable there is no point of
changing the DevicoIoControls to their subsequent ReadFile or WriteFile
counterparts.

And,

The way the kernel is handling both IOCTLs and the ReadFile/WriteFile
requests are almost the same. But then why different functions?

Thank you,
Best regards,
Pradeepa Senanayake.

The idea was to pass "EPx" extensions to CreateFile. IE: <device
path>\EP01. These handles could then be used with ReadFile/WriteFile for
a particular endpoint set.

That could be done, yes. The old Microsoft DDK sample "bulkusb" works
this way.

There should be less overhead associate with ReadFile/WriteFile because
they do not pass a "libusb_request" structure. Since we have an EP
specific handle, the driver knows exactly what to do with these request
whereas a DeviceIoControl could be anything hence the need for a
"libusb_request" structure.

Well, I hope you can appreciate that this is an insignificant
difference. The driver still has to create an URB and wrap an IRP
around it. The difference is that it will look up the endpoint handle
in a file object context structure, instead of looking in a table of
endpoint numbers.
I do agree that it seems somehow prettier to use ReadFile to read from a
pipe, but I'm not sure that's really a good enough reason to change
things at this point. Right now, the Windows model matches the Linux
usbfs model, which uses ioctls for everything.

All that said, this functionality was never fully implemented into
libusbK. If these request have to be "buffered" (as Tim stated) then we
just lost any advantage ReadFile/WriteFile might have gained us anyways.

The driver can choose "buffered" vs "direct" at initialization time; the
difference is that all ReadFile and WriteFile calls will use the
driver's global scheme. With an ioctl, you get to specify the buffering
in the ioctl code.
--
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------

Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
libusb-devel mailing list
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Tim Roberts]

Post by Pradeepa Senanayake
The way the kernel is handling both IOCTLs and the ReadFile/WriteFile
requests are almost the same. But then why different functions?

Partly, tradition and history. The five original Unix primitives were
open, read, write, ioctl, and close, and most operating systems since
then have kept those primitives.

On Windows, ReadFile and WriteFile get additional handling when the
device is actually a file system. For example, both of them maintain a
"current position", which DeviceIoControl does not do. That difference
doesn't matter when there isn't a real file behind the handle.