On Wed 25 Aug 1999, Chris G. Demetriou wrote:

> > Leo Weppelman <leo@wau.mis.ah.nl> writes:

> Right.  as always, there are two disklabels to be concerned about: the
> in-core label and the on-disk label.  the in-core label can be
> arbitrarily large, and disk drivers should support this.
> 
> When setting the in-core label (DIOCSDINFO), the arbitrarily large
> label should be allowed.

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


> in-core label (and mbrlabel(8) or similar programs might want to
> generate disklabel(8) compatible output, so you could say something like
> 	mbrlabel sd0 > file
> 	disklabel -R -S sd0 file
> (where -S just sets the in-core label), or similar cmds.

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.



> > It is useful to carefully consider what the userland disklabel definition is
> > going to look like, so the userland transition on the ioctl-interface has
> > only to be done once. To support other disklabel formats, the best thing
> > todo seems to reserve a certain amount of slack in the structure and use
> > unions in the definition. So label formats can be squeezed in.
> 
> ... or your pointer/size/type suggestion.
> 
> i think i agree with this analysis, but the decision of what how to
> represent the data is probably not going to be an easy problem.

Why not take the current disklabel as a basis? It is maybe a bit too
ffs-centric,  but that _is_ the primary filesystem. We can extend the
number of partitions and add some things (like the 'sticky' flag below).

[ Suggestion for a read on-disk label/set in-core label/write on-disk label
  function removed ]
The basic function set looks good! 

> I'm not sure of the feasibility of doing the generic -> native
> translation in the kernel, rather than embedding that knowledge into
> user-land programs.  If you try to do it in the kernel, you need to
> figure out what do to about partition IDs, etc., which may not easily
> fit into a generic representation that's useful for most kernel
> purposes.

Me neither. Besides, I think that there is no guarantee that generic ->
native translation is possible without loss of information. I mean, the
generic label contains enough info to reasonably describe a disk and the
slicing. It does not contain some superset of all labeling technics that
were ever tried out... (Hence my choice to build upon the current label).


> 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?
Since you name was is so many of the disklabel files I fear you are
authoritative in this ;-)

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

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