GPT as default?

[Poul-Henning Kamp]

>As time passed people started to complain more about the lack of using
>verbs to do the partitioning. That's just the nature of things and I'm
>working on it.

Before you guys rip each other another one, I just want to chime
in with some background:

For the existing classes, MBR, BSD and PC98 it was necessary to
emulate enough of the old ABI that it was simpler to implement the
"here is your completely new metadata as a binary blob" style change
ioctls.

Doing it this style has some advantages, most notably that you can
reuse the 'taste' function to validate the proposed metadata, if
you arrange it the right way.  That means the minimum amount of
code in the kernel and the majority of it in a seldom invoked
executable.

One disadvantage is that it is very messy for a class like MBREXT
here metatada is all over the media.  (That's why we have never
really supported editing extended partitions, nobody wanted to deal
with that mess.)

Compared to this is the verb-based style, which puts (much) more
of the complexity in the kernel with the potential benefit that one
could conceiveably use a unified userland tool for vastly different
classes, because now the kernel code knows all the magic details.

Finally, one should realize, that we are talking about an API/ABI
that seldom, if ever, gets invoked more than once for a given
system, and that is during installation where the system already 
run a highly magic application, for that very reason.

I find it counterintuitive to put the complexity into the kernel
for a so seldomly used API/ABI, so I _personally_ prefer the "here
is your metadata as a binary blob" style.

However,

As architect of GEOM I have sworn not to dictate people how they
write their classes or what their classes do or should do, apart
from the fundamental GEOM architecture and interfaces, which are
pretty well protected by my liberal application of KASSERT.

But it would clearly be an advantage if all the slicers used or
at least supported the same style...

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.