Subject: Re: 32 bit dev_t, Revision 2
To: Perry E. Metzger <firstname.lastname@example.org>
From: Todd Vierling <tv@NetBSD.ORG>
Date: 01/11/1998 16:45:22
On Sun, 11 Jan 1998, Perry E. Metzger wrote:
: As CGD has explained, we've had severe problems on things like the ARM
: port with this sort of thing, caused by structure alignments being
: different from non-structure alignments. You really want to be very
: careful about it. I suggest that this might be reasonable as a device
: for FINDING all the problems during your initial conversion of the
: kernel, but that the committed code should use a uint32.
Okay... hrm. I'll be giving some serious thought here. Perhaps I can just
"try it" after fixing only the equality tests and fsid_t conversions in vfs.
Somehow we need to address the problem of "mount -u" of the root device and
programs that do binary compares of a fstat()ed file and a stat()ed device.
: > 3. Our new dev_t will be split 12 bits major, 20 bits minor. If the top 12
: > bits are zeroes, the dev_t is an "old" device when considering conversion in
: > the kernel.
: Sounds reasonable, though where did you pick 12 and 20 from?
Well, SVR4 has 14/18, but 16384 major devices sounded a lot. (I can still
make it this, of course.) And 12 and 20 are both multiples of 4 bits, which
just seemed logical. It's a toss-up, really.
: > 5. Character and block device major numbers for a given device must match.
: > If a character device or a block device does not have a corresponding
: > counterpart, the counterpart will be unconfigured.
: > 6. When COMPAT_[09-13] is defined in the kernel, the macro major() will
: > include inlined support for an old-to-new major number conversion table (one
: > for block, and one for character). Both the major() and minor() macros will
: > retrieve only the proper set of bits from the dev_t depending on the top 12
: > bits.
: 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.
Root device "mount -u" checking (making sure /dev/???a matches the dev_t of
the boot-time root device).
Two examples; I'm sure there are more.
: 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.
: > 7. The stat interface will be bumped a version number again, introducing
: > __stat14(), __fstat14(), and __lstat14(). These will return a file's dev_t
: > unchanged, or if COMPAT_[09-13] are defined, dev_t's always converted to new
: > format using the old-to-new conversion table above. mknod(2) will not be
: > changed, and will always create device nodes with the numbers unchanged.
: Huh? stat() already has 32 bit dev_t's. I see no reason for doing this
: at all.
: > 8. The old stat interfaces, if included by a COMPAT_[09-13] option, will do
: > direct searchs of the old-to-new table above to demote new dev_t's to 16 bit
: > dev_t's.
: Why bother with this?
Again, programs that *do* care about binary comparisons of dev_t's. These
convert dev_t's to keep them consistent with open()ed special files, as with
the tty case above.
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).
So what do we do to fix it?
: > 14. mknod(8) will be introduced to a new command line option to create "old"
: > style device nodes.
Netbooting older NetBSD machines, that users do not yet wish to upgrade. I
gave the alternative, too, of specifying nbitsmajor and nbitsminor at will.
===== Todd Vierling (Personal email@example.com) =====
== "There's a myth that there is a scarcity of justice to go around, so
== that if we extend justice to 'those people,' it will somehow erode the
== quality of justice everyone else receives." -- Maria Price