New g_part class

[Poul-Henning Kamp]

In message <BA11EE01-2B86-42EA-94AC-6F977EF7E680 at mac.com>, Marcel Moolenaar wri
tes:
>All,
>
>I sent a diff to re@ for review, but I figured this is also a good  
>place.
>The diff can be found here:
>	http://mail.xcllnt.net/~marcel/g_part.diff
>
>The g_part class is a generic partitioning class with a rich set of
>g_ctl verbs for creating and modifying partition schemes. 

I did think about doing things this way originally, but I couldn't
convince myself that it would make more sense to do so and I'm still
not convinced I see a net benefit from sticking all the slice
edititing code into the kernel.

First there is obviously the size/bloat argument.  Currently the
slicers only have to have the taste functionality.  Writing new
layouts can generally reuse the same code for the permission check,
Although MS-DOS extended partition tables are an example that cannot.

Considering the fact that editing can be done equally well in
userland, what is the rationale or benefit of putting the code into
the kernel, to deal with very infrequent operations to change the
disk-layout ?

My second concern is if we might still have to replicate all the
error detection in userland, if we want to retain the option for
atomic changes, ie: allowing users to specify a set of changes (with
disklabel -e for instance) before committing them all ?

Third, I doubt this will prove as useful as expected in writing
partitioning tools.  For instance, how will the partitioning tool
know about the geometry/alignment restrictions of MBR ?

If you study libdisk, you will find that there are a couple of DWIW
functiosn that translate the users wish for a NN MB size thing into
a properly aligned and sized thing for the MBR.  Where does that
functionality live in this situation ?   Does the kernel return "no
good, try these parameters instead ?" or does it silently truncate
and align ?

So I would advocate that you try to implement the MBR method next
and then do a prototype disk-editor utility, so we can see if this
actually makes life easier or not.

>schemes like MBR, BSD, SUN and/or PC98.

BSD labels represent a particular nasty case, because of the
possibility that the label sector is inside on a partition.  I will
advocate that if we go this direction, we should not migrate BSD,
but leave it behind to die, eventually.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.