Subject: 32 bit dev_t: trash 16 bit support
To: Charles M. Hannum <email@example.com>
From: Todd Vierling <tv@NetBSD.ORG>
Date: 01/13/1998 20:45:32
: > Well, during development (I'd think switching dev_t's would warrant a letter
: > bump from `B' to `C' perhaps? :) we can expect things to bite. However, it
: > should be adequate to require those tracking -current to update /dev/MAKEDEV
: > and mknod(8) at the same time--for those going release to release, that will
: > happen automatically as both are in the base binary set.
: `Yeah, right.' Past experience shows that any time you expect users
: to do two things at once, some of them are going to forget, not read
: the directions at all, or just plain screw it up. Why have the
: support hassle when you don't need it?
That's just it--I _do_ need it. I have more-or-less given up on using
16-bit /dev node compatibility because the required hacks to do so are so
elaborate or involved that they make code _far_ less manageable.
For a rehash:
- struct as the value of dev_t may or may not follow standards, but the
macro overhead is a lot more than originally expected and just generally
is painful to live with. Strike it.
- 16 bit compatibility routines require splitting the macro system into two
separate systems for block and character special devices because the major
and minor numbers don't necessarily match in the 16-bit system. This
causes severe problems because:
- some contexts are ambiguous as to whether the device is block or
character (such as checking the minor number in a d_ioctl() call),
so the major and minor numbers may be converted incorrectly. This
would require serious code rewriting to fix, or another whole
set of use-specific minor() macros, which is frankly hideous.
- ensuring that the stat() system returns untouched dev_t values even
in the presence of checkalias() and associated goo is more than
problematic. This would also require serious code rewriting.
- this adds layers of unnecessary overhead when the goal is a merged
character and block device table; with it, that notion is totally lost.
My vote is for just saying that "if you don't do it, you lose," and someone
who builds a kernel and boots it will find out very quickly that it doesn't
work--it can't mount root read/write (with a couple exceptions, this is what
will happen). That user _should_ have an old kernel available, and will
boot that as a fallback to send the anticipated mail of "uh, why doesn't
The support problem is nowhere near the intensity of the code and
maintenance nightmare of having 16 bit dev_t support.
===== Todd Vierling (Personal firstname.lastname@example.org) =====
== "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