lkml.org 
[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Migrating to larger numbers
H. Peter Anvin writes:
> Richard Gooch wrote:
> >
> > H. Peter Anvin writes:
> > > Followup to: <199906072316.JAA05265@vindaloo.atnf.CSIRO.AU>
> > > By author: Richard Gooch <rgooch@atnf.csiro.au>
> > > In newsgroup: linux.dev.kernel
> > > > Why not? Assuming all your drivers have devfs support, you don't need
> > > > device support in your filesystems.
> > >
> > > Uh, yeah, right.
> >
> > So you disagree. But why?
>
> Because I *still* think devfs is a good implementation of a bad idea.

Well, that's answering a different question. I did say "assuming...".

But on the issue of whether devfs is a good idea or not, I strongly
disagree. Let's face it, the magic devices numbers scheme is a hack
which dates back decades, and probably would never have happened if a
decent VFS interface was implemented right from the start. There must
be a reason our good friend Ken added a devfs in Plan 9.

This business of maintaining two, three or four separate databases
(the kernel code, devices.txt, /dev and MAKEDEV) which need to be
consistent is really silly. Duplication of data has always been a bad
idea, because there inevitably develop inconsistencies.
And this ignores all the things that are so much easier, faster and
more efficient with devfs as well as things that are impossible
without it.

I know that devfs is a new way of doing things that breaks with old
Unix tradition. But breaking with tradition is not always a bad
thing. Otherwise we'd still be swinging from the trees.

Regards,

Richard....

-
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:52    [W:0.084 / U:1.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site