Subject: Re: libahdi [Re: CVS commit: basesrc]
To: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: tech-userlevel
Date: 02/11/2000 08:48:11
On Thu, Feb 10, 2000 at 04:49:03PM +0000, Julian Coleman wrote:
> [...]
>
> 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).
No, just return a 'struct disklabel *'. The calling program can stick it in
the in-core label if it's his putpose, but we may need a struct disklabel *
for other purposes.
>
> 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.
I think we need a separate data type for each native partition. Your
structure doesn't work well for MS-DOS partitions for example (we
need start sector, size and start c/h/s , size c/h/s, partition type and
eventually addidtionnal opaque data for this partition, in case it's an
extended partition, or a FreeBSD slice).
Maybe some common parts can be extracted and the rest be put in a void *.
>
> 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
there is a sys/disklabel_mbr.h :)
> 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 ...
At this point I think we have to handle the max number of partitions possible.
It's hup to the calling program to truncate it if needed.
--
Manuel Bouyer <bouyer@antioche.eu.org>
--