GPT as default?

[Ivan Voras]

Marcel Moolenaar wrote:

>> Consider further that Ivan is a SoC student working on a new FreeBSD
>> installation and configuration tool which will offer graphical and
>> curses interfaces to, amongst other things, disk partitioning (in
>> fact, his mentor has asked him to focus primarily on the latter).
> 
> I'm fully aware. I gave him my input, and told him it was just a
> thought. It's up to him to do something with it or not.
> 
>>   He
>> won't have an easy job of it if 1) there is no reliable way to
>> configure GPT and 2) you trample all over his turf by insisting on
>> implementing your own curses interface to g_part.
> 
> I think you're making his job difficult by 1) spreading FUD and 2)
> interfering in an interesting and fruitful discussion I have with
> Ivan.

While I do enjoy a nice juicy flamewar occasionally (it's good for the
soul :) ), I'm not seriously considering going into this one. Thus, I'll
only add that if the GPT stuff is not finished soon-ish (few weeks, a
month?), and this includes the replacement for gpt(8) and the boot
loader, I'll gladly go with the venerable (and now mostly obsolete)
mbr+bsdlabels. I'll be first to admit that yes, I could do at least the
GEOM-related parts (and if I dust off my tasm books, the loader), I'll
also say that, if I do that, there also a dozen other things I could do
in the same way, which I won't in the time allotted.

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) - I don't see a reason
why this utility couldn't be a GEOM class helper .so library, like for
the other classes. Also, if we forgo EFI for now (because, let's admit
it, it's not used in non-OSX x86 and AMD64 machines), I think the first
stage MBR boot loader can be modified to chain load from GPT partitions.

As an absolutely last resort, I could even go with the existing gpt(8)
if the boot loader is done (and, I belive that des@ has said something
about the loader, nudge, nudge :) ).

> 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.
These two properties ARE different from the other classes, but I think
this is mostly because almost all other classes were done by only two
persons (i.e. there's not enough variety in the styles). It's different,
but not horrible.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20070423/b020318e/signature.pgp