Date: Mon, 23 Apr 2007 20:37:40 +0200 From: Ivan Voras <ivoras@fer.hr> To: Marcel Moolenaar <xcllnt@mac.com> Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= <des@des.no>, freebsd-geom@freebsd.org Subject: Re: GPT as default? Message-ID: <462CFCF4.90505@fer.hr> In-Reply-To: <09A66888-CB75-42B7-878B-0FB71DA36D32@mac.com> 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> <09A66888-CB75-42B7-878B-0FB71DA36D32@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7F4CB8663A1A934B6B27CBC1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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_labe= l.c?rev=3D1.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), >=20 > 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 :) --------------enig7F4CB8663A1A934B6B27CBC1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLPz6ldnAQVacBcgRAnVnAJ0QR5xA10Nc4B4gQaB0/jP5WP3u3wCgtPca 20CTGKWBUN6EHuqIVxxfmjY= =jvsp -----END PGP SIGNATURE----- --------------enig7F4CB8663A1A934B6B27CBC1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462CFCF4.90505>