On Sun, 11 Jan 1998, Chris G. Demetriou wrote:

: [ this was written as quickly as possible, so there may be thinkos or
: typos which appear to present an opinion that I do not hold.  that's
: what y'all get for typing back and forth to each other a lot while i
: was too busy to chime in. 8-]

I think I did the same, Chris, but I just hope that my brain is quick enough
to subconsciously hit `backspace' at the appropriate moment.  :)

: Uh, last I saw, mandated use of opaque 32-bit tokens for device
: numbers.  Isn't that true?  (I seem to recall that, but can't quote
: C&V, and don't want to pull the RFC down.) that kills at least half of
: your argument.

Well, there are always `old' NFS servers, but we still want to be able to
use `old' 16 bit devices if the appropriate compat exists, whatever the
case.  Right?

: > 1. dev_t--only when _KERNEL is defined--becomes an opaque type of the
: > definition:
: >     typedef union { u_int32_t i; } dev_t;
: 
: Please, do this while debugging, but don't commit it that way.  While
: Perry's claims about what i've said are incorrect, the spirit of them
: is correct.

I've stricken this completely, and all the extra cruft around it.  I think I
have zeroed in on the places I need to worry about equality comparisons and
dev-to-int conversions, and third party code can pretty much be checked by
third parties.  :)

: This is fine by me.  If people want more major bits, that'd be fine by
: me, too, but most of the systems I use use 12/20.
: 
: I like 20; i can easily imagine using 20 minor bits.
: 
: 8 bits to select a SCSI bus, 4 to select a target, 3 to select at LUN,
: 5 to select a parptition.  8-)

Or whatever.  Perhaps 6-bus,4-target,3-LUN,3-slice,4-part?

I've seen 16/16, 14/18, and 12/20.  I can't foresee 4096 devices in the
near future ("by the time we have more, we'll need a 64 bit dev_t").  We
could even conceivably have 10/22, but the 4-bit-alignment just Feels Right.

: First of all, this is only 4k devs, not 8k devs.

Thinko, like I said before.  8-)

: > 5. Character and block device major numbers for a given device must match.
: > If a character device or a block device does not have a corresponding
: > counterpart, the counterpart will be unconfigured.
: 
: No, not "character and device major numbers must match."  There should
: be a unified table, which character and block devices in the same
: table with a flag to tell you which types the entry supports.

Well, when the cdev-vs-bdev API is rewritten to distinguish character and
block in the function calls.  This is a transition mechanism.

: 'minor' should return the correct minor, by either:
: 	(1) returning the right bits, if it's a new device node, or
: 	(2) doing a conversion of the right bits based on the major
: 	    number, if it's an old device node.

Ah, I did not think about the minor case.  With a stub that only returns
what's passed into it for devices that have an easy conversion, right?

: file systems should compare devices e.g. for mounting purposes by
: comapring major numbers and minor numbers.

Right, it should, and I think I found all the points in the kernel that care
about this.

: *punt*  If other OSes only have 16-bit dev_t's, then their compat code
: can implement some hack.  Otherwise, leave it alone.

What about old NetBSD ?

: What uses of programs do you think this will cause problems for?

Shells.  write(1).  talk(1).
Frankly, anything that calls ttyname() or the OS equivalent, in one of two
cases:

- an OS with 16 bit dev_t's, or old NetBSD (static?) binaries, and new
  device nodes in the filesystem.
- new NetBSD (or dynamic NetBSD) binaries with old device nodes in the file
  system.  (But if the dev_t stored in the opened file is left in 16 bit
  format, this is not a problem.)

: yes.  Very good.  I think i might perfer the name "devcmp()" though
: (after timercmp()).

I like that too.  Will do.

: > 14. mknod(8) will be introduced to a new command line option to create "old" 
: > style device nodes.  Possibly, mknod(8) will be modified to have an option
: > to specify explicitly the number of bits used in each of the major or minor
: > device numbers.
: 
: No to the former.  Yes to the latter.  Best of all, give it the option
: to take an opaque 32-bit number an mknod() that.  _THAT_ would be most
: useful.

Well, both.  With the majorbits/minorbits options, you could run a MAKEDEV
script from some other BSD with minor modification, or a script somewhere
early in $PATH.  The 32-bit-number option is also a great idea.  (I'd assume
that it should accept a hexadecimal number, too....) 

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