Subject: Re: 32 bit dev_t, Revision 2
To: Todd Vierling <tv@NetBSD.ORG>
From: Perry E. Metzger <email@example.com>
Date: 01/11/1998 17:07:55
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
> 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
> : > unchanged, or if COMPAT_[09-13] are defined, dev_t's always converted to
> : > 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
> : > direct searchs of the old-to-new table above to demote new dev_t's to 16
> : > 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
> 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.