On 15 Jan 1998, Charles M. Hannum wrote:

> Bill Studenmund <wrstuden@vali.stanford.edu> writes:
> 
> > True. But then we will be splicing minor numbers together until we move to
> > 64-bit dev_t's. :-) That just seems kinda goofy.
> 
> If `seems kinda goofy' is the best argument anyone can come up with,
> I'd say that's flat out ridiculous.  You're *going* to screw over
> users by making old MAKEDEVs DTWT.  Making the device numbers look
> `pretty' in hex is, quite frankly, a *stupid* reason to screw over
> users.

Wait. Why are we going to screw over users?

Here's what I thought we were doing:

We have two ideas of what the dev_t is. One, the one returned by stat and
fstat & friends, is what's on the disk. The other, used internally by the
kernel, is in the kernel's internal representation (stored in va_rdev).
You sugested/pointed this out, and it certainly cleans things up.

Regardless of what we choose to do with bit paterns (either
MMMMMMMMMMmmmmmmmmmmmmmmmmmmmm or mmmmmmmmmmmmMMMMMMMMMMmmmmmmmm), as long
as the routine which converts an on-disk dev_t to the internal
representation can turn a 16-bit dev_t(*) to the 32-bit format, we're
fine.

((*) a dev_t where the major bitfield and minor bitfield combined only use
16 bits, even though it sits in a 32-bit value) 

As long as we do the above, we're fine.

Todd's proposal (which I like, but w/ 6 bits of subunit :-) is to go with
MMMMMMMMMMmmmmmmmmmmmmmmmmmmmm on disk, and use major 0 to indicate an
old-style dev_t (0000000000000000MMMMMMMMmmmmmmmm). We can achieve TOTAL
transparancy iff:

1) we retire block device 0 (we can keep character device 0 there if it's
the console, as it rarely even uses minor numbers). Assuming the
conversion routine knows a bdev from a cdev, we silently switch bdev major
0 to whatever it gets moved to. 

2) we decide now how many bits we want to allocate to sub-units. I'd hope
it's not hard for us to make that decision. Then the conversion routine
just decides if the old-style dev_t uses unit and sub-unit fields (device
type DV_DISK and DV_TAPE come to mind). If so, it splits the old minor
field into unit and sub-unit, then pieces them together in the new-style. 

Especially given your suggestion/statement about how to keep a
kernel-representation and an on-disk representation (for stat and fstat),
the above should NOT be hard.

The thing I don't like about the split-minor proposal is that it's bending
over backwards for compatability. Since we DO have a smooth upgrade path
w/o this trick, I'd rather we make a clean break with the past.

If I didn't think we could achieve this upgrade w/o screwing users, I
would support the split-minor idea.

If I've missed something, and this path will screw users, then I'll agree
that we should do the split-minor idea. But please show me how it will
screw them.

Take care,

Bill