From owner-svn-src-all@FreeBSD.ORG Sun May 15 17:25:54 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 997F41065670; Sun, 15 May 2011 17:25:54 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 677AF14EA07; Sun, 15 May 2011 17:25:53 +0000 (UTC) Message-ID: <4DD00C8F.1020700@FreeBSD.org> Date: Sun, 15 May 2011 21:25:35 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marcel Moolenaar References: <201105151145.p4FBjDVR038539@svn.freebsd.org> <7B2294F7-8383-42F2-8127-759DBCD3540A@xcllnt.net> <4DCFF0D5.3080309@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=10C8A17A Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig001759CB17BAC0D51AFE7306" Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r221952 - head/sbin/geom/class/part X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 17:25:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig001759CB17BAC0D51AFE7306 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable On 15.05.2011 20:59, Marcel Moolenaar wrote: >> g_part_dumpconf() function does set both pair of parameters: >> (start, end) and (offset, length). I do not see a way how one pair >> can not be present in XML tree. >=20 > /* ... paging in non-commit details ... */ >=20 > The point is that this is what's happening *now*. This is not > what happened before. With support for logical partitions (i.e. > the EBR scheme), the total partition bounds and the effective > usable space are not the same. This is because the partition > starts with an MBR look-alike. The usable space is therefore > 1 sector less and start at offset 1 (0-based) from the start > of the partition. >=20 > In any case: this particular scenario had to be handled and > for that we have offset+size (the usable area, as per GEOM > standards) and start+end (the total space occupied by the > partition) separately. They do not represent the same info. >=20 > The start+end parameters did not exist before and I had to add > that "later". To have the utility work with older kernels (that > did not support the EBR scheme) I added the fall-back to using > offset+length, because those two would encode what we needed > in that case. Yes, i looked in the commit log before doing this change. And i did not do any changes in the kernel. Removing code that never triggers seems no so bad for me. I'm also do not see how MFC can affect the stable branch, because this code only used inside gpart(8) and it is problematic to reuse it from not here (and also it never triggers in stable/8 too). > As I said: I'm fine with the change, but please assess the > consequences of dropping the fall-back, for it may be better > to make this change on -current after 9-stable branched and > without the MFC. So, would you like to revert this change? --=20 WBR, Andrey V. Elsukov --------------enig001759CB17BAC0D51AFE7306 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN0AyVAAoJEAHF6gQQyKF6WU0H/jmm1ZYrWNIYgW6gCsL3PJHc Kv+UMPBzPoPdchkcV80A/X9sUOAZDgVn62xWK9j5xa3JOVfnxZiS/jpm3sGcs675 FCrECPr60H9j3Krki1v86pGBrUvA++D/hiCrkWseF9eM6qq31N+gBx9Po4R4DvfV nIg3pU9yAHXmhY/vnz4jws0XzNHHBlPpywJkNkei591QD+70MaHXWBZbvGFeIxb8 B+ETu+0x7ii2uTu/QpD+FoySTIRjmR2Tx7iHd3rtJcoUqzax/cO+bLyl5bGra57a 7nyD0TJ82rW/ZbF+UAnQ/FdloS8+0oS747ZncWSG0gBKS7UkiGgbaV+NaZ3T764= =0IIC -----END PGP SIGNATURE----- --------------enig001759CB17BAC0D51AFE7306--