Date: Mon, 23 Apr 2007 11:17:27 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Ivan Voras <ivoras@fer.hr> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-geom@freebsd.org Subject: Re: GPT as default? Message-ID: <09A66888-CB75-42B7-878B-0FB71DA36D32@mac.com> In-Reply-To: <462CEC00.2010304@fer.hr> References: <f0am4t$mmk$1@sea.gmane.org> <86wt076k7u.fsf@dwp.des.no> <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> <863b2u18hz.fsf@dwp.des.no> <4629C2FE.9030301@samsco.org> <91BC1CF6-6C72-4263-A99A-C24FC209586E@mac.com> <f0eauu$97s$1@sea.gmane.org> <A08237C6-0F3C-4C60-B5C0-8C5AD3998EC7@mac.com> <f0g55u$dn7$1@sea.gmane.org> <DF7EC867-FC12-4C2C-92E6-4FCC18795562@mac.com> <86irboi0ra.fsf@dwp.des.no> <3383A397-6A95-4546-841D-CF17B98A797C@mac.com> <861wibin3h.fsf@dwp.des.no> <71073037-7FA3-4C51-9276-8AA7F42B95DE@mac.com> <462CEC00.2010304@fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
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 representation. 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@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?09A66888-CB75-42B7-878B-0FB71DA36D32>