Subject: Re: dev_t changes & partitions
To: Charles M. Hannum <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 01/14/1998 20:17:10
On 14 Jan 1998, Charles M. Hannum wrote:
> Bill Studenmund <firstname.lastname@example.org> 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
> 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.
> 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?