GPT as default?

[Marcel Moolenaar]

On Apr 23, 2007, at 11:37 AM, Ivan Voras wrote:

> Marcel Moolenaar wrote:
>
>>> - 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.
>
> I was happy with it until I discovered I cannot modify the partition
> table :)

You mean that setting kern.geom.debugflags=16 doesn't work?

> Actually, I didn't believe this would be a "popular" feature myself,
> until, for various and completely unrelated reasons, I found myself
> needing to do so on two different machines. I think people were
> complaining mostly about this part, not on the command-line UI.

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.

>> Would a GEOM help class be of use to you?
>
> Yes, then I could have two options: either script the command-line
> utility or, possibly, try and hook directly into the .so helper  
> library
> (must see how much infrastructure code this way of usage needs).

Check out src/tools/regression/geom_gpt. There's a little C program
that converts the arguments into a gctl structure. It's used to test
the verbs. It was that simple to manipulate partitions with geom_gpt
and it's that simple to do the same with the g_part class. Only
minor changes were made to support multiple partitioning schemes
(see the gpt branch in Perforce).

You can partition disks that way, so it should be really simple
overall.

> (btw. technically it's not "GEOM help class" - it's a dynamic link
> library which has some data structures and function entry points
> exported. See for example
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/geom/class/label/ 
> geom_label.c?rev=1.9
>  - this is a small one. The geom(8) program dynamically links these
> libraries when needed, and uses them to perform actions related to  
> GEOM
> classes. These helper libraries can either do things themselves (in
> userland) - like labeling a provider, or pass the verb to the kernel -
> I'm not sure a combination of these is possible).

I definitely can take look.

>>> 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.
>
> I know, but if we pretend those 2 or 3 Itaniums running FreeBSD don't
> exist, we can cover 99.99*% of the market :)

Yeah, yeah, rub it in :-)

>> 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.
>
> These things are helped by getting fresh people in the project :)

True, but that's a good thing. If it weren't for them we'd
not be where we are now. It's not a bad thing that opinions
change or that new ideas are being tabled at all. But it
definitely helps if people can remember that implementation
of the ideas and/or opinions can only happen after those
ideas or opinions come into existence, so the implementation
will always lag behind. Sometimes that's measured in years.

-- 
Marcel Moolenaar
xcllnt at mac.com