Re: [CFC/CFT] large changes in the loader(8) code

On Jun 27, 2012, at 12:27 PM, Andrey V. Elsukov wrote:

> On 27.06.2012 21:55, Marcel Moolenaar wrote:
>> You can't just re-interpret standards to match a context you know very well
>> isn't applicable and consequently redefine what the word "device" means.
>> You're on a slippery slope and while you may not see it as a problem, you
>> do make it a problem for FreeBSD users. It's our users we should be keeping
>> in mind when we solve problems.
>> 
>>> If a user wants modify GPT in the disk editor from the another OS,
>>> he can do it, and it should work. The result depends only from the partition editor,
>>> it might overwrite the last sector and might don't.
>> 
>> Right. Another happy user that sees his/her FreeBSD installation destroyed
>> or degraded (no mirroring, warning messages about corrupted GPT, etc) for
>> no apparent reason and without any kind of warning that what he/she is doing
>> is potentially harmful... That's the spirit!
> 
> Ok. Let's return back to my patches. They don't add any new methods to
> shoot in the foot. We are talking about the *FreeBSD loader*.
> This is the program that starts FreeBSD kernel. It doesn't start other
> OS. We already have many users who uses FreeBSD as a single system on
> the machine. Many of them use GPT inside of some GEOM provider.

Your patches are a continuation on a path that we're discussing isn't
necessarily the path we should be on. While you don't make things
worse from a compliance perspective, you make it worse by adding the
non-compliant behaviour to more components.

> As i understand there two parts where we haven't a consensus:
> 
> 1. You are against from:
> Our loader detects that primary GPT header is damaged. It tries to read
> backup GPT header from the last LBA and it detects that there is
> "GEOM::" signature. It tries to read one previous sector and there is
> *valid* GPT header.

How do you know it's valid? It's in a location that is not valid
to begin with. Validity is based on rules and you're violating the
the rules without defining exactly what we call valid given the
new rules. This may seem nitpicking, but having went through the
hassle of dealing with the broken way we created the dangerously
dedicated disk, I appreciate the importance of being anal when it
comes to something that lives on non-volatile storage and gets to
be exposed to a world much larger than FreeBSD.

> 2. You are against from having one fake PMBR entry by default in the
> /boot/pmbr image.

I don't understand what you're saying or what I'm being accused to
be against.

-- 
Marcel Moolenaar
marcel_at_xcllnt.net