Re: [linux-usb] Re: USB device allocation (fwd)

Matthew Dharm (mdharm@one-eyed-alien.net)
Wed, 6 Oct 1999 14:37:19 -0700 (PDT)


This was a solution to the dynamic USB device assignment problem that I
proposed on 5 Oct 1999. I don't think it made it to the linux-kernel
list, so here it is.

In a moment, I'll sent over to linux-kernel another posting I made to
linux-usb, which addresses some of the concerns raised by another
listmember.

Matt Dharm

-- 
Matthew Dharm                                         InterNIC: MDD94
Engineer                                              Cell: (619) 890-6943
Home: mdharm@one-eyed-alien.net                       Home: (858) 689-1908
Beep: page-matt@one-eyed-alien.net                    Beep: (858) 621-8155

G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999

---------- Forwarded message ---------- Date: Tue, 5 Oct 1999 21:31:00 -0700 (PDT) From: Matthew Dharm <mdharm@one-eyed-alien.net> To: linux-usb@suse.com Subject: Re: [linux-usb] Re: USB device allocation

Hrm... a slightly different take on the problem...

It was originally proposed (that is, the proposition which really kicked this thread of discussion off) that we have a major number for USB devices, and then assign the minor numbers in blocks to different types of devices (i.e. a range for printers, a range for ACM, etc).

My understanding (and maybe I'm smoking crack here) is that there are only 127 devices allowed on a USB tree, and minor numbers go all the way up to 255. So, why not simply have devices accessed by their device number?

That is to say, the first device on a USB tree is /dev/usb0. The next is /dev/usb1. Our little user-space daemon will simply provide symbolic links between, say, /dev/mouse and /dev/usb0 (if that's proper). Minor numbers are assigned by some sensible system (i.e. first-come first-serve, or perhaps some topology based thing).

My initial look at this idea is that it might create some kind of race-condition, if the device known as /dev/usb1 suddenly became known as /dev/usb0 without anything actually happening to the device (but instead other devices around it changing). So, as long as a device, when plugged in, is given a minor number, and that number doesn't change unless _that_ _device_ is removed and re-inserted, we should be clear of race conditions. It might be necessary to add the restriction that we try to re-use minor numbers as infrequently as possible (like process ID assignment does).

A special /dev/usbinfo entry can be used to pass event data from kernel space to user space in some useful format, to drive the user-space daemon. Heck, with an entire major number, we could have hundreds of paths for information to flow from kernel space to user space, all relating to USB. Topological info, device info, descriptors, statistics, etc. could all be sent on separate minor numbers.

This solution has several advantages, as I see it:

1) It provides for low-level access to each USB device 2) It allows easy operation of high-level device names (as symlinks) 3) It leverages the existing solution (the /dev filesystem) 4) It eliminates contention for minor numbers (totally, as I see it) 5) It eliminates the need for a dynamic filesystem

#4 and #5 are the biggest gain from my point of view. This will require that USB devices which are not supposed to present a /dev entry do so, but that entry could simply return a line of text that says "Go away. We don't do char interfaces".

Comments?

Matt Dharm

-- 
Matthew Dharm                                         InterNIC: MDD94
Engineer                                              Cell: (619) 890-6943
Home: mdharm@one-eyed-alien.net                       Home: (858) 689-1908
Beep: page-matt@one-eyed-alien.net                    Beep: (858) 621-8155

It was a new hope. -- Dust Puppy User Friendly, 12/25/1998

-- 
To unsubscribe, e-mail: linux-usb-unsubscribe@suse.com
For additional commands, e-mail: linux-usb-help@suse.com

- 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/