Subject: Re: 32 bit dev_t
To: Chris G. Demetriou <cgd@pa.dec.com>
From: Bill Studenmund <wrstuden@vali.stanford.edu>
List: tech-kern
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
> time.
> 
> 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
upgrade mess.

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

Take care,

Bill