Újabb fejlemények!
UEFI is kidebuggolva, SecureBoot támogatás megoldva (shim), és egy csomó beépülő elkészült. Lett egy új beépülő típus is, ami tetszőleges adatokkal tudja kibővíteni a kernelnek átadott boot infót.
Támogatott kernelek:
Linux (mindet ugyanaz a beépülő támogatja):
- BIOS alatt
- UEFI alatt
- Raspberry Pi-n
Windows
- UEFI alatt (SecureBoot az kell hozzá, ugye; de beépülő nem)
OpenBSD
- BIOS alatt (saját beépülővel)
(UEFI-s bootolót nem találtam a miniroot74.img-ben, mindössze két fájl van a boot partíción, "boot" és "bsd", de elvileg csont nélkül mennie kell)
FreeBSD
- BIOS alatt (saját beépülővel)
- UEFI alatt (loader.efi-t hívva, beépülő nélkül)
FreeDOS
- BIOS alatt (saját beépülővel)
(UEFI-t maga a DOS nem támogatja)
Egyszerűsített Multiboot2 protokoll a könnyebb hobby OS kernel íráshoz:
- ELF64 / PE32+ (BIOS, UEFI és RPi, beépülő nélkül)
- ELF32 (BIOS, UEFI, védett módban indul)
- a.out (BIOS, UEFI, védett módban indul)
- bővített Multiboot2 lista (pl. átadja az EDID infót is, ami az eredeti specben nem szerepel)
- nincs szükség beágyazott bináris marhaságra (ELF, PE, a.out fejlécet értelmezi oszt jóccakát')
- tisztán 64-bites kernel belépési pont (nincs szükség trampoline kódra, mint a GRUB esetén)
- ha a kernel az indulása korai szakaszában elszállna, akkor részletes és értelmes hibaüzenet ad (kerneltől függetlenül működik, már amíg a kernel be nem állítja az IDT-t/VBAR-t)
- képes a kernelt minden processzormagon egyszerre elindítani (SMP-t nem tud a GRUB, de az Easyboot igen ;-P)
- ha kell, akkor van egy beépülő a GRUB szimulálására, annak összes nyűgjével, így olyan kernelek is betölthetők, amik esetleg GRUB bugra támaszkodnának
Érdekességek
BSD-k esetében úgy döntöttem, hogy a betöltőnél kapcsolódok be, és nem direktben a kernelnél. Ennek több előnye is van: egyrészről így müködnek a boot szkriptek (Lua és társai), a sokféle konfiguráció a különféle modulokkal és akkor sincs gáz, ha változna a kernel dinamikus linkelése. Továbbá így csont nélkül támogatott nemcsak az UFS-ről, de a ZFS-ről való bootolás is.
UEFI esetében külön gond volt, hogy még a referencia TianoCore sem felel meg a szabványnak. Az azt írja ugyanis, hogy a DevPath elhagyható, ha bufferből töltődik be a futtatható, pedig valójában nem is, nemcsakhogy kötelező megadni, de érvényesnek is kell lennie, különben nem indul el az UEFI App. Szóval szívtam egy sort ezzel: ha a kernel a boot partícióról töltődik be, akkor nincs gond, átadom, amit én is kaptam, viszont ha root partíció lett megadva, akkor nekem kell összerakni a hozzá tartozó DevPath-ot; továbbá ha valami miatt nem sikerülne lekérni, akkor is át kell adnom valami érvényes DevPath-ot (ilyenkor a fallback az, hogy egy memory-mapped pathot generálok).
További újjítás a Simpleboot-hoz képest, hogy az ikonok immáron tartalmazhatnak alfa csatornát (pixelenként különböző átlátszóság). Ez azért érdekes, mert a háttérszín dinamikusan állítható. Itt meg abba futottam bele, az ImageMagick nem tudott alfa csatornát menteni TGA esetén, az új GIMP meg bugos lett és már nem képes rá (régen tudta, de már elmúlt). A megoldás az lett, hogy leimplementáltam ImageMagick-be (már beolvasztották, ha letöltitek a legfrissebb verziót, az már tudni fogja). Szóval convert (bármilyen kép) -colors 256 -compress RLE ikon.tga, és ha az eredeti képben volt alfa csatorna, akkor a végeredmény TGA-ban is lesz.
Felkészülnek
A fájl rendszer támogató beépülők (ext, ufs), hogy a kerneleket ne csak a boot partícióról, de közvetlenül a root partícióról is képes legyen betölteni.
Igazából már ezek is elkészültek, de sajnos belefutottam egy csúnya Clang fordító bugba, egyelőre még nem találtam rá kerülőmegoldást, de még nyomozok. A gond konkrétan az, hogy hiába használ pozíciórelatív címzési módot az x86_64, és hiába adom át az "-fno-plt" kapcsolót neki, mégis generál PLT-ket és PLT relokációkat szimpla statikus, lokális függvényhívásokhoz. Érdekes módon csak azokhoz, és ott sem mindig, a futásidőben dinamikusan linkelt függvények (ahol még lenne is értelme a PLT-nek) ellenben jól működnek, helyes, PLT nélküli relokációk generálódnak hozzá. Ez azért para, mert fájlrendszer beépülők esetében mindenképp szükséges pár dolgot helyi függvényekbe kiszervezni. (Megj: ARM alatt nincs gond, ott figyelembe veszi a "-fno-plt" kapcsolót a Clang fordító.)
Szóval a fájlrendszer beépülők jelenleg csak gcc keresztfordítóval fordíthatók emiatt, az alapértelmezett Clang-gal nem; ezért nem commitoltam még őket.