At Sat, 20 Jun 2009 21:26:47 -0400 (EDT), der Mouse
<mouse%Rodents-Montreal.ORG@localhost> wrote:
Subject: Re: FreeBSD devfs support on NetBSD 5.0
>
> I still hold that devfs is a solution looking for a problem. The only
> real benefit I've seen anyone cite to a devfs is the lack of need to
> run MAKEDEV when hot-plugging something which wasn't anticipated when
> /dev was built.
Actually the real fundamental benefit I see for devfs is the elimination
of duplication of information between the kernel's internal
configuration tables and the external MAKEDEV script. The "dynamic"
option is then an obvious extension to devfs for those systems which
have (semi-)automatic device table maintenance.
If there were, say, some way to generate the MAKEDEV script on boot from
the kernel's configuration (which could easily also employ a translation
table which would allow localization of names, etc.), then the idea of a
userland daemon which monitored a special device for new device
attach/detach events could be also easily be included in this script and
we'd have the best of all worlds.
However I think it's probably easier to build a VERY simple devfs that
is simply a live dynamic filesystem representation of the device
autoconf tree, plus (as I've posted about before) a simple meta-data
only union FS to sit above it, and then we have a more pure, direct, and
elegant implementation. /dev with "manually" created nodes is now just
a lame attempt at exporting, or rather re-creating, the kernel's
autoconf device tree as a filesystem view by using magic special files
-- let's get rid of the "manual" part the easiest way possible (i.e. by
having the kernel invent the FS representation directly) and then we
don't have to worry about any of the other weirdness. We'd still have
to preserve the special file flags for posterity and backward
compatibility, but that's OK.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgp6ZCmNqrfxj.pgp
Description: PGP signature