Re: USB device allocation

David Weinehall (tao@acc.umu.se)
Tue, 5 Oct 1999 23:45:11 +0200 (MET_DST)


On Tue, 5 Oct 1999, Martin Dalecki wrote:

> David Weinehall wrote:
> >
> > On Tue, 5 Oct 1999, H. Peter Anvin wrote:
> >
> > > Dan Hollis wrote:
> > > >
> > > > On Tue, 5 Oct 1999, Steffen Grunewald wrote:
> > > > > That's 32 entries for 16 devices...
> > > > > > 64 = /dev/usbscanner0 USB HP scanner
> > > > > > ...
> > > > > > 95 = /dev/usbscanner15
> > > > > Same here...
> > > > > > 128 = /dev/ttyACM0 USB modem
> > > > > > ...
> > > > > > 255 = /dev/ttyACM127
> > > > > What about some spare entries for USB monitors, speakers, CDrecorders ?
> > > >
> > > > The desperate need for devfs becomes all more clear.
> > > >
> > >
> > > Actually, the need is for a decent-sized dev_t.
> >
> > With a decently sized dev_t we will still have the problem with a
> > cluttered /dev directory. With devfs we won't. And if you still want your
> > standard, cluttered, /dev directory, you can still have it with devfs. So
> > I can't really understand you being so negative in regard to devfs.
>
> Inventing a dynamic fs is cluttering the way I see what a fs should be
> by far more then just having some superflous entries in /dev/

Is procfs any better in this respect?!

Oh, and have you actually ever tried a system running devfs (such as a
kernel patched with Richard Gooch' patch, or a Solaris-system), or?

Hmmm. If USB isn't enough to convince, think about USB2 (128 devices/bus
if I'm not all wrong), FireWire, FibreChannel, SCSI-III, etc. Sooner or
later we need a solution to the problem with devices. And devfs is a very
good, thought-through, proven to work (been used in Solaris for many
years) and backward-compatible solution. And it's available now.

Why create something new, when there's a good solution already?

/David Weinehall
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </

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