From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PXrHl-0002Ax-41 for mharc-grub-devel@gnu.org; Wed, 29 Dec 2010 03:21:29 -0500 Received: from [140.186.70.92] (port=52863 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PXrHh-0002Ah-UW for grub-devel@gnu.org; Wed, 29 Dec 2010 03:21:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PXrHf-0001W3-LE for grub-devel@gnu.org; Wed, 29 Dec 2010 03:21:25 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:64056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PXrHf-0001Vn-DJ for grub-devel@gnu.org; Wed, 29 Dec 2010 03:21:23 -0500 Received: by wwb17 with SMTP id 17so10211392wwb.30 for ; Wed, 29 Dec 2010 00:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ENMrVEuZOXwu0D9eNYxB8J2rAJnQeoRoFFrs05hoQEY=; b=bitp4zcPNsTpLKc8ihuiPoTboTgS0JVr/w9Pp5eSUTCRBVw9mMruT/zCcue4wI0mk9 rrNsz6Cxlb3O7MjxWHcl+X868fExwAeqDorMPXn2ETc3I/5z/JSDE1OFEMP9f2NL5dQf B9z13dAC8sBYiQ7GL212uimSdlUm2j+HxAHLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=Z4C/85MWJnYWhv1CaAJiij32E7FXxe1bGIVQ6MDoDB72ALX3Nl3EmiTzWLj+H4NeYm 0t9L3bnZw3YN0S4OmhUTTUyMwI+8hODcMIX8AD1f4cNGcHZGxM2l/E0wd37WVnP1wmJu +f+Ikb+61mI4spYVNAsX1sdVeyt0LPFa8726c= Received: by 10.216.28.8 with SMTP id f8mr2714613wea.48.1293610882682; Wed, 29 Dec 2010 00:21:22 -0800 (PST) Received: from debian.bg45.phnet (vpn-global-dhcp3-001.ethz.ch [129.132.210.1]) by mx.google.com with ESMTPS id p4sm6928251wer.5.2010.12.29.00.21.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Dec 2010 00:21:21 -0800 (PST) Message-ID: <4D1AEF7E.5090901@gmail.com> Date: Wed, 29 Dec 2010 09:21:18 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101211 Icedove/3.0.11 MIME-Version: 1.0 To: grub-devel@gnu.org References: <201012290625.oBT6Prwe014184@m5p.com> In-Reply-To: <201012290625.oBT6Prwe014184@m5p.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig173B4E3F1D56A9809229CEDC" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Two Small Patches (x86 VolId & Sun Label Checking) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 08:21:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig173B4E3F1D56A9809229CEDC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/29/2010 07:25 AM, ehem+grub@m5p.com wrote: >> From: Vladimir '?-coder/phcoder' Serbinenko >> On 12/26/2010 10:15 PM, ehem+grub@m5p.com wrote: >> =20 >>> Quite simple, the disk slice scheme detection routines vary in the >>> quality of their detection. In particular, the MSDOS-style detection = is >>> *extremely* brittle. The only even mildly distinguishing characterist= ic >>> it finds is ensuring only the msb of the boot-flag byte is set. The o= ther >>> thing it looks for is the 0xAA55 signature, but that is merely a sign= al >>> to PC-BIOSes that the disk is bootable; as such *any* bootable disk f= or a >>> IBM-PC will have that signature, whether or not it is actually using = the >>> MSDOS-style header. A 1 in 65536 chance of a false positive is bad. >>> =20 > =20 >> Actually 1 in 2^(7*4+16) =3D2^44 in you take into account the both che= cks >> and consider every possible sector equiprobable. While this is a >> problem, it's design problem of this partitioning label. More sanity >> checks are possible but they would be heuristics and increase the >> possibility of false negative. So every additional sanity check is to = be >> considered on case-by-case basis. >> =20 > Alas, seeing how every possible sector is very much *not* equiprobable,= > =20 Then you need to havethe information about distribution before even speaking about any probabilities. Otherwise these "probabilities" are good only for fortune-telling. > >> Improving quality of partmap detection is a good goal but be aware of >> the price of heuristics. >> =20 > That isn't my thinking. I was thinking of having it test for the variou= s > schemes first, then choosing the best fit. While trying multiple scheme= s > is viable for grub_partition_iterate(), it doesn't work when installing= > boot code or attempting to do partition modification (since both of the= se > *must* know in order to function). > > =20 When doing grub-setup then the philosophy is: "do no harm". It must abort when it sees anything unusual. GRUB can't have a super cow intelligence to magically sort all possible weird stuff. So sometimes we have to abort rather than risk damaging any data (with optional override options). As for partmap the user tells explicitly which partition table he means. E.g: parttool hd0,msdos1 boot+ So there is no problem here. > Organizational item here. Is the existing layout of / for t= he > best? (task would be boot/partmap/parttool, arch is pretty much every .= c > file in grub-core/partmap) I wonder if perhaps a structure like > / would work better? > > =20 Shuffling the files around without anything more than "it looks slightly better for me" is usually useless. We, the current developpers, find the current layout convenient. If do-o-cratically the consensus on changing of layout would be established it can be done, however I don't see it hap= pen While the sensible checks would be accepted, pushing tolerances of heuristics is of little use. Tell the real stuff if you want to convince = me --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig173B4E3F1D56A9809229CEDC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk0a734ACgkQNak7dOguQgl5ngD9EjEcbpGJlMOrpMyl1HS4dfYy M6+QtkT5D2UTvSRlcgoA/ipPt7LW/WcjuWcHZkg3stQuE7OgQKoWj0x8iSpz1Vb6 =S7KS -----END PGP SIGNATURE----- --------------enig173B4E3F1D56A9809229CEDC--