On 15 Jan 1998, Charles M. Hannum wrote:

: > I integrated your suggestions on how to handle struct specinfo with zero
: > trouble, and I did *not8 use the split minor format.  Pleas tell me how this
: > screws over users?
: 
: Yes, you did so in a way that violates at least 1 standard (by adding
: another mandatory argument to mknod(8) to get new-style device nodes).

The mknod(8) change proposals are unrelated to this....

: Also, your proposal:
: 
: * makes ls(1) display bogus info for old-style device nodes, and

Um, why does it matter?  On the old ls(1) binary, 32 bit nodes will look
bogus too.  This is a ludicrous reason to make the structure of dev_t messy,
yet as far as I have seen, is the only plausible reason to use a split
minor.  Aren't we trying to avoid more cosmetic hacks vs. manageability? 

The proposal to split dev_t in three for the purpose of listing is just a
suggestion to help this cosmetic problem.

: * makes the output of major() and minor() invalid for feeding back to
: mknod(8), because it would pack them in the wrong format.

Um, why would you be taking the output of major() and minor() and feeding it
to mknod(8) and not mknod(2)?  That's broken, period.  Please tell me what
standards this would break, and why you'd ever want to do this. 

The only thing I'd see as a problem is running mknod(8) with an old MAKEDEV
script, but why would you do that when your /dev is already there?  (That's
the other cosmetic problem that changing mknod(8) attempts to help.)

: > People -- everyone reading this thread -- please take note:
: >     Yes, Virginia, I do have transparent 16 bit node compatibility.
: 
: About as transparent as a cataract.

I'm trying very hard to suppress mudslinging here.

I was explaining a point I had to reexplain several times today.  As far as
the kernel cares, and as far as userland cares compiling out of the box, the
16 bit nodes work just like any other nodes--they just have `major' number
zero in the fs, and a whole slew of minor numbers.  `What breaks here?'

I have not yet changed mknod(8) or ls(1) (except to try out a three part
split on ls).  I'm just trying to address the cosmetic issues, which at the
base, aren't even problems.  Restructuring dev_t as you proposed just adds
marginal readability at the cost of kernel cruft and additional
compatibility issues. 

=====
===== 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