From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWo2Y-00044w-9f for mharc-grub-devel@gnu.org; Sun, 26 Dec 2010 05:41:26 -0500 Received: from [140.186.70.92] (port=54420 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWo2U-00042U-W9 for grub-devel@gnu.org; Sun, 26 Dec 2010 05:41:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWo2T-0002qu-Qw for grub-devel@gnu.org; Sun, 26 Dec 2010 05:41:22 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:56596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWo2T-0002qb-Jt for grub-devel@gnu.org; Sun, 26 Dec 2010 05:41:21 -0500 Received: by wyj26 with SMTP id 26so8163218wyj.0 for ; Sun, 26 Dec 2010 02:41:20 -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=JBhQIjUy2o0Tcy3H+ILHjOqywON3owybN6RylMk8tJs=; b=JAFI+mhcfEN+ZhGgVTSvgl379zIYKpbPnRSHEChzkjcrmjBGS7HnB1mRSqKT8NBcAc yBTk3cZjUcbkbtSj2i2uFxOZH80VuMqKhHYAmV6RF3nfyCPIfJRtcKH0yjdOtonn79iU 6JMuwvCCC+afDJVK1ShLnGoUiY2KmtkZCAPe8= 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=kxcIUxb18XyIaDgyu+Y5Z8UL7SQRfyetWu1KwNwE9H314aAKMN+h4jnbQQIpnBwbIo e2w1dzECUpN/2lqdvwj+j7ntH4PupUNZlwzwLVq/LLJ/3zuhK9wUfpi+WSD37SopQNmU nHIvp3/RjtjOOk5jvuaLv5y6u2XxLibaOfxoU= Received: by 10.216.173.75 with SMTP id u53mr11763479wel.79.1293360080488; Sun, 26 Dec 2010 02:41:20 -0800 (PST) Received: from debian.bg45.phnet (47-30.2-85.cust.bluewin.ch [85.2.30.47]) by mx.google.com with ESMTPS id r6sm5286227weq.20.2010.12.26.02.41.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 26 Dec 2010 02:41:19 -0800 (PST) Message-ID: <4D171BBC.9000506@gmail.com> Date: Sun, 26 Dec 2010 11:41:00 +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: <201012260529.oBQ5Tj6w069781@m5p.com> In-Reply-To: <201012260529.oBQ5Tj6w069781@m5p.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFF42BF4C9A0D202C44B6AB15" 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: Sun, 26 Dec 2010 10:41:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFF42BF4C9A0D202C44B6AB15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/26/2010 06:29 AM, ehem+grub@m5p.com wrote: > >>> stage. Second, perhaps minor, but I'm surprised someone chose to brea= k >>> the checksum verification code in grub-core/partmap/sun.c and didn't >>> didn't keep the magic number check with it. >>> =20 > =20 >> This seems to be just moving the code around. There are many different= >> coding styles. Changing from one of them to another is waste of effort= >> unless it's done to uniformise with rest of codebase. I don't have >> strong preference to one or another style so I prefer not to touch any= thing. >> =20 > Leaving it alone for now is fine by me. I just found it rather strange = to > see two distinct styles in the exact same bit of code. I'd expect eithe= r > all of the verification or none of the verification broken into a > distinct function. > > =20 checking magic number is a simple check (a =3D=3D b) whereas checksum che= ck is a composite (you need to compute checksum first) so moving checksum out in a separate function makes sense > I will in fact be implementing breaking detection functions into distin= ct > functions uniformly, I'm not fond of "let's change it just because we can". There are much more real tasks on the project. Come to #grub and I'm sure will find something for you. > because there is a deeper issue lurking here. Looks > to be pure luck no one ran into an unpleasant bug lurking in the existi= ng > design. > > =20 Please show me the real problem then. > (I can readily provide an illustration of the lurking landmine, later > though) > > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigFF42BF4C9A0D202C44B6AB15 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/ iF4EAREKAAYFAk0XG7wACgkQNak7dOguQglU8QEAkTsyP7ANTNovd5nZU/HuTWNm 7dO4myafDnMzCSaZjL8A/RI1nc8X8iAlB8VaMluSnyoXrkigwA/W+8jahYyWqxZT =gSCv -----END PGP SIGNATURE----- --------------enigFF42BF4C9A0D202C44B6AB15--