GPT as default?

Marcel Moolenaar xcllnt at
Mon Apr 23 18:18:41 UTC 2007

On Apr 23, 2007, at 10:25 AM, Ivan Voras wrote:

> But, I believe the outlook is bright. AFAIK, the only thing currently
> missing for geom_part is the userland utility with verbs "add",  
> "remove"
> and "show" (as well as the GEOM XML dump, please)

.. and create, delete and destroy :-)

Yes, the tool uses the GEOM XML to figure out the configuration and
g_part will put all it's information in the XML. It's conforming to
established mechanisms.

> - I don't see a reason
> why this utility couldn't be a GEOM class helper .so library, like for
> the other classes.

It could actually and it would be a good way to implement support for
scripting that way. I haven't spent much time on that yet as there
hasn't been any interest. I implemented gpt(8) in that manner when
GPT was still using the generic slicer code. Hence the command-line
interface. The only feedback I received was negative, so I didn't
think people would be happy to see me do exactly the same thing.

Would a GEOM help class be of use to you?

> Also, if we forgo EFI for now (because, let's admit
> it, it's not used in non-OSX x86 and AMD64 machines),

It is, actually: ia64. EFI was specifically designed for ia64,
with the intention to be a replacement for the BIOS on non-
legacy i386 machines.

>> In an attempt to close the gap between us, let me ask you this:
>> What's the cleft between g_part and the other GEOM classes?
>> In what way do you think I'm hell-bent to increase that what
>> I don't know?
> I don't know the entire possible background to this claim, but I  
> see two
> things: use of kobj and the "modify in-memory, then commit" operation.

KOBJ is the de facto standard way to implement interfaces. The
interface in this case is between the generic partitioning code
and the per-scheme code that deals with the actual on-disk

The in-memory modify with commit is there to support sysinstall
as well as to bridge the gap between the elementary operations
and the need for atomic compound operations. For example: The
GPT partition code support the legacy FreeBSD slice with BSD
label. It's supported to allow migrating from MBR+BSD to GPT+BSD,
which we needed in the early days of the ia64 port. GPT+BSD
creates the same device nodes as MBR+BSD, so it is possible to
do it in place. In fact, it's theoretically possible to do it
with partitions mounted, because all that changes is the on-disk
representation. However, to migrate a MBR to BPT without a
special verb for it would require a sequence of delete verbs,
followed by destroy, create and a sequence of add verbs. These
verbs together need to appear as a single atomic operation to
the kernel. This, as I said with sysinstall in mind, let me to
implement the in-memory update with commit (or undo/revert).

The worst that can happen is that it ends up being an unused
feature. You can always commit after each verb, In fact, I've
put everything in place to allow each verb to be followed by
an implicit commit by way of the flags. The future will tell
us what we end up using or what was really needed. The
implementation is intended to provide all the flexibility to
implement something good, useful and user-friendly.

So, there are good (in my opinion at least) reasons behind
what I do. The design is much more elaborate and complete than
some (or many?) think. And it almost appears that the adoption
of past, current and future practices is exactly what makes
people think that there's a cleft or a lack of design. This,
I think, can only mean that the status quo is much more ad hoc
than we like to think it is and opinions change faster than
we all like to admit.

Ahhh, the joys of human fickleness and fallibility :-)

Marcel Moolenaar
xcllnt at

More information about the freebsd-geom mailing list