Subject: Re: 32 bit dev_t
To: Chris G. Demetriou <email@example.com>
From: Todd Vierling <tv@NetBSD.ORG>
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 firstname.lastname@example.org) =====
== "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