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__((__used__)) \ __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(name,"coreinfo"); PAYLOAD_PARAM(listname,"System Information"); 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 system";
All of these will end up in the .notes.pinfo section of the ELF as null terminated strings.
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.
Thoughts? Jordan