Subject: Re: libahdi [Re: CVS commit: basesrc]
To: NetBSD tech-userlevel mailing list <firstname.lastname@example.org>
From: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
Date: 02/10/2000 16:49:03
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 :
(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)
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 :
ahdi_readlabel(struct ahdi_ptable *ptable, char *diskname, int flags);
so that the native label is parsed into a 'struct ahdi_ptable'. This
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 :
id: GEM, BGM, NBD, ...
root sector (the sector on the disk containing the parition information)
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 ...
All data sizes must be explicitly specified. This may impact the MI vs.
MD headers above.
The routines must be endian-independent. Again, this may impact the
Different ports specify RAW_PART (and SWAP_PART?) differently. Not sure
if this will be a problem
This requires quite an overhaul of code. Wait until after 1.5 before
putting this in the main tree?
PS. [Bcc'd to port-m68k, since this isn't m68k specific anymore]
My other computer also runs NetBSD