On Thu, Mar 21, 2002 at 12:55:19AM +0100, Oliver Neukum wrote: > On Thursday 21 March 2002 00:22, Greg KH wrote: > > On Wed, Mar 20, 2002 at 11:17:25PM +0100, Oliver Neukum wrote: > > > > What ones? I can't think of any right off the top of my head. > > > > > > ioctls for getting complex information. > > > > read() works fine for getting complex information too :) > > One kind of complex information. V4L with read instead of ioctl > would be horrible.
It could be done, but yes, it would be messy. > > > This does look like yet another filesystem. > > > > It is another filesystem. If you look in /proc/filesystems, you will > > see lots of them. They are multiplying! > > Without any planing or forethought. It's procfs all over again. ??? pcihpfs is well planned. So are all of the different filesystems that are now present. They do one thing, and one thing only. Much unlike procfs. That's why driverfs was not implemented within procfs. > > > We need some centralised point for doing > > > device configuration. > > > > That's what userspace tools are for :) > > Nope. There's no sanity found if you need half a dozen > filesystem with strange failure modes if one happens to be mounted > on a different place or with strange permissions. > We need unification. There's nothing hotplug specific > about node<->device correspondence. It belongs > in driverfs. We need to get rid of special cases. Wait, node<->device correspondence is currently done in /dev and has nothing to do with driverfs. driverfs is to represent the devices in the kernel, and show their hierarchy to allow power management to be implemented sanely. Now you can get rid of a /dev node altogether, which is what I did with pcihpfs (hey look, there's a free major/minor number, anyone else want it?) and some people talk about every individual device being a separate filesystem (which could get a bit messy, but would work). But I don't see how you can put the node<->device mapping into driverfs, it does not fit into that model (think a usb-serial device that only has 1 usb interface with 3 endpoints, yet binds to 16 minor numbers.) However, the /sbin/hotplug interface can be used... But that's an argument for a later time, after some more design work is done :) thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
