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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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.
On Mar 27, 2014 12:55 AM, "Tim Roberts" <[hidden email]> wrote:
>
> Travis wrote:
> >
> > 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.
>
> --
> Tim Roberts, [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/libusb-devel


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

_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tim Roberts
Pradeepa Senanayake wrote:
>
> 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.

--
Tim Roberts, [hidden email]
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
_______________________________________________
libusbx-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Loading...