Bill Studenmund <wrstuden@vali.stanford.edu> writes:

> 
> On Wed, 14 Jan 1998, Charles M. Hannum wrote:
> 
> > > Hmm. Well, I'd still vote we change the minor split when we change
> > > dev_t's. That way we rebuild devices only once. :-)
> > 
> > I'm compelled to point out that, with my proposal, none of the device
> > numbers change at all until we decide to do an actual renumbering.
> > 
> > The two steps are largely orthogonal -- and both pretty trivial.
> 
> I agree that the changes are orthogonal (except that we won't want to
> change the number of partitions until we have a larger minor field :-),
> and that they don't really involve much code changing (especially changing
> the partition field).
> 
> 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.*

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

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.


[*] I'm specifically ignoring the random (and generally broken)
implementations of `dialout devices' in some serial drivers, which use
the highest bit of the unit number as a flag.  There are also a small
handful of drivers (`lpt' being the only one that comes to mind
offhand) that have flags at the high end of the unit number, and these
will have to change as well.


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.