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