Hi, On Tue, Mar 19, 2002 at 10:02:22PM +0100, Nemosoft Unv. wrote: > On Tuesday 19 March 2002 07:31, Greg KH 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 would also mean all USB devices would have to implement a /proc > interface... Unless you are referring to just USB ioctls(), in which case > something USB generic could be invented.
Yes, this would be something that would "just work" for all USB devices, much like the current device representation in /proc/bus/usb/xxx works for the current usbfs implementation. > > > That, or entries in the subdirectories. "device" would, from a user > > > point of view, probably make most sense (only one place to look) > > > > Something like U: would be nice, but there are some problems, as > > detailed below. > > > > > Remember there could be multiple U: lines (does anybody know offhand of > > > a USB device that has multiple physical devices on one USB interface?) > > > > USB to serial devices do. I have a 8 port converter around here that > > only has 1 interface, yet as 8 minor numbers assigned to it. > > Okay. That's not really a problem, as long as programs are smart enough to > deal with multiple devices. Userspace sees this as 8 different devices, as it should. I don't understand where the problem is here. > > > As to the /devfs name... Could be done, but I would like to put the > > > amount of logic that is needed ina user program to a minimum, so 'old' > > > style /dev should be listed as well. > > > > Major/minor is all that is really needed. If you're using devfs you can > > manipulate devfsd to let you know that a new device has shown up, and > > what its name is. > > Agreed, it's all that is *really* needed. Yet, I do not want to put the > burden on each and every programmer to implement a whole > major-to-devicename over and over again. Sounds like a good thing for a userspace library :) Seriously, just because I name my usb tty devices /home/gregkh/usb/devices/foo/XX should not matter to the kernel. All it cares about is the major/minor pair right now. It can not know what the userspace representaion of that major/minor pair is, and it does not need to. A simple flat database lookup in perl mapping all of the numbers vs. the names in Documentation/devices.txt would sufice. > > Actually the hotplug interface is almost all you need, just add a > > major/minor number announcement and you have everything (hint, hint...) > > Well, I run neither devfsd or hotplug. That in itself isn't a problem, I > can install the necessary programs right away. But, I would not want to > implement a scheme that is dependant on external programs. > > I think we're getting a bit off-track here. It's not about new devices > showing up, it's about quering existing devices, and the relation (in this > case) between something in /proc/bus/usb and /dev. At the same time, in > case of multi-interface devices like the Philips webcams it would be very > nice if the /dev/audio for the microphone could be linked to the /dev/video > of that same camera (okay, not everybody has 6 webcams hooked up to his > system :) ) I realize that programs need to know what the device is now. But all USB devices passed through the /sbin/hotplug interface at some point in their lifetime. I was just suggesting a way to determine the major/minor pair at that moment and saving it for all future programs to use. Yes it's a bunch of work, but it's almost all userspace work (which is a good thing from my point of view :) > > > Please explain "more fundamental ID" ? "net eth2" sounds fine (or > > > perhaps, "net:eth2"). It's either something like that or a node > > > starting with a / . > > > > Yes, network devices do not have a major/minor. But they are announced > > by /sbin/hotplug so you don't really need anything added for it. > > Again, an announcement by /sbin/hotplug is not what I need. But, I can look > around at how it passes information around, might be educational. See http://linux-hotplug.sf.net/ for some very good documentation. There's also an article in the April 2002 issue of Linux Journal that goes into the hotplug subsystem in a bit more detail. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
