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
Richard Gooch wrote:
>
> 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.
>

devfs is based on a completely bogus idea: that a device driver is a
kernel thing. *THIS* is the supreme fallacy, and a major pitfall for
Linux today. devfs in fact helps perpetualize this problem, in large
part by moving policy into the kernel that has no business being there.
It's the DOS way of fixing things -- quick, dirty, and extremely
short-sighted.

-hpa

--
"The user's computer downloads the ActiveX code and simulates a 'Blue
Screen' crash, a generally benign event most users are familiar with
and that would not necessarily arouse suspicions."
-- Security exploit description on http://www.zks.net/p3/how.asp

-
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.074 / U:8.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site