Date: Mon, 23 Apr 2007 19:25:20 +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: <462CEC00.2010304@fer.hr> In-Reply-To: <71073037-7FA3-4C51-9276-8AA7F42B95DE@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLOwAldnAQVacBcgRAsGfAJ47iU8byJo3N1O4ImnXqghIKvsEaACgrkzx sSsBdaqKF7NnI5T6M/cqfQ0= =PFC1 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462CEC00.2010304>