On Wed, Mar 20, 2002, Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Mar 20, 2002 at 12:55:34PM -0800, David Brownell wrote: > > > > > Ah, I didn't know that. Unfortunately, not all USB drivers have an > > > > > /proc/ interface like CPiA. > > > > > > > > Ok, sorry for jumping in late here, but no ioctl(). I hate the current > > > > usbfs ioctl interface and do not want to see that spread at all. usbfs > > > > could (and will) change to be representation of the usb tree in which no > > > > ioctls are needed. > > > > That'd be API-incompatible, so it's 2.5+ issue. > > Agreed. Just to be clear, I'm not talking about dropping support for > the existing ioctl usbfs interface, just creating a new one without > ioctls.
I talked to someone about this and you can't do everything. Things like control and bulk transfers map relatively easily. But there's other things too. Like resetting endpoints, clearing halts, resetting devices, choosing which alternate setting. Some of these can be done creatively. Alternate settings could be just a symlink. For those things which don't map easily, perhaps we can do some stuff still as ioctl's, resetting endpoints and clearing halts for instance. I'm not against this, but I'd like to see a real virtual driver filesystem. Changing stuff from ioctl to read()/write() will just make my life harder, since I'll have to code it into libusb. Most people wouldn't notice a change. > > The problem with saying "I hate that ioctl interface" is that there are > > still operations that don't map reasonably to read/write/seek. > > What ones? I can't think of any right off the top of my head. How would you map isochronous onto a read/write interface? > > Folk would benefit from being able to bind/unbind drivers from > > interfaces (viz that recent VMWare note, and there are other cases > > too). > > Agreed. The pencam userspace program has this problem right now with > the video kernel driver being bound to the device. I'd love a solution > for that right now, so much that I'd be willing to add a new ioctl :) I thought someone wrote an ioctl to unbind drivers once? > > Taking a new approach to usbfs might be productive, but that > > might make it look more like a driverfs add-on ... :) > > Heh, the idea is the same (no ioctls, read and write different files), > but it would be separate from the driverfs tree probably, as it doesn't > pertain to the main driverfs issue. > > See pcihpfs in the kernel right now for an idea of what I am thinking > of. JE _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
