Re: Grub for ia64

[tgingold]

Quoting Marco Gerards <address@hidden>:

> address@hidden writes:
>
> Hi,
>
> > this is a port of grub2 to ia64.  ia64 systems (itanium) are EFI based so
> this
> > port reuse existing EFI infrastructure.
>
> This is truly great, thanks a lot for doing this! :-)
>
> First of all, the same comment as for your other emails.  Please use
> diff -up and inline the patches and write changelog entries.  I like
> that you split up the patches so they can be reviewed and separately.
>
> Next week or weeks I will be quite busy and won't have time for GRUB
> hacking or to review patches.  But I will try to do so ASAP, or
> hopefully Okuji will have the time to do so.  I hope you will be
> patient, I want this in ASAP. :)
>
> > fat.diffs: fix 64bits issues and make filename match case insensitive.
>
> Can you please explain why you want this in detail?  I know there are
> issues with EFI to determine the prefix.  My guess is that is why you
> want to change this.
Yes.

>  But I am afraid this might not be a generic
> solution so I hope we can discuss the problem first.
I suppose you can't use mixed case filename currently for FAT fs.  This
patch fixes that.

> > [I think most 64 bits issues have already been reported recently and
> > independently by the mail grub2 64bit system compatible]
>
> Cool.  I assume these patches are in CVS now?
AFAIK not yet integrated.

> > modules.diffs:
> > currently the ia64 port cannot load modules.  This patch makes slight
> changes
> > so that grub can be completly prelinked without removing the dynamic
> loading
> > feature.
> > I think it is worth for three reasons:
> > * it makes initial port easier.
>
> Right, we had that with the PPC port too.  I will have a look if it
> doesn't break anything for other archs.
>
> I hope you are willing to implement whatever is required for module
> loading for IA64.  Module loading is an essential part of the GRUB 2
> design and I prefer having the same behavior for every port.
Sure.

> > * the current common code can't work on ia64 (on ia64 a function pointer is
> a
> > descriptor and not the address of the first function instruction).
>
> Can you give some examples by using code?  Certainly we would have to
> aim for module loading at some point in time. :)
Yes, cf kern/dl.c:

          if (grub_strcmp (name, "grub_mod_init") == 0)
            mod->init = (void (*) (grub_dl_t)) sym->st_value;

This won't work on ia64 AFAIK.

> > * grub-emu doesn't have dynamic modules and could reuse this work to remove
> > most of #ifdef/#endif GRUB_UTIL
>
> *Please* do not mess around too much with grub-emu.  I can perfectly
> understand why people want all kind of things changed in grub-emu and
> I would certainly like to have module support there (IIRC there were
> patches sent in, some of which I still have to review, etc :-/).
>
> It's important to know why I wrote grub-emu.  It is mainly a debugging
> tool.  For example you don't want to implement a filesystem or work on
> the commandline interface without such tool.  Having module loading
> only is just annoying so GRUB_UTIL can't and won't be removed.
>From my point of view, GRUB_UTIL could be removed without adding modules
to grub-emu.  This would be slightly cleaner.

> Actually, it is technically almost impossible to do modules loading in
> every case on every processor.  For example take the PPC, some
> relocations are almost impossible or very hard to implement in
> userspace.
Looks strange.  How does ld.so works on these systems ?

> > I have also written a few additionnal EFI specific commands I will post
> later.
>
> I am looking forwards to your patches.
Ok.

Thanks,
Tristan.