I hate to get involved in this flame fest but there are a few points that
neither side of this argument seems to have stumbled across yet.

On Fri, 16 Jan 1998, Todd Vierling wrote:

> Okay, people are saying I'm missing some points; people are saying Charles
> is missing some points.  I'll weigh what I can see as advantages and
> disadvantages of both procedures.  Please, if I've missed something here,
> tell me and I will add it to the list and repost, but I'm not into the
> mudslinging, so please send flame to /dev/null.
> 
> Contiguous bits for major and minor - Advantages:
> - Cleaner coded, and becomes only a slight modification of the 16-bit system
>   if compatibility drops out
> - Can use a completely merged devsw as translation is done before use of
>   a dev_t in the kernel
> - It has overwhelming precedent
> 
> Disadvantages:
> - Requires MAKEDEV and mknod(8) be updated at the same time, or that MAKEDEV
>   be updated to use new mknod(8) flags before the change

This can be mitigated by reserving the first 256 32-bit major numbers for
compatibility devices.  mknod creates a 16-bit node for majors < 256 and
32-bit nodes for majors beyond 256.  Yes, this is ugly and creates a hole
in the device table, but splitting the minor does exactly the same thing.
And eventually this hole can be reassigned when COMPAT_DEV_13 goes away.

That way an old MAKEDEV with a new mknod works fine, and I should hope
that the old mknod with an invalid major (new MAKEDEV) should bomb.  If it
does not bomb you have a 16-bit node with truncated major and minor
numbers.  You would have the same problem if you split the minor.

> 
> Advantage or disadvantage, depending on the user:
> - ls(1) displays old device nodes with a major number of zero, the
>   reserved compatibility number

I would hope ls(1) had compatibility code to properly print 16-bit
dev_t's.

> - Requires a separate kernel option to enable compatibility, so prompts
>   users of -current to ask why a kernel doesn't boot (and receive the answer
>   of updating mknod(8) and MAKEDEV, then adding appropriate kernel option)
> - Forces us to renumber devices now and make the new numbers correspond
>   between 
> - A user who MAKEDEV's some 32 bit devices and falls back will be confused
>   as to why functionality was lost; requires MAKEDEV to have a 16-bit option
>   or default to such so devices get old node numbers
> 
> Neutral (usually "don't care"s):
> - Makes the dev_t easier to read in a debugging dump of function arguments,
>   or in a raw hexdump of a filesystem
> 
> Optional:
> - MAKEDEV, when modified, could default to creating 16 bit nodes with the
>   new mknod(8) (and the options of nmajorbits and nminorbits), allowing
>   the 32 bit representations to change before 1.4 for new functionality
> 
> =====
> 
> Splitting minor into two parts - Advantages:
> - Works on old or new MAKEDEV and mknod(8), even in different mixes
> 
> Disadvantages:
> - Does not allow for a merged, renumbered device switch table; device
>   numbers below the predefined N split of `old' and `new' are block/char
>   dependent (as well as arch dependent)
> - If compatibility left out, the remnants still exist (five operations for
>   minor number to be stripped from a dev_t, and a table of N*2 null devices)

What happens when an old, 16-bit kernel reads a new 32-bit device node?
If it silently ignores the high bits then you take the chance that your
new 32-bit device node will match and old 16-bit device and in this case
you get silent data corruption.  

> 
> Advantage or disadvantage, depending on the user:
> - ls(1) displays old and new device nodes in the same format
> - The translation heuristic might be conditional on whether or not a device
>   is renumbered, prompting an extra conditional translation layer
> - A user who MAKEDEV's some 32 bit devices and falls back will be confused
>   as to why functionality was lost; requires MAKEDEV to have a 16-bit option
>   or default to such so devices get old node numbers

[...]

So far I have not seen either side come up with a solution to the problem
of an old kernel trying to decypher a new device node.  Maybe there is
none.

=========================================================================
Eduardo Horvath				eeh@btr.com
"Cliffs are for climbing.  That's why God invented grappling hooks."
					- Benton Frasier