Todd Vierling <tv@netbsd.org> writes:

> 
> On 15 Jan 1998, Charles M. Hannum wrote:
> 
> : > - ls(1) prints devices in major-`unit'-`subunit' format (12/12/8 bits).  In
> : >   this arrangement, 16-bit device nodes show up as `0,major,minor'.
> : 
> : Of course, with my proposal, the old device numbers split correctly,
> : and this isn't a problem.  No need to teach ls(1) anything new.
> 
> No need to teach ls(1) anything if it just pulls major() and minor() from
> <sys/types.h>.  You have breakage in any case if you have ls(1) using old
> major and minor formats and new nodes... you may get correct major numbers
> with a split format, but you have wrong minor numbers anyway.

However, if you build a new ls(1), it will display the old nodes
*correctly*.  There's nothing you can do in the other direction
anyway, so talking about it at all is silly.  The point is that with
my scheme the upgrading user sees NO DIFFERENCE AT ALL.  The only
user-visible change is that a new MAKEDEV will use different device
numbers, and I doubt more than a handful of people really care about
that anyway.  *That* is transparent.

> I still have yet to see what splitting the minor number *gains us*.  We can
> go without, and still be just as transparent in compatibility.

Quite frankly, that's obviously horsesh*t.  There are several
user-visible changes, and you break very old user expectations about
how major(), minor(), mknod(8), and ls(1) work -- in addition to
almost certainly violating XPG and other standards.  I'm not sure what
definition of `transparent' you're using, but it's not in the OED.

What splitting the minor number gains us is that a user doesn't even
have to know that the change happened -- and it doesn't break what
people expect the system to do.

> Adding stuff to ls(1) and mknod(8) is just one of many ways of implementing
> larger devices in user tools.

Of course, with my proposal the only thing you have to do make new
device nodes is rebuild ls(1) and mknod(8).  (You don't even have to
modify them.)  *Everything* else (all 20 lines or less) is hidden
inside the kernel and one .h file.

> Would you rather remember the node numbers in:
> 
> brw-r-----  1 root  operator    17,0,0 May 26  1997 /dev/sd0a
> brw-r-----  1 root  operator    17,0,1 May 26  1997 /dev/sd0b
> brw-r-----  1 root  operator    17,1,0 May 26  1997 /dev/sd1a
> brw-r-----  1 root  operator    17,1,7 May 26  1997 /dev/sd1h
> brw-r-----  1 root  operator    17,4,2 May 26  1997 /dev/sd4c
> 
> or:
> 
> brw-r-----  1 root  operator   17,   0 May 26  1997 /dev/sd0a
> brw-r-----  1 root  operator   17,   1 May 26  1997 /dev/sd0b
> brw-r-----  1 root  operator   17, 256 May 26  1997 /dev/sd1a
> brw-r-----  1 root  operator   17, 263 May 26  1997 /dev/sd1h
> brw-r-----  1 root  operator   17,1026 May 26  1997 /dev/sd4c

So what happens to ptys?  Now ls(1) will tell me:

crw-rw-rw-  1 root  wheel    0,6,0 Jan  7 03:47 /dev/ptyp0	<- old-style
crw-rw-rw-  1 root  wheel    6,1,0 Jan  7 03:47 /dev/pty?0	<- new-style

Yes, I have a problem with that.  Both of those are bogus.  With my
proposal I'll see:

crw-rw-rw-  1 root  wheel    6,    0 Jan  7 03:47 /dev/ptyp0	<- not changed
crw-rw-rw-  1 root  wheel    6,  256 Jan  7 03:47 /dev/pty?0	<- new-style

which is just as it should be.  (I'm using `?' in place of the 17th
letter.  I don't want to get into arguments about naming; eventually
the current naming convention needs to change, but that's a separate
problem.)

There's no excuse for making the `subunit' separate.  It is, and will
always be, parsable only by the device driver.