On Apr 23, 2007, at 11:32 AM, Dag-Erling Smrgrav wrote:
> Marcel Moolenaar <firstname.lastname@example.org> writes:
>> On Apr 23, 2007, at 12:09 AM, Dag-Erling Smrgrav wrote:
>>> Marcel, my words may have been poorly chosen, but I've been using
>>> for several years, and I've reported these issues (and others) to
>>> 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.
I told you before:
To view use the -r option to gpt(8) to open the device read-only.
To modify: set kern.geom.debugflags to 16 first and run gpt(8).
I don't claim that it's ideal or perfect, I only claim that you
can do what you want in a way that suitable until I'm done with
>> 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?
> 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.
I see. So with cleft you really mean that you'd like to see g_part
move from category 2 or 3 to category 1. That surely is a poor choice
I'm not at all opposed to add support for geom(8). See also my
email to Ivan.