Todd Vierling writes:
> : Could you explain what kernel ABIs you are preserving by this
> : mechanism? stat() already does 32 bit dev_t's, so there is no real
> : userland impact to what you are doing (no userland stuff interprets
> : dev_t numbers except for stuff like MAKEDEV which doesn't count).
> 
> Programs who find their tty by fstat()ing stdin and searching /dev for the
> tty, stat()ing each file, and comparing the dev_t.

This would work just fine without any need for any change -- it would
"just work".

> Root device "mount -u" checking (making sure /dev/???a matches the dev_t of
> the boot-time root device). 

Again, it would "just work" without any of what you proposed. No
problem at all. dev_t's are treated as meaningless integers by all
user programs that use them other than mknod.

> I can lift just about all of that if we determine that the first thing a
> user must do after the committed changes is re-run MAKEDEV with a new
> MAKEDEV script and mknod binary.  Without this, we have to ensure that
> binaries can do stat()-versus-fstat() checks.

They can do that WITHOUT running a new MAKEDEV.

> : > 7. The stat interface will be bumped a version number again, introducing
> : > __stat14(), __fstat14(), and __lstat14().  These will return a file's dev
_t
> : > unchanged, or if COMPAT_[09-13] are defined, dev_t's always converted to 
new
> : > format using the old-to-new conversion table above.  mknod(2) will not be
> : > changed, and will always create device nodes with the numbers unchanged.
> : 
> : Huh? stat() already has 32 bit dev_t's. I see no reason for doing this
> : at all.
> : 
> : > 8. The old stat interfaces, if included by a COMPAT_[09-13] option, will 
do
> : > direct searchs of the old-to-new table above to demote new dev_t's to 16 
bit
> : > dev_t's.
> : 
> : Why bother with this?
> 
> Again, programs that *do* care about binary comparisons of dev_t's.

Yeah, but they just do if (dev_1 == dev_2) -- they don't give a damn
about what part of the dev_t is in use, and stat() works just fine for
them. 

> It boils down to:  if something does a fstat*() and compares it with the
> dev_t in a stat(), it'll fail if we use the old device nodes,

No it won't. Not at all. What makes you think it would?

> device nodes and a binary of 1.2 or earlier (or a COMPAT_<someOS> binary
> that uses dev_t's < 32 bits).

The COMPAT_FOO subsystems already use differently shaped stat
structures. No issue here.

Perry