> Tehát ebbe az image-be bele lehet pakolni több kernelt
Persze.
> fel kell mount-olni loop device-ként, s a config módosítása után boot-olja a másik kernelt?
Annyira, hogy példa kernelek mappájában a Makefilenak van egy "make mnt" opciója is, ami csuklóból megteszi ezt (Linux alatt, csak mert lusta vagyok mindig becsépelni a mount parancsot a sok kapcsolóval)
https://gitlab.com/bztsrc/simpleboot/-/blob/main/example/Makefile#L48
> Új kernel hogyan kerül bele?
Hát felmountolod és rámásolod. Ennyi. A fájlrendszert bootoláskor értelmezi, ezért új mappák, új fájlok, meg töredezettség tök mindegy, nem számít.
> így aztán fogalmam sincs, mi van egy PC-n, hol van az entry point, mit kell előtte tenni, hogy abból ne legyen baj, mi lesz az IT vektorokkal, a stack inicializálásával, mi van a hardware, például RAM frissítés initjével, ezekre kell-e figyelni, s ha igen, akkor kinek és hol.
Hát ez bizony jó sok kutatómunkát igényel, ráadásul többhelyről kell összevadászni.
- BIOS alatt a BIOS Boot Specification (https://www.scs.stanford.edu/nyu/04fa/lab/specsbbs101.pdf) a mérvadó, bár elég srendliánul implementálja néhány förmver. Ami biztos, hogy az elsődleges lemez (ha merevlemez nincs, akkor floppy) első szektora betöltődik a memóra 0:7C00-ás címére, és a meghajtó kódja a DL regiszterbe kerül. Ennyi, kábé semmi másban nem bízhatsz. Még abban sem, hogy az a cím tényleg 0:7C00 és nem 7C0:0 (vicces valós módú címzés miatt e kettő ugyanaz a lineáris cím, de tök más szegmenssel). Mindent neked kell csinálnod, a processzor inicializálst, a fájlrendszer értelmezést, stb. Simpleboot esetén a legnagyobb kihívás az volt, hogy egy egy szektornyi kód képes legyen inicializálni a processzort, betölteni egy fájlt a lemezről, majd értelmezni a COFF/PE futtathatót és relokálni a szekcióit... NAGYON kevés az a 446 bájt (512 a szektor mínusz a partíciós tábla mínusz magic bájtok).
- UEFI alatt az UEFI Specification (https://uefi.org/specifications) mondja meg, mi történik. Na ez az igazi agyfasz, de lényegében az első merevlemezről betölti a GPT-t, és megkeresi rajta az ESP partíciót. Ezt követően végigveszi a BootOrder nevű NVRAM változóban felsorolt fájlokat, és megpróbálja betölteni őket. Ha egyiket sem találja, akkor összerak egy "EFI/BOOT/BOOT(architektúrakód).EFI" path-ot, és azt is bepróbálja. Ennek egy relokálható, Picipuha COFF/PE futtathatónak kell lennie, speciális kóddal a fejlécben (a Simpleboot BIOS-os szektora ugyanezt a fájlt tölti be). Az igazi szívás vele az, hogy még a szabványnak megfelelő förmverek is totál inkompatíbilisek egymással, mivel valami agyhalott dinamikus interfészeket rakott bele... Az egyik hw gyártó ilyen interfészekkel szállít, a másik amolyannal. Szerencsére igyekeztem minimálisan tartani, így ami nekem kell, az a 2.0-ás förmverek mindegyikében benne szokott lenni. Régebbi gépeken, 1.0-ás förmverrel vagy megy, vagy nem. Inteles mac-eken tutira nem, mert azok nem szállítják a GOP interfészt, amire szükség van a framebuffer inicializáláshoz (Apple-ék UGA interfészt szállítanak ugyanis). Szóval ja, brainfuck a javából.
- kernel esetében pedig mind a formátum, az entry point, az elvárt lapozás, a bemeneti paraméterek, szóval minden tök más kernelenként (és még architektúránként is, ugyanannál a kernelnél). Ezért szokás ezek összességét külön "boot protocol"-nak hívni. A Multiboot2 nem egy nagy eresztés, sok szívás van vele (pl csak x86 32-bites kernelekhez írták, a 64-bitet utólag erőltették bele, nem is sikerült jól, több architektúra támogatás meg még mindig nincs), viszont annyi előnye van, hogy kernelfüggetlen szabvány, így senki nem túrkálhat önkényesen bele, többnyire stabil környezetet jelent.
> Amúgy vicces volt olvasni a commentben, hogy az NMI tiltása, tekintve, hogy az NMI nem maszkolható megszakítást jelent. :)
Igen. Ráadásul az AMD64 Developers Manual fapofával leírja, muszáj tiltani long mode-ba való kapcsolás előtt, azt, ami elvileg nem is letiltható :-) Ennél egyébként már csak a "Keyboard not found, press F1 to continue" BIOS hibaüzenet zseniálisabb!