: > 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
this work?".... 

The support problem is nowhere near the intensity of the code and
maintenance nightmare of having 16 bit dev_t support.

=====
===== Todd Vierling (Personal tv@pobox.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