New g_part class

[Poul-Henning Kamp]

In message <835A2C66-BBEB-4A19-B6A3-A60E17572604 at mac.com>, Marcel Moolenaar wri
tes:

>Editing is of course still done in user space. The application
>is responsible for providing the right values to the kernel and
>the kernel will simply fail the operation if something is not
>correct.
>
>The reason why the kernel supports the application with these
>verbs is simple: the kernel needs to be involved because the
>application cannot write to disk directly in all cases. 

Right, but the current scheme handles this by asking the kernel to
write the finished metadata image, which the kernels taste
functionality can be used to validate and parse.

That way, the kernel doesn't have very rarely used code for
editing the metadata, only the necessary code to parse and
configure based on the on-disk metadata.

>Libdisk is badly designed (if at all) and badly implemented [...]

No argument there, and that's from the guy who slapped it together
between changing diapers :-)

>It's the application that should exhibit artificial intelligence
>(if at all), not the kernel.

So what is the advantage of editing the metadata in the kernel
instead of userland ?  Userland still needs to know about the
entrails of each slicer method, so what is the benefit of
your scheme, compared to editing the metadata in userland and
just having a "write new metadata" verb ?

If you could have writte a generic partitioning tool that didn't
know about the different formats, then I could see the point,
but having to have the code both in userland and in the kernel
makes little no sense to me, in particular given how seldom
it is used.

>> 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.
>
>I wouldn't mind if BSD labels die. At this time the g_part class
>already supports the notion of leaf partitioning schemes, of
>which BSD will be one. Leaf schemes cannot have sub-partitions.

I'm not sure I understand the need for this restriction ?


The problem with BSD labels is that you need to intercept writes
to the metadata part if one of the partitions allows this to
happen.

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