* Patrick Georgi patrick@georgi-clan.de [070627 20:54]:
I got quite far with adding decompression to lar (lzma'd data runs fine, nrv2b decompression seems to hang), but ran into issues that need discussion.
Wow. I would have expected this the other way round.
Currently, two files in the lar archive are parsed directly out of rom (using the find_file function which returns a pointer to there). One of them is "option_table", a 900 byte file (which compresses to 350 or so), where I could live with it staying uncompressed in image.
You read the option table in grub2? Why? (sorry I think we talked about it but it slipped away in the patch orgies of the recent days.
Config options should be parsed from the LinuxBIOS table like lxbios does it.
My current work around, is to just define a place in memory where to decode it to and then load the ELF image from there.
I think this is the same on v2's compressed payload, is it?
This complicates ELF loading as now there is a risk that the raw ELF file and the ELF image overlap. (Right now, I just use an address that I know is beyond the ELF's range)
Can we use the very low or very high memory for this?
Jordan's talk here at the OLS described how LinuxBIOS relocates itself from the very low space to TOM during the boot process. I think we should think carefully about this stuff. Will any OS ever claim to be copied into the low 1M?
I propose a new API for the ELF loader that hides this issue and ensures that decompression works fine. It would be used like this: copy_elf(&archive, "normal/payload", &entrypoint, &last_address)
Is this going to replace int elfboot_mem(struct lb_memory *mem, void *where, int size)?
I am not really sure I understand the issue completely yet.
Specifically, I'd like to see this for the grub2 support I work on, as it's very trivial to just push the modules as "payload.data" into the lar archive, load it right behind the ELF image and have grub2 find its modules at _end.
Could you create a lar-fs for grub2 that is always compiled in for LinuxBIOS? Then the modules could be easily loaded from there (plus a kernel, a menu.lst and all the other stuff that we might want to put there)
Would such an FS solve your specific problem? Would we still need to solve the generic problem?
Stefan