From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 27 20:14:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC3DB1065673; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 990018FC0A; Wed, 27 Jun 2012 20:14:24 +0000 (UTC) Received: from marcelm-sslvpn-nc.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5RKEDrR012391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jun 2012 13:14:20 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=koi8-r From: Marcel Moolenaar In-Reply-To: <4FEB5EA1.7060903@yandex.ru> Date: Wed, 27 Jun 2012 13:14:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <7E41D945-F6FA-48D5-ADDC-4884A7C7C0F8@xcllnt.net> <4FEB5EA1.7060903@yandex.ru> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1278) Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 20:14:24 -0000 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. >>=20 >>> 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. >>=20 >> 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! >=20 > 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: >=20 > 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. --=20 Marcel Moolenaar marcel@xcllnt.net