On Wed, 2009-01-28 at 21:57 -0500, Pavel Roskin wrote:
> On Tue, 2009-01-27 at 08:19 +0100, Michel Dänzer wrote:
> > I was able to reproduce Jordi's findings on my PowerBook G4. (Well,
> > except device.map seems to get generated correctly and the search
> > command seems to work for me, maybe this is due to differences between
> > our OF device trees or something like that)
> >
> > After some printf-style debugging over the weekend, the failure to load
> > some modules indeed turns out to be an hfs.mod bug: the problem is that
> > strncasecmp() doesn't match the HFS B-tree sort order, which in
> > particular breaks lookup of files with an underscore in their name. The
> > first attached patch fixes this using a lookup table from Linux
> > fs/hfs/string.c.
>
> Actually, the return value of grub_strncasecmp() was incorrect until
> recently. Maybe the current version would work for you?
Unfortunately not; I verified with a simple program that the glibc
strncasecmp() also has a different order between underscore and
characters. The HFS sort order seems quite peculiar.
> I'm not against your patch, but I'd like to understand how important it
> is for GRUB.
The failure to look up some files on HFS filesystems makes it hard for
most PowerPC Mac Linux users to switch from yaboot to GRUB.
> Please write a ChangeLog entry for the patch.
How about this:
2009-01-29 Michel Dänzer <mic...@daenzer.net>
* fs/hfs.c (grub_hfs_cmp_catkeys): Use lookup table for HFS
B-tree sort order. Otherwise we fail to look up some files,
e.g. with an underscore in the name, so e.g. the _linux module
can't be loaded from an HFS filesystem.
> > The failure to auto-load some modules like search was also caused by
> > this, the auto-loading process aborts after failing to load a module. It
> > might be better to continue auto-loading other modules anyway.
>
> Patches are welcome. With explanations, please.
Just tossing out an idea.
> > BTW, I also need the second attached patch to be able to boot my
> > self-built 32 bit kernels configured to support 2GB lowmem.
> > elf->ehdr.ehdr32.e_entry ends up as 0x70000000.
>
> Strange. The original mask should ensure that elf->ehdr.ehdr32.e_entry
> is less than 0x40000000.
Right, that's the problem. :) Apparently the kernel's early boot code
relies on it remaining unchanged.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
