[ after this message, i'm going to read the rev 3 doc and comment on
it.  "Good thing my SO's plane flight was cancelled." 8-]
  

> : 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?

You want to be able to boot from them and use them.  However, you
should replace them as soon as possible and there might be minor bugs
(i.e. when comparing devices) resulting from their use if you mix old
and new device nodes.


> : > 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.  :)

Paul might want you to add it back, but if so then it should be
consistent in user-land and in the kernel, and most of the macros you
wanted (i.e. to convert to and from integral types should be
unnecessary except maybe for the NFS code).

> : > 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.

How much difference do you think there is?

I don't think there's very much...  Mostly different function calls.
Do any of the device table entry points actually have different
_semantics_ for block vs. character?  (most of the special semantic
handling is taken care of the in the spec vnops.)

You'll note that there's not a foo_char_open and a foo_block_open --
usually there's just one 'fooopen', etc.


The calling interface to device drivers will have to change
eventually, anyway, but I don't think that's a stumblink block for
this purpose.


> : '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?

Yah.  There should be MI stubs for conversion involving:
	(1) "the same number,"
	(2) MI devices
which could just be plugged in to the table to do the right thing.


> : *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 ?

"Do whatever you'd do for a vendor with a 16-bit dev_t in the stat
struct."

That might mean that binaries which do dev_t tricks will break, or it
might mean that some wicked 'distillation' algorithm will be used, or
something else.

Maybe this means an addition to the 'compat' tables for backward
compatibility, but i'm not sure it's important enough to seriously
worry about.


> : 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.)

Your other mail indicated that you 'got over' your concern about old
programs with 32-bit dev_t's right?

Yes, you need to do something gross for compatibility with 16-bit stat
structures, but I don't think that's important enough to twist the
architecture around for it.




chris