>> If someone can throw some API docs my way I expect I can cannibalize
>> some existing code and produce support for Sun labels....

> First, names for functions.  Either of the form :

>   ahdi_readlabel()
>   ahdi_writelabel()
> or
>   read_ahdi_label()
>   write_ahdi_label()

I'd prefer to have a fixed part in the prefix for all the functions,
perhaps something like

label_read_ahdi()
label_write_ahdi()

But since it's a separate library of its own, this is not a very
serious issue.

It also occurs to me that since presumably these functions will all
have identical interfaces, it might be better to have

label_read(int type, ...)
label_write(int type, ...)

instead.  This might make it easier to plug in additional label types
at runtime (which I currently see no need for, but it feels like the
sort of thing that could be useful in the future and hence we should
avoid a library API that makes it painful).

> There's also the additional complication of different native and
> NetBSD labels on some ports.

I thought all NetBSD labels were basically the same, modulo endianness.
Is this not true?

Or are you talking about the fact that on some ports, native labels
aren't the same as NetBSD labels?

> We also want a function that takes the native label and updates only
> the in-core disklabel with this information (for dealing with foreign
> labels).

I would think this would be done with two calls, a read and an
update-in-core.  Why make it a single routine?

> Next, data structures.  Would it be good to be able to 'import' all
> the foreign labels into a common structure?

We already do, mostly, in that everything gets mapped into the
disklabel structure the kernel uses already, each under its own port.
The major problem I see with this is that some ports' native labels
contain information (such as partition names) that cannot be
represented in a struct disklabel.

> and for each partition :

>   partition flag
>   id: GEM, BGM, NBD, ...
>   root sector (the sector on the disk containing the parition information)
>   start sector
>   size in sectors
>   partition letter (the NetBSD letter to be assigned to this partition)

What's the "partition flag"?

What's the "root sector"?  Perhaps some of the more elaborate native
disklabel formats keep a per-partition info sector, but this should be
hidden by that port's read/write functions, no?  Certainly all the
label formats I'm familiar with (which admittedly isn't that many) keep
the entire label, including all the partition info, in a single sector.

I'd rather see partition number than partition letter; all the other
code I've seen works with numbers, mapping them to/from letters only
when it has to speak with a human or /dev.

>   MI vs. MD headers
>     At the moment all (?) ports have header files describing their disk
>     labels in header files that are not installed for all other ports.
>     These header files need splitting into MD and MI headers.  The MI
>     headers should go in src/sys/sys?

I'm not entirely sure why there have to be header files describing the
various label formats.  After all, nobody but libdisklabel is ever
supposed to be messing with them, right?

>   Number of partitions
>     Different ports support different numbers of partitions.  The
>     data types should handle the maximum number.

Is there a well-defined maximum number?  Are there any native
disklabels with effectively unlimited partition counts?  (For example,
is it possible to nest extended partitions on i386?)

>     However, the current state of affairs means all partitions on a
>     particular disk may not be accessible at once to certain
>     architectures.  For example, accessing my 10 partition disk on a
>     Sun.  Not sure what to do about this ...

The install-label-in-core code will have to install only as many as the
kernel in use supports.  How it picks which ones to install, if there
are more than kern.maxpartitions in the label, is for the particular
program to decide, perhaps with help from a human.

As for Suns, well, I've got 16-partition disks on /sparc and /sun3
already.  It wasn't hard, provided you're careful with /dev during the
changeover.  (I gather the need for a flag day wrt /dev is the major
reason this hasn't already been done in the main tree.  I can handle
it; many, perhaps even most, of the people here can handle it.  But a
lot of naïve users would be totally screwed by it.)

>   Data sizes
>     All data sizes must be explicitly specified.

Only if there are structs describing "foreign" on-disk data structures
(often a bad idea anyway, if only for endianness reasons).

>   Endian
>     The routines must be endian-independent.

Well...in some sense.  For example, I think Sun labels are always
big-endian (does anyone happen to know what the RoadRunner did for disk
labels?).

>   Partition usage.
>     Different ports specify RAW_PART (and SWAP_PART?) differently.

SWAP_PART?  I don't recall seeing that anywhere.  Siccing grep on the
kernel source tree makes it look like a mac68k-specific thing; it's
defined in sys/arch/mac68k/mac68k/disksubr.c (along with a bunch of
other _PART defines) and as far as I can see nowhere else.

>     Not sure if this will be a problem

I think it is likely to be.  Let's suppose, arguendo, that a new port,
NetBSD/foobox, is added.  The FooBox native scheme uses partition 0 as
the "whole disk" partition, so NetBSD/foobox defines RAW_PART as 0.

Now I take my Sun disk and put it on my NetBSD/foobox machine. What
happens?  Is Sun partition a inaccessible?  Or is the Sun RAW_PART of 2
mapped to the FooBox RAW_PART of 0, shuffling partitions 0, 1, and 2 to
make up for the difference?  Or what?

> Time scale
>   This requires quite an overhaul of code.

True, but not of that much code.  There are only a handful of places
that are affected: disklabel, mbrlabel (which presumably would turn
into a more generic program using libdisklabel), and possibly the
label-reading code for the various ports...anything else?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B