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