Quoting Marco Gerards <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] 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.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
