On 8/28/07, Stefan Reinauer stepan@coresystems.de wrote:
- Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [070828 01:54]:
What about creating directories for each payload so we can differentiate between multiple payloads (in the original sense)?
Yes, I would prefer something like that, too
done. normal/payload/segment0 normal/payload/segment1 etc.
Maybe we should introduce a major/minor version in the LAR header? Or a different magic string for each revision?
I generally hate versions. Think features, not numbers. But since this is probably not doable without significant overhead, I'd just go with a normal version header that gets increased every time we change the format. No need for major, minor, subminor, ...
but then you have to handle the versioning, and figure out what to do if it does not match, and .... Let's not do this.
void *start; int len; u32 reallen;
- void * entry;
- void * loadaddress;
void *entry; void *loadaddress;
Not sure how these pointers sneaked in here. They do break portability and cross compilability. Compiling LinuxBIOS on a 64bit host without compiling lar 32bit is not possible with such things in the header.
I think you guys have missed the point. These are in the mem_file struct, and that struct is by definition a per-machine struct. There is NO cross-compatibility issue with mem_file -- see include/lar.h. mem_file is not even defined in util/lar/lar.h. The lar utility doesn't know what it is.
What was that linker auto rename trick that Marc mentioned recently?
The naming is not the issue. The issue is getting gcc to do abs calls, not relative calls, for some symbols.
Let's do this instead:
INITRAM_OBJ = $(obj)/mainboard/$(MAINBOARDDIR)/PICOBJ/initram.o
and have a rule that handles all PICOBJ objects differently?
As long as you agree to write it, I don't know how :-)
Or why not just PICFLAGS for pic objects?
New patch attached with new payload naming. But I am not changing the void * you mentioned, because I don't think it's a problem (there was already another void * in the mem_file struct before I got there!)
thanks
ron