Subject: Re: 32 bit dev_t
To: Charles M. Hannum <mycroft@MIT.EDU>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/15/1998 18:51:07
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.
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. And we don't
lose N major numbers; just one.
: > - mknod(8) will make 16-bit device nodes (or N bit device nodes, depending
: > on command line switches) if passed two numerical arguments. It will make
: > 32 bit device nodes if passed three numerical arguments in
: > `major unit subunit' format.
:
: And no need to do this. I especially wonder how many standards this
: violates.
I don't know; you're the standards guru and I'd love to know. BSDI does a
variation of this, according to Chris Torek....
: Again, you're making this more complicated than it needs to be.
How?
Adding stuff to ls(1) and mknod(8) is just one of many ways of implementing
larger devices in user tools. I proposed one way, and I've already proposed
(in the past) the "more standard" way that just accepted a major and minor
numbers that are bigger--that's more or less just a transparent upgrade.
The alternatives of splitting up the minor is, in my opinion, just an easier
mnemonic for end-users. Remember, I still don't advocate forcing the minor
number split on any of kernel--just for mknod and ls. I'm still using
major() and minor() in my test code.
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
? That's the reason for the ls/mknod split.
=====
===== 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