[ On Friday, August 25, 2000 at 23:24:19 (-0700), Greywolf wrote: ]
> Subject: Re: dynamic configuration (was Re: PR#4094)
>
> I'd like to see the drivers declare their own major numbers, possibly
> maintaining a sparse numbering scheme.

Yes....  This is, as I recall, what FreeBSD was doing at least in 2.1.8.

It wasn't very cleanly done though (it is/was a #define) and it didn't
lead to any significant elimination of duplicated information.

It still also means that third party and private driver authors must
still choose a number or request one from a central clearing house, and
even with any sparse numbering that I can imagine there's still ample
room for collisions if the central clearing house isn't used.  Even when
'config' or the compiler prevents such collisions from causing runtime
problems, they still mean that users of such drivers have to modify
their systems when updates of the kernel source or yet more third-party
drivers cause collisions.

>  It would match most closely
> what we have today, except that the driver would declare its number
> (and type) on load rather than having a big ?devsw[] compiled in.

Except for a few possible cases there's really no need for a driver to
declare its major number.  The major number is just an index into the
device table.  That's what makes a fully dynamic/virtual /dev so
appealing -- it totally eliminates any possibility of various copies of
this duplicated information from ever getting out of synchronisation.
What's tricky about it though is that it also requires the kernel to
read and write some form of secure, portable, secondary storage where it
can preserve and restore the other attributes of the device files
(i.e. so that "chown uucp /dev/tty01" works across boots, and across
boots of new kernels).

With a normal /dev what's probably best is to have a separate companion
program to "config" that will take a list of drivers and create an
ordered table (i.e. with fixed, known, indecies) that can be used by
both "config" and "MAKEDEV".  In general this program would only need to
be run when a new driver is added to the local source tree.  This would
eliminate any need for a central clearing house of major numbers, etc.,
but avoid the complications and issues that would be present if "config"
itself were to create the ordered table.

Of course this implies that "MAKEDEV" must be rewritten to be a
data-driven program (and probably written in C for not just performance
reasons, but to eliminate depenencies on other tools), and somehow this
table shared by "config" and "MAKEDEV" must be installed somewhere.
Perhaps MAKEDEV should simply extract it from the installed kernel
binary -- that's the only really safe place for it, since keeping it
anywhere else means yet another copy exists that can get out of sync and
that's exactly what I'm trying to avoid.....

Ideally "MAKEDEV" would have a fix-up mode where it would recreate /dev
in a fashion that's safer & quicker than "cd /dev; rm *; ./MAKEDEV all"
and perhaps this could be run automatically very early on after every
boot if /netbsd is newer than the m_time of "/dev" itself.  This would
imply that the only device nodes that have to have fixed major numbers
are those that would be open at the time the cleanup of /dev is done, so
perhaps /dev/console, /dev/{zero,null} (and their friends), and of
course /dev/root (which isn't yet implemented).

I think these points address all of the issues that were brought up in
the "Ideas about the cdevsw/bdevsw structs." thread in tech-kern way
back in May of last year (1999).  I'd been saving that thread in my
INBOX in hopes of responding to it with a proposal for some time now!  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>