Messages in this thread | | | Date | Tue, 5 Oct 1999 17:45:01 -0400 | From | Johannes Erdfelt <> | Subject | Re: USB device allocation |
| |
On Tue, Oct 05, 1999, Brian Swetland <swetland@be.com> wrote: > [Jeff Noxon <jeff@planetfall.com>] > > On Tue, Oct 05, 1999 at 01:54:24PM -0700, Dan Hollis wrote: > > > My /dev takes 107kbyte on disk (2,245 entries!), this is even just a small > > > fraction of devices. > > > > This may sound like flamebait or ignorance, but here goes: Why can't > > USB devices just show up dynamically under /proc/usb/dev/ or something > > like that? Are traditional device nodes really necessary? > > Wait! Why couldn't all devices just show up dynamically? You'd only > see the devices that were actually on the system (at that moment). Wait, > somebody already made this work! Ye gods, the anarchy. > > Why should a usb zip drive, parallel zip drive, or scsi zip drive be > different to access? They all speak the same protocol. You don't have > a different driver for a scsi disk on a buslogic controller and a scsi > disk on an adaptec controller, do you?
Neither do you with USB. It uses the same SCSI disk driver. Perhaps I'm missing your reference?
For all of the "standard devices" (this is vaguley defined) it uses one of the standard device nodes. In the case of USB zip drives, etc it shows up as the next sd* device.
This is good (consistent) but bad since the device naming is dependant on order of plugging the device in.
This will not work for USB. devfs (as it stands right now) won't work for USB either. However, making the appropriate changes to devfs CAN make it work.
To use standard device nodes would require something similar but with a mess of kernel code (no one likes that) or creative moving around of device nodes on the disk.
Since the in kernel solution will probably never be accepted into the kernel, a daemon is most likely solution.
I'd like to see devfs in the role since it exists already and does much of the work that is needed already.
I guess it's time to grab devfs and seriously look at what can be done to do this.
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/
| |