Re: Grub for ia64

[Marco Gerards]

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.

>>  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?

>> > * 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.

>> > * 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.

>> 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.

--
Marco