GPT as default?

[Ivan Voras]

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 :)

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.

(If it were about UI, the fdisk and bsdlabel "user intefaces" would long
be dead and buried, at a crossroads, with wooden stakes in them).

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

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

>> 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 :)

Seriously: EFI support must stay for the systems that need EFI to boot,
it's not needed for those that don't. i386 and amd64 machines need GPT
without EFI.

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

I see.

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

Excellent.

> 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 :)

-------------- 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/5d58da4e/signature.pgp