Subject: Re: 32 bit dev_t, Revision 2
To: Todd Vierling <tv@NetBSD.ORG>
From: Chris G. Demetriou <email@example.com>
Date: 01/11/1998 17:12:49
> : 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,
> 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
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.