[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Grub for ia64
Re: Grub for ia64
Thu, 28 Sep 2006 16:49:24 +0200
Internet Messaging Program (IMP) 3.2.5
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
> >> > * grub-emu doesn't have dynamic modules and could reuse this work to
> >> > 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
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!