There are three replies here.

> From: Darren Reed <darrenr@cyber.com.au>
> 
> My perceived problem with this is how do you maintain knowledge of what the
> major/minor, owner and permissions are of those device nodes across a
> reboot ?

See current practice, e.g.:

	[wb.rc:i386] uname -s -r -m
	NetBSD 1.2G i386
	[wb.rc:i386] grep chmod /etc/rc
	chmod 666 /dev/tty[pqrs]*

> I don't expect a driver to set those itself.

Nor do I.  It's a boot time issue in ANY case, to ensure correctness.

> Otherwise, I agree that this is the right thing to do, although there still
> needs to be a split for major/minor bits, the size isn't as critical for
> major numbers (but should not be less than 8 bits).

I agree that the major and minor still have to be known.  But a 16/16 split
would be just fine if the major was incremented per probe and the minor was
incremented per device within a probe.

> From: Jason Thorpe <thorpej@nas.nasa.gov>
>
> 	(1) There are several problems with a "devfs" approach, including
> 	    non-persistence of chmod's and symlinks.

See above.

> 	(2) There are some programs out there that like to compare dev_t's
> 	    to see if e.g. file foo is on the same file system as file bar.

Everything will be consistent for any given kernel run.  That is, the only
ways the majors can change is if (a) you reboot or (b) you unload an LKM and
reload another one.  Comparing dev_t's should be fine as long as you don't
cache them anywhere (except /var/db of course, but that's reset at boot time.)

> From: "Chris G. Demetriou" <cgd@pa.dec.com>
>
> (1) there are a number of unsolved problems with approaches like this.
> e.g. "how do you keep permissions the same between boots, without
> wasting a bunch of time while booting."

Hmmm.  Your system must boot faster than mine.  For me it's about 30 to 50
seconds if the file systems are clean, most of which is in cold load time,
and the "chmod 666 /dev/tty[pqrs]*" in 1.2G takes less than 50ms of that.

> (2) some people aren't keen on being forced to waste kernel space for
> the file system and built-up data structures, when small statically
> allocated ones work just fine.

I can see the embedded systems desire here.  I don't disagree with it.  But
I've booted enough kernels that didn't match /dev's static allocations that
I feel I would have saved more time and money with the thicker approach and
that this cost trend can only continue in the future.

> (2) you can't get rid of device nodes completely no matter what you
> do, though that's mostly irrelevant.  8-)

I think that I would mount / with "nodev" if I could.  Others may disagree.
Actually if I wanted to do this today I could make /dev an MFS and run the
existing MAKEDEV at boot time.  Then remount /dev read-only and make sure
that all other file systems are mounted "nodev".  Damn.  I wish I'd thought
of this back when I ran gatekeeper.dec.com, it would have kept me out of at
least one internet security tell-all book.