lkml.org 
[lkml]   [1999]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: USB device allocation
On Tue, 5 Oct 1999, Martin Dalecki wrote:

> Brian Swetland wrote:
> >
> > [David Weinehall <tao@acc.umu.se>]
> > > On Tue, 5 Oct 1999, H. Peter Anvin wrote:
> > > > > > 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.
> >
> > Tradition! Big 'ol arrays and clutter are obviously better than a
> > dynamic solution. Hot-plugable devices are a myth made up by people
> > who don't realize that all hardware can be detected when you compile
> > your kernel the way it should be. Config files are for people too dumb
> > to recompile things when configurations change. That's sarcasm, btw.
>
> And one should cure the disease (too short dev_t) instead of the
> symptoms
> (inventing devfs).

Using devfs isn't curing the symptoms; it's just curing another disease.
Sure, we need a larger dev_t, but devfs is something we sooner or later
need too. And I for one vote for sooner...

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

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.045 / U:2.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site