SELF

[Myles Watson]

Jordan,

Did you want to specify that the entry point is always the last self_header
in the segment table?  Your pseudo code suggests that for the streaming
load.  Maybe name and notes should always be first too.

Thanks,
Myles

[Jordan Crouse]

On 15/05/08 14:21 -0600, Myles Watson wrote:
> Jordan,
>
> Did you want to specify that the entry point is always the last self_header
> in the segment table?  Your pseudo code suggests that for the streaming
> load.

Yes, that is the intention.  I should make that clearer in the description.
> Maybe name and notes should always be first too.

I don't know if thats something we want to enforce in the design
(it all sort of depends on how you parse the ELF), but I think in
pratice it would be a good idea to put that information near the front to
avoid needless walking.

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.

Jordan

[Myles Watson]

> > Did you want to specify that the entry point is always the last
>
> self_header
> > in the segment table?  Your pseudo code suggests that for the streaming
> > load.
>
> Yes, that is the intention.  I should make that clearer in the
> description.

If there is always one and only one entry point, maybe it should be in the
LAR header.  It would help my mental process if on the SELF page you
described what information should be stored in the wrapper, whatever it
happens to be.  I'm thinking of path, size, entry point...

To speed up walking, maybe we should put a lower limit on LAR entries like
1KB.  Since there is a SELF structure, what would we want that was smaller
than 1KB?  It seems like the fragmentation might be worth it for the small
number of LAR entries likely to be in any image.
> > Maybe name and notes should always be first too.
>
> I don't know if thats something we want to enforce in the design
> (it all sort of depends on how you parse the ELF), but I think in
> pratice it would be a good idea to put that information near the front to
> avoid needless walking.

That makes sense.
> 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.

Besides the name of the application to run and maybe a brief description,
what else would a payload want to pass to chooser?

Thanks,
Myles

[Jordan Crouse]

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

[Peter Stuge]

On Thu, May 15, 2008 at 05:19:14PM -0600, Jordan Crouse wrote:
> 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";

I like it!

Does bayou show the name? I would prefer that over the listname.
Or maybe both.

//Peter

[Jordan Crouse]

On 16/05/08 01:40 +0200, Peter Stuge wrote:
> On Thu, May 15, 2008 at 05:19:14PM -0600, Jordan Crouse wrote:
> > 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";
>
> I like it!
>
> Does bayou show the name? I would prefer that over the listname.
> Or maybe both.

Its a good discussion to have.  One one hand, its nice to have 'coreinfo'
in the list, but on the other hand, a newbie would probably prefer a menu
that said:

Look at system information
Boot a kernel

So its a fine line between smaller code, better descriptions, and not biting
the newbies.  But this is part of the reason why the NAME segment didn't work 
- clearly there are levels of information that the payload needs to
provide between the binary name and the overly verbose description.

Jordan