GPT as default?
des at des.no
Mon Apr 23 18:32:58 UTC 2007
Marcel Moolenaar <xcllnt at mac.com> writes:
> On Apr 23, 2007, at 12:09 AM, Dag-Erling Smørgrav wrote:
> > Marcel, my words may have been poorly chosen, but I've been using GPT
> > for several years, and I've reported these issues (and others) to you
> > several times over the course of those years and witnessed your
> > complete lack of interest.
> Yes, your words were poorly chosen and you continue to show poor
> judgement. I have exactly 1 thread in my mailbox where I discuss
> GPT with you and that problem has been resolved.
Yes, it was eventually resolved. You ignored my initial report. I
bugged you about it, and we had a fairly fruitful conversation during
which I pinpointed the exact change which had broken GPT. That was
five months - to the day - before the bug, an overly-restrictive
sanity check which prevented GEOM_GPT from recognizing its own GPTs,
was finally fixed.
> I fail to see how that's several times over the course of years
> and I fail to see how that represents a complete lack of interest.
> What else did you send me mail about?
The fact that it's not possible to view or modify the partition table
while partitions are mounted.
> 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 should have said "the gap between $GPT and other GEOM classes",
where $GPT is "whichever GEOM class currently implements GPT support".
We have a fairly large number of GEOM classes, and right now they fall
into two categories:
1) those that are configured using a geom(8) plugin: gcache, gconcat,
geli, gjournal, glabel, gmirror, gmultipath, gnop, graid3, gshsec,
2) those that aren't: $GPT, gbde and gvinum
(there's a third category - GEOM classes which replace legacy code and
interface with legacy applications such as fdisk(8) and bsdlabel(8) -
but it isn't relevant here)
The fact that GEOM_GPT was in the second category was understandable
given that it was written two years before geom(8), but now that we
*do* have geom(8) I believe it is in everyone's interest to use it.
Yes, *your* interests as well, because it really *is* that easy to
write a geom(8) plugin if your class implements the necessary verbs;
you'll spend less time on the code than on the man page.
Dag-Erling Smørgrav - des at des.no
More information about the freebsd-current