From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LWpLJ-0007vT-V3 for mharc-grub-devel@gnu.org; Tue, 10 Feb 2009 04:55:49 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWpLI-0007uc-SC for grub-devel@gnu.org; Tue, 10 Feb 2009 04:55:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWpLI-0007ti-7U for grub-devel@gnu.org; Tue, 10 Feb 2009 04:55:48 -0500 Received: from [199.232.76.173] (port=35650 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWpLH-0007tc-Ns for grub-devel@gnu.org; Tue, 10 Feb 2009 04:55:47 -0500 Received: from darkcity.gna.ch ([195.226.6.51]:46349 helo=mail.gna.ch) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LWpLG-0005Sj-UX for grub-devel@gnu.org; Tue, 10 Feb 2009 04:55:47 -0500 Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id 776D4C6650; Tue, 10 Feb 2009 10:55:46 +0100 (CET) X-Virus-Scanned: amavisd-new at gna.ch Received: from mail.gna.ch ([127.0.0.1]) by localhost (gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts+rwWn5mpyw; Tue, 10 Feb 2009 10:55:46 +0100 (CET) Received: from thor.local (217-162-255-249.dclient.hispeed.ch [217.162.255.249]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 14307C5A79; Tue, 10 Feb 2009 10:55:46 +0100 (CET) Received: from daenzer by thor.local with local (Exim 4.69) (envelope-from ) id 1LWpLF-0006TO-Lo; Tue, 10 Feb 2009 10:55:45 +0100 From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: Robert Millan In-Reply-To: <20090209141940.GA4841@thorin> References: <1233040781.5108.98.camel@thor.local> <20090207194859.GC988@thorin> <20090207233836.1yh2s7te1ccgo0wc-cebfxv@webmail.spamcop.net> <20090209141940.GA4841@thorin> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2009 10:55:44 +0100 Message-Id: <1234259744.5081.682.camel@thor.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Cc: The development of GRUB 2 Subject: Re: hfs patch (Re: State of GRUB on PowerPC) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 09:55:49 -0000 On Mon, 2009-02-09 at 15:19 +0100, Robert Millan wrote: > On Sat, Feb 07, 2009 at 11:38:36PM -0500, Pavel Roskin wrote: > > Quoting Robert Millan : > >=20 > > >On Tue, Jan 27, 2009 at 08:19:41AM +0100, Michel D=C3=A4nzer wrote: > > >>+/* > > >>+ * unsigned char caseorder[] > > >>+ * > > >>+ * Defines the lexical ordering of characters on the Macintosh > > >>+ * > > >>+ * Composition of the 'casefold' and 'order' tables from ARDI's code > > >>+ * with the entry for 0x20 changed to match that for 0xCA to remove > > >>+ * special case for those two characters. > > >>+ */ > > >>+static unsigned char caseorder[256] =3D { > > >>+=20 > > >>0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D= ,0x0E,0x0F, > > > > > >Could you be more specific about what the table contents mean? > >=20 > > Michel may know better, but I think it's the order of characters. =20 > > Those with the lower order go first in the sorted binary tree. Those =20 > > with the same order are equivalent on the filesystem level. That is, =20 > > "foo" can only be between "bar" and "quux" in the node tree. "foo" =20 > > and "Foo" are the same tree node and thus the same file. >=20 > I think what we need here is enough information so that someone can under= stand > what the table means I'm not sure what more information I can provide. :( > and be able to modify it if need arised. I think that's very unlikely: the Linux kernel code this is copied from hasn't changed at all since Linus started using Git for 2.6.12-rc, possibly much longer. > An undocumented table just looks like a "blob" of binary data. I guess to some extent it could be considered that - it's a blob which is needed to correctly interpret the blobs in an HFS filesystem. --=20 Earthling Michel D=C3=A4nzer | http://www.vmware.c= om Libre software enthusiast | Debian, X and DRI developer