Subject: Re: 32 bit dev_t
To: Chris G. Demetriou <cgd@pa.dec.com>
From: Todd Vierling <tv@NetBSD.ORG>
List: tech-kern
Date: 01/15/1998 14:38:45
On Thu, 15 Jan 1998, Chris G. Demetriou wrote:

: Are you saying that you can run an old MAKEDEV with a new mknod now?
: I don't think i've ever seen you indicate that.

Ah, okay.  No, I haven't indicated that, because I haven't yet chosen the
path to take with mknod(8) and ls(1).  My current bias is (and my ls(1) is
already coded for this in the test setup): 

- ls(1) prints devices in major-`unit'-`subunit' format (12/12/8 bits).  In
  this arrangement, 16-bit device nodes show up as `0,major,minor'.
- mknod(8) will make 16-bit device nodes (or N bit device nodes, depending
  on command line switches) if passed two numerical arguments.  It will make
  32 bit device nodes if passed three numerical arguments in
  `major unit subunit' format.
- major() and minor() are still the preferred way of getting at the
  internals of a dev_t (though only the kernel should care, anyway).
  Devices may or may not adhere to the `unit'-`subunit' split, so they
  should use their own semantics on handling the minor bits.

This lets old MAKEDEV scripts (and old mknod commands) work on the new
mknod(8), and new mknod commands/MAKEDEV scripts will break on the old
mknod(8) with either command line switches or the third number.

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