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