Subject: Re: libahdi [Re: CVS commit: basesrc]
To: Julian Coleman <J.D.Coleman@newcastle.ac.uk>
From: David Brownlee <abs@netbsd.org>
List: tech-userlevel
Date: 02/10/2000 17:09:58
On Thu, 10 Feb 2000, Julian Coleman wrote:

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

	How about a common datastructure that contains a void pointer
	to any label type specific magic, and an enum that identifies
	what type of magic (ideally both should be null for most labels).

	We could have this for both the main label and individual
	partition data elements.
	
	If we want to convert a disklabel from one form to another we're
	going to need the common data structure.

>   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?
> 
	Maybe src/sys/disklabel - as there will be many of them?

>   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 ...
> 
	Dynamically allocate the real partition data, then have an
	array that maps 'active' partitions to real partitions?

>   Partition usage.
> 
>     Different ports specify RAW_PART (and SWAP_PART?) differently.  Not sure
>     if this will be a problem
> 
	We really want to nuke the 'c' vs 'd' partition mush from orbit.
	Hopefully when we switch to larger number of partitions across all
	ports we can have common 'RAW_PART' vs 'NETBSD_RAW_PART' defines.

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

	The library can go in and only be used for non native label
	manipulation initially - that way we do not break any existing
	functionality...

		David/absolute