Hi,

> I assume that 'arbitrarily large' == 'generic'.... Do we _only_ allow the
> generic label to be stored as an in-core label? I think sanity demands 'yes'.

I would think so.

> Yes. Also:
>     - disklabel _only_ manipulates a 'generic' label.
>     - mbrlabel (and the likes) manipulate both a specific and the
>       generic label
> I don't think we should try to stash all label formats in one program.

Yes, that's my opinion, too.  I hate programs that try to be the
"eierlegende Wollmilchsau" :-).  Those always do things wrong, and
even those things that they do arguably right, they don't in a way
I would expect them.  Even worse than that would be to stash all
label formats into the kernel.

That was the reason I wrote mbrlabel in the first place.  It just
was a quick hack to demonstrate the feasibility of doing a
conversion of media dependent disklabels to native disklabels
in a userland program.

(BTW, there of course is room for enhancements in mbrlabel,
like the possibility to ignore some of the (MBR) partitions
(this can probably be avoided if we up the number of partitions
in the incore disklabel to something like 64), or (of course in a
separate program) the possibility to read a NetBSD/i386 disklabel
out of a NetBSD partition found during the mbr partition traversal).

> > While the ability to work around deficiencies in kernel
> > native->generic translation in user-land (via programs like mbrlabel)
> > is very important, if the need for programs like mbrlabel is anything
> > other than transitory for common label formats, we're probably doing
> > something wrong.  The 'bugs' section of mrblabel points out why you
> 
> I am not sure why you think they should be 'transitory'. Are there enough
> platforms with pc-like labels (assuming you meant these by 'common ;-) to
> warrant them as the basis for (or fully included in) a generic-label?

IMHO doing any and all native partition formats of any and all platforms
we support in the kernel is surely the wrong thing to do.

> Since you name was is so many of the disklabel files I fear you are
> authoritative in this ;-)

Hmm, not meaning to ignore Chris' effort in this :-), it is more or less
the result of anyone taking parts of his disklabel code when porting to
different platforms, not of he being involved in these porting efforts.

> > want this done in the kernel: so that the first open of the disk gets
> > a proper faked-up generic label.  (I would argue that any attempt to
> > "fix" disk drivers to remember in-core labels when all partitions are
> > closed is bogus... you then need to perform special hacks where you
> > didn't previously need to, e.g. in disklabel -r or dd (if clobbering
> > the old label area 8-) to get the old in-core label forgotten if it's
> > no longer desirable... violates the principle of least surprise.)

Hmm, IMHO it _is_ neccessary for disk drivers to remember in-core labels
between all opens.  Anything else is IMHO "violating the principle of
least surprise".  (BTW, wasn't it you, Chris, who did something very
similar to this to the tty's parameters when you introduced the ttyflags
utility?  IMHO, that's way more VTPOLS :-))

Speaking of "principle of least surprise", IMHO the disklabeling in and
of itself is sufficiently violating this principle so that I don't think
that it is appropriate to even add more hacks to that.  Certainly I wouldn't
want to add any hacks to dd (and I cannot think of any reason that one would
argue for such a modification), but I also think that disklabel -r
should be left alone (albeit I have to admit that I don't know firsthand
what this actually does, having not actually tried it on a disk that had
its in-core disklabel modified, only infering from its description).
Both already (seem to) do what is IMHO the expected behaviour.

> My first though with that section is also "bogus", but it might
> be an idea to include a 'sticky' flag in the generic-label definition.
> This flag can than be used by utilities like mbrlabel to stick a
> fake label on a device (and remove it of course).

IMHO this isn't neccessary (and would only complicate things).

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800