mylesgw at gmail.com
Thu May 15 22:56:24 CEST 2008
> > Did you want to specify that the entry point is always the last
> > 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
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?
More information about the coreboot