Messages in this thread | | | Date | Wed, 6 Oct 1999 19:31:04 -0400 | From | Johannes Erdfelt <> | Subject | Re: [linux-usb] Re: USB device allocation (fwd) |
| |
On Wed, Oct 06, 1999, Matthew Dharm <mdharm@one-eyed-alien.net> wrote: > On Wed, 6 Oct 1999, Johannes Erdfelt wrote: > > > On Wed, Oct 06, 1999, Matthew Dharm <mdharm@one-eyed-alien.net> wrote: > > > On Wed, 6 Oct 1999, David Waite wrote: > > > > > > > A number of problems though: > > > > 1. People will need to realize that they are not guaranteed that usb0 will > > > > remain usb0. If someone unplugs a hub off root with 126 devices tied to it, > > > > they will probably all get scrambled. So in the end, you need some way to > > > > make sure that if you want a certain device, you are going to get it. A > > > > Lookup-then-Check method will work, if it repeats on failure. > > > > > > The point is that nobody will directly access usb0 unless they know what > > > they're doing. People will generally use the symlink for the device. > > > Also, since the assignment will always roll upwards (like process IDs), if > > > usb0 is disconnected and a new device connected, the only way that the new > > > device will get usb0 is if _all_ other usb minor numbers are assigned. > > > That's a lot of devices, and one very paranoid case. If you have 255 > > > devices (254 attached at any one time), then you know you should be > > > careful. > > > > This sounds like an interesting solution, but I have some questions. How > > would you merge the 2 sets of ioctl's for the device. > > > > There's the set of ioctl's for the USB specific portion of it, then > > there's the set of ioctl's for the deriver specific (lp, scsi, etc). > > AFAICT, this isn't going to be easy with the current setup. > > That could be a problem. Tho that's a problem with almost all of the > discussed options for USB device allocation. > > First, are there any USB-specific ioctl's? If there are, then we need to > figure out how to handle those, regarldess of how we assign device > numbers (my method, statically, or devfs). Suggestions? The first one > that comes to mind is that the USB-specific ioctls could only operate on > /proc, or that they are given numerical assignments which are unassigned > to other ioctl's for most all devices.
This is how it operates now. /proc/bus/usb/dev has all of the USB devices. You open and use ioctl to send raw commands to the device.
The problem with it now is permissions. I want to send raw commands to my USB camera. There's no reason for a kernel driver. However, you can change permissions on /proc files and keep it persistant.
JE
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |