On 14 Jan 1998, Charles M. Hannum wrote:

> 
> Bill Studenmund <wrstuden@vali.stanford.edu> writes:
> 
> > 
> > On Wed, 14 Jan 1998, Charles M. Hannum wrote:
> > 
> > But with any of the changing schemes, how do we tell a changed dev_t from
> > an unchanged dev_t? If it's a 16-bit or 32-bit dev_t seems like an easy
> > clue to me.
> 
> The dev_t type itself is already 32 bits.  As is the field in FFS.
> How, exactly, do you intended to differentiate between a so-called
> `16-bit dev_t' and a so-called `32-bit dev_t'?  *They're the same size
> in core.*

(dev_num & 0xffff0000) == 0 => "16-bit" dev_t.

> > I think I missed your proposal for re-numbering. I did see the one for
> > going to 32-bit dev_t's.
> 
> Honestly, I think you weren't paying attention.  My proposal includes
> all old device numbers within the same encoding scheme as any new
> device numbers.  The proposal for renumbering is essentially to
> deprecate the old 256 major numbers, and shift the major numbers up by
> 256.  [In reality, you could just deprecate the major numbers formerly
> used by disk drivers, since none of the other minor number encodings
> will change. [*]] There's no need to do these at the same time; the
> move to the new encoding can be done at any time, because it doesn't
> change the actual encoding or the meaning of any existing device
> numbers.
>
> The reason people are clamoring to change the unit/subunit splitting
> at the same time is that the other schemes for splitting the device
> number do not have this feature; if you do the steps separately, you
> have to waste both the old space and the corresponding space within
> the new encoding scheme for compatibility.  In fact, with my proposal,
> you could even change the encodings of different types of devices'
> unit numbers separately.  It's infinitely flexible (and simple).

True. But then we will be splicing minor numbers together until we move to
64-bit dev_t's. :-) That just seems kinda goofy.

In the keeping-minor-bits-together plan, all we have to do now is decide
how many minor bits per subunit (and you're right, we only have to bother
changing the disk dev_t's minors in compatability mode).

It seems easier to me to just decide between 6, 8, or 10 unit bits now,
and go with the minor bits being contiguous.

> As for unit/subunit splitting, I think 6 bits of subunit is a
> reasonable compromise.  64 partitions seems more than enough, and I
> can envision wanting to have more than 12 bits of unit (disk) number
> in the not-so-distant future.

Cool.

> P.S.  We have, in fact, deprecated device numbers before.  But this
> was years ago, when it wouldn't have had the potential to confuse
> thousands of users, and it wasn't quite as trivial to provide an
> upgrade path.

When was it?

Take care,

Bill