> : Could you explain what kernel ABIs you are preserving by this
> : mechanism? stat() already does 32 bit dev_t's, so there is no real
> : userland impact to what you are doing (no userland stuff interprets
> : dev_t numbers except for stuff like MAKEDEV which doesn't count).
> 
> Programs who find their tty by fstat()ing stdin and searching /dev for the
> tty, stat()ing each file, and comparing the dev_t.

Except, those device nodea _are different_.  I can point you to
programs that i'd like to have work, that do this kind of thing.

If you're updating your kernel to support the new-format of device
nodes, then you should soon after (as soon as you think it's safe)
update your device nodes.  That's a law of system upgrades.

For a while, while you're not sure it's safe, you might encounter a
bit of lossage with the type of program you describe, but _that's_ the
law of running -current.  8-)


> Root device "mount -u" checking (making sure /dev/???a matches the dev_t of
> the boot-time root device). 

This is done in-kernel, right?  (Checking the sources to be sure, it
seems so.)  If so, it doesn't count.


> Two examples; I'm sure there are more.

Actually, only one, that i'm not sure I buy that one as a good reason.

Care to try for more?  8-)


> : We want to be able to boot a new kernel on a machine with an old /dev,
> : but I don't see what else here is critical.
> 
> I can lift just about all of that if we determine that the first thing a
> user must do after the committed changes is re-run MAKEDEV with a new
> MAKEDEV script and mknod binary.  Without this, we have to ensure that
> binaries can do stat()-versus-fstat() checks.

"No conversion, ever."  'fstat' of your tty device should give the
real device node number, not a converted one.

> It boils down to:  if something does a fstat*() and compares it with the
> dev_t in a stat(), it'll fail if we use the old device nodes,

'see above.'


> or new
> device nodes and a binary of 1.2 or earlier (or a COMPAT_<someOS> binary
> that uses dev_t's < 32 bits).

Emulations for environments which don't support 32-bit device nodes
have to do something special, regardless of what's done in the rest of
the kernel.

Why saddle the rest of the kernel with that brokenness?


> : > 14. mknod(8) will be introduced to a new command line option to create "old" 
> : > style device nodes.
> : 
> : Why?
> 
> Netbooting older NetBSD machines, that users do not yet wish to upgrade.  I
> gave the alternative, too, of specifying nbitsmajor and nbitsminor at will.

Do nbitsmajor + nbitsminor.

Do 32-bit opaque tokens.

Don't stuff unknowable amounts of converstion code into mknod.


cgd