Bill Studenmund wrote:
> Let's start to get the name right now. How about libdisklabel, with the
> individual routine names containing the partitioning format name.

Sounds good too me.  I wondered whether something shorter would be better,
but I can't think of anything that is a) meaningful and b) non-ambiguous.

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

Hmm, API ... some thoughts ...

Purpose of the library ... routines to read native labels _and_ to read
other ports' disks.

We want to be able to (at least) read the foreign labels, maybe also to
write them.  First, names for functions.  Either of the form :

  ahdi_readlabel()
  ahdi_writelabel()

or

  read_ahdi_label()
  write_ahdi_label()

(with or without underscores).  I prefer the former (and libahdi is
implemented like that).  There's also the additional complication of
different native and NetBSD labels on some ports.  For example, we need

  ahdi_readlabel()	(native Atari disk label)

and

  atari_readlabel()	(NetBSD port/Atari disk label) 

to read Atari disks on all ports.

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

Next, data structures.  Would it be good to be able to 'import' all the
foreign labels into a common structure?  Can we do this sensibly?  At the
moment, I have :

  int
  ahdi_readlabel(struct ahdi_ptable *ptable, char *diskname, int flags);

so that the native label is parsed into a 'struct ahdi_ptable'.  This
contains :

  number of sectors/track
  number of tracks/cylinder
  number of cylinders
  number of sectors/cylinder
  number of total sectors
  number of partitions

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)

Perhaps a separate data type for each native partition form would be better,
with a common disk information data type.

Obstacles (all that I've thought of so far, some obvious) :

  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?

  Number of partitions

    Different ports support different numbers of partitions.  The data types
    should handle the maximum number.  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 ...

  Data sizes

    All data sizes must be explicitly specified.  This may impact the MI vs.
    MD headers above.

  Endian

    The routines must be endian-independent.  Again, this may impact the
    headers.

  Partition usage.

    Different ports specify RAW_PART (and SWAP_PART?) differently.  Not sure
    if this will be a problem

Time scale

  This requires quite an overhaul of code.  Wait until after 1.5 before
  putting this in the main tree?

J

PS.  [Bcc'd to port-m68k, since this isn't m68k specific anymore]
--
                    My other computer also runs NetBSD
                          http://www.netbsd.org/