Subject: Re: 32 bit dev_t
To: Chris G. Demetriou <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 01/15/1998 12:11:15
On Thu, 15 Jan 1998, Chris G. Demetriou wrote:
> > The thing is, this matter is fine now. Taking a suggestion from you (table
> > of major numbers/minor-number-translating functions) and Charles's
> > suggestions wrt specinfo, it's now possible to have both 16 and 32 bit
> > dev_t's coexisting. Translation is only done when the kernel caches the
> > dev_t deep in a vnode (used when calling device functions), and the devices
> > see 32 bit dev_t's whereas userland sees untouched dev_t's. Voila!
> He was talking about about updating MAKEDEV and mknod at the same
> 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.
One of the things I heard suggested (by Jason?) was to add a flag to mknod
to have it make "32-bit" nodes. Old mknod programs will choke on this
flag. Then the MAKEDEV script uses this flag whenever it makes a node
using the new major & minor numbers.
Since the new mknod will make old-style nodes when invoked with the old
syntax, and the new script will make old mknods barf, we can avoid an
Optionally, we could have mknod make a "32-bit node" if we renumber, and
it's given a re-numbered major number. If we do this, it should print out
some message as a warning. And we don't have to do this if we feel it's