On 19.08.2007 20:14, Uwe Hermann wrote:
here's a first (draft) implementation for having multiple LinuxBIOS payloads in one image, which will be executed one after the other.
The current implementation has the following limitations:
- Payload files must be named 'payload[0-9]', i.e. payload0, payload1, etc. Actually, you can specify the prefix (e.g. 'payload') via Kconfig.
Can we tell the implementation in some way that we'd like it to ignore payloads with numbers before x?
- All payload files must be in the same target directory (which can be specified via Kconfig).
I'd like not to introduce/keep such limitations.
- The payloads are executed in order, i.e. first payload0 is executed. When that is done and returns control to LinuxBIOS, payload1 is executed next, then payload2 etc. etc.
Can one payload decide which payload to run next? For example, lbmenu might want to make sure the netboot payload is run instead of FILO.
What state do the stack/registers have to be in for returning control to LinuxBIOS? Do we assume anything about the state of the machine after the payload has returned control? Can we flag a payload as "terminal" in the sense that if control is ever returned from it, we should reboot? Think memtest (which overwrites RAM) etc.
Oh, and how would this mesh with Ron's current LAR extension proposal?
Regards, Carl-Daniel