Re: Grub for ia64

[tgingold]

Quoting Marco Gerards <address@hidden>:

> address@hidden writes:
>
> >> 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.
>
> Please elaborate.
The prefix is determined from an EFI file path.  This file path may have
some components in upper case.  However grub can't match a mixed file name
with a FAT directory entry.
We could either fix this by lowering the EFI file path or fixing the fat fs.

> >>  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.
>
> Well, I am afraid the same problem will show up when using HFS+, ext2
> or whatever. So that is why I would like a detailed description of
> this problem (I just know there is a problem, but never received a
> detailed report).
>
> >> > [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.
>
> Ok.  Your patch relies on that?  so would those have to go in first?
No, No.  Completly independant.

> >> > * 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.
>
> Why not?  In the internal working of filesystems there are also
> function pointer being used.  Same for almost every other part of
> GRUB 2.  So I am wondering what makes this different.
Function pointers works on ia64 (of course!)  But you can't convert an address
to a function pointer.  This cast is not valid on ia64 (and violates the C
standard).

> >> > * 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.
>
> Well, it's use can certainly be brought back or changed.  But adding a
> module loader is not the way to go.  If it bothers a lot of people I
> could change functions like grub_dl_ref into a macro which does the
> #ifdef.
I have never suggested to add module loader to grub-emu!

> >> 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 ?
>
> For the PPC I once wrote a module loader (userspace).  Some
> relocations expect the symbols you point to from the relocated code,
> to be within 4MB.  The dynamic loader on the PPC perhaps has no
> problems with that because it can load code about everywhere and
> perhaps those relocations are normally not used, but I can be wrong.
These problems are very common.
You should compile with -fpic!

Tristan.