Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 May 2011 21:25:35 +0400
From:      "Andrey V. Elsukov" <ae@FreeBSD.org>
To:        Marcel Moolenaar <marcel@xcllnt.net>
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
Message-ID:  <4DD00C8F.1020700@FreeBSD.org>
In-Reply-To: <E2746EF4-47DD-48F7-A255-4BAF83736A5F@xcllnt.net>
References:  <201105151145.p4FBjDVR038539@svn.freebsd.org> <7B2294F7-8383-42F2-8127-759DBCD3540A@xcllnt.net> <4DCFF0D5.3080309@FreeBSD.org> <E2746EF4-47DD-48F7-A255-4BAF83736A5F@xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DD00C8F.1020700>