jordan.crouse at amd.com
Fri May 16 01:19:14 CEST 2008
On 15/05/08 14:40 -0600, Jordan Crouse wrote:
> I'm working on this part of the chooser right now, and so the existing
> design is probably subject to change as I'm learning interesting things
> about how the ELF works and how we interact with it. I'm also trying to
> think about how to configure the chooser behavior, and I think that the
> payloads will need some way to communicate information to the
> chooser, and it will probably come in through either NAME or NOTES or
> some future combination of both.
So, after some playing, I've come up with some ideas:
#define PAYLOAD_PARAM(key, value) \
static const char _pstruct(key) \
__attribute__((section(".note.pinfo"),unused)) = #key "=" value
In the same fashion as the kernel module macros (MODULE_LICENSE, etc),
this macro can be used to pass information to the chooser. Consider
the following in coreinfo:
PAYLOAD_PARAM(desc,"Display information about the system");
These will be expanded out as
static const char _pstruct[_pinfo_name] = "name=coreinfo";
static const char _pstruct[_pinfo_listname] = "listname=System Information";
static const char _pstruct[_pinfo_desc] = "desc=Display information about the
All of these will end up in the .notes.pinfo section of the ELF as null
The ELF parser in LAR will take this section and put it into the ELF as a
PARAMS segment, replacing the NOTES and NAME segments. The strength of
the params segment is that it can have unlimited options, at the cost of
more string parsing in bayou, which i don't think is a bad thing.
I implemented this, and it seems to work pretty well. I went ahead and
updated the wiki pages, but as always, this is a draft and can change.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot