[TEST/REVIEW] boot0cfg/fdisk issue fix

[Marcel Moolenaar]

On Wed, Jul 06, 2005 at 07:58:23PM +0300, Maxim Sobolev wrote:
> 
> I wonder if there cound be a "better" fix.

Yes, there is.

> Another good feature to have is the ability to tell geom_mbr/geom_bsd 
> (via sysctl or ioctl) to make in-core copy of the table/label and 
> release any locks it helds on this region, so that it can be replaced 
> with completely different version if needed via simple write(2). The 
> same applies to the disklabel class. This is really necessary for some 
> cases, when the user or the program know he/is trying to do.

Yes, I've been arguing that.

A completely different approach that helps to abstract the details
of the slicer (i.e. MBR, GPT or BSD) is a functional interface.
Have a device special file for each slicer and implement ioctl(2) on
them for adding, removing, resizing etc of partitions. That way
GEOM gets to see requests like:
	"remove slice number 3, please"
Those are very easy to validate. Much better than getting a block
of raw bits and having to figure out what exactly changed and if
something's not acceptable.
The request to add a slice is understood by any and all slicers,
so you solve the problem generically, not by kluging the one and
only slicer your brain is fixated on and leaving the problem
unaddressed for every other slicer.

Concretely: Suppose we have a SCSI disk with a MBR and a BSD label.
We'll have the following device special files:

	da0
	da0.mbr
	da0s1.bsd
	da0s1a
	da0s1b
	da0s1c
	da0s1d
	da0s1e
	da0s1f
	da0s2
	da0s3
	da0s4

Potentionally we could end up with a single tool to manipulate any
and all slicers, provided we define the ioctl interface correctly.

Just another thought,

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net