On Wed, 6 Aug 2003, David Laight wrote:

> > Do you mean to have "disklabel" calculate the number of partitions?
> > If so, then I agree. I think "d_npartitions" in the disklabel struct
> > serves some purpose (to limit the size of the label, and keep garbage
> > in the binary label from being parsed), so it's nice to be able to
> > view it, but it makes no sense to have to specify it.
>
> I'd go for d_npartitions meaning 'the number of slots available
> where this disklabel is stored.  Unfortunately that isn't the case :-(
> It is used as (rather useless) 'current upper bound to the number
> of valid entries'.
>
> The problem is that MI code can scan a disk (looking in likely places)
> until it finds a disklabel.  But it can't add a partition because
> it doesn't know whether it has found an 8 entry or 16 entry label,
> all it has is the number of defined partitions.

How about, if we let "disklabel", when converting a text label to a
struct, make that field the maximum of the specified value or the
actual number of valid partition entries? That would do the intuitive
thing for a person who was adding a partition, avoiding the problem
that started this (unnamed) sub-thread, while not being incompatible
with your scheme.

Frederick