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" <t...@probo.com> 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, t...@probo.com > 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 > libusb-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusb-devel
------------------------------------------------------------------------------
_______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
