fef65bd375
At the front is btxldr, in the middle is BTX itself (our mini-kernel), and then the 'client' (loader.bin) which is the actual loader itself. boot2 just executes a raw ELF or a.out binary with the only setup provided being that a bootinfo structure is passed on the stack. Now, since loader.bin is a BTX client, the loader needs to be able to locate a BTX kernel for the client to execute in the context. Thus, just like pxelder, btxldr uses the a.out header on the loader binary to find the BTX kernel stored in the loader and set it up. It does _not_ just reuse the BTX kernel that boot2 invoked it with. This is because it can't assume that it will _have_ a "spare" BTX kernel lying around. For example, when cdboot loads the loader there isn't an existing BTX kernel. In fact, cdboot will only work with an a.out loader as well since it also "borrows" the BTX kernel in the loader binary (which it finds by parsing the a.out header) just as pxeldr does. The only difference between cdboot and pxeldr is where they get /boot/loader from. If we wanted to make /boot/loader be an actual ELF binary we would need to change the following utilites to handle that (and they all have to be able to handle locating the BTX kernel inside of an ELF binary somehow): - btxldr - pxeldr - cdboot If we didn't want to require a flag day but make the transition smooth then we need to be able to support both a.out and ELF versions of /boot/loader which isn't exactly trivial since all three of these utilities are written in assembly. Pointy-hat to: peter |
||
|---|---|---|
| .. | ||
| boot0 | ||
| boot2 | ||
| btx | ||
| cdboot | ||
| gptboot | ||
| kgzldr | ||
| libi386 | ||
| liloldr | ||
| loader | ||
| mbr | ||
| pxeldr | ||
| Makefile | ||
| Makefile.inc | ||