Subject: Re: 32 bit dev_t, Revision 2
To: Perry E. Metzger <>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/11/1998 17:33:25
On Sun, 11 Jan 1998, Perry E. Metzger wrote:

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

Not in the case that:

- the /dev device opened is an old dev_t, and we convert the dev_t to new
  format when storing it in the vattr.va_rdev--when fstat()ed you get a new,
  not old, dev_t which doesn't match what's on disk!
  (If we don't convert the vattr.va_rdev field when opening a device
  special file, though we do convert the major number when finding the
  actual device, that _could_ be okay, but how much code out there tests
  vattr.va_rdev for equality with another dev_t that may be the opposite
  style of device?  I'm only 1/10th the way through a kernel compile and
  I've hit ten cases so far, vfs_subr.c being the main culprit.)
- you're using a binary for an OS other than NetBSD that uses 16-bit
  devices, or you're using a binary for NetBSD 1.2.1 or earlier, and the
  device node is "new" style--now you have ambiguity as to which device it
  is, since the major numbers are outside of 16 bit scope.

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

That's why we have to worry about confusion--because a dev_t in one place
may not match a dev_t somewhere else where an equality test is used.

Look in src/lib/libc/gen/ttyname.c, and look at it a few revisions back too. 
Imagine what would happen in the two cases I describe above, and pay close
attention to the fact that ttys are compared based on dev_t.  Breakage.

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

There's an issue of userland programs that *use*dev_t's* -- who are a lot
more than you probably think.  The BSD routine ttyname() and the SVR4
routine ptsname() both break if we Just Change It without considering
two-way compatibility.

===== Todd Vierling (Personal =====
== "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