Subject: Re: CFR: The Auto-Generation Block/Character Device Switch Tables
To: MAEKAWA Masahide <gehenna@NetBSD.org>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 05/13/2002 02:18:33
[ On Monday, May 13, 2002 at 09:20:29 (+0900), MAEKAWA Masahide wrote: ]
> Subject: Re: CFR: The Auto-Generation Block/Character Device Switch Tables
> But to construct MAKEDEV from majors list, as Darren points out, is
> easier than it. It is not trivial, too.
I would suggest not constructing MAKEDEV, but rather re-designing it and
making it data driven so that it reads the same table(s) used to build
the kernel (and maybe those can alternately/also be read from a sysctl
from within the kernel itself).
It should probably also become a script run in /etc/rc.d at boot, which
by default might report conflicts and/or missing nodes, but which could
optionally be configured to correct /dev.
Conceivably one could even add another "stage" before /etc/rc, i.e. a
script that would run before /sbin/init opens /dev/console, and the main
one we have now, i.e. /etc/rc, would then be run after /dev/console is
opened (with /dev/console still being the controlling tty for the shell
running /etc/rc). This way on some systems /dev could even be a memory
filesystem that's always newfs'ed on boot and populated by MAKEDEV so
that at least on boot it would always match the running kernel and have
the default permissions properly reset, yet for those who would like
persistence they could leave /dev on the root filesystem and switch
MAKEDEV into its "just annoy me" mode. Even with /dev in a memory
filesystem there could be a persistent minimal /dev underneath it on the
root filesystem for emergency use.
Greg A. Woods
+1 416 218-0098; <email@example.com>; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>