Rendszerindítás Minix3 Fájlrendszerről

Egyéb: Assembly, Ada...

https://gitlab.com/bztsrc/minix3fs

Egyszer csak tele lett a tököm, hogy mindenki a FAT-tel szív, amikor van sokkal egyszerűbb és jobb alternatíva, ezért valamikor régen összeraktam egy részletes leírást példakódokkal a Minix3 Fájlrendszerről. Már el is feledkeztem róla, de emiatt most valaki megkeresett és megkérdezte, hogyan lehet bootolni róla (mivel a Minix3 a NetBSD boot loaderét használja, ami szörnyű és nem igazán felhasználóbarát, a neten található összes bootszektor példa meg csak FAT-et tud). Szóval jogos volt a kérdés, nyilván egyik meglévő példa sem tud fájlokat betölteni MFS-ről.

Ezért úgy döntöttem, hozzáadok egy MFS bootszektor példakódot a repómhoz, ami Assembly-ben lett írva. Ez képes
- betölteni egy tetszőleges fájlt (kernelt vagy második lépcsős betöltőt) a Minix3 Fájlrendszerről,
- autodetektálja a formátumát (ELF, PE/COFF, a.out),
- parszeolja, betölti a szegmenseit és
- beállítja a neki megfelelő környezetet (protected mode vagy long mode).
Mivel ilyen okos, ezért ez a betöltendő futtatható már bármilyen magas nyelvből (C, Ada, Rust, Go, stb.) fordítható, nem szükséges az Assembly ehhez már.

A bootszektor forrását telepakoltam kommentekkel, de ha valakinek kérdése van, vagy talált egy bugot, akkor szóljon!

A repóban egyébként található egy függőségmentes, multiplatform mfsboot parancs is, ami képes telepíteni ezt a bootszektort egy Minix3 Fájlrendszer szuperblokkba. A betöltőnek nincs több komponense, mindössze a bootszektorból áll.

  • 555 megtekintés

( Raynes v | 2025. 03. 30., v – 13:16 )

Derekas projekt megint, de szerintem csak elméletnek jó. Ki akarna minixfs-ről bootolni? Eleve csak unix/like rendszerek támogatják, azok meg bootolnak a saját natív fájlrendszerükről is. Kivéve ha UEFI boot, mert akkor kötelező a FAT (ez lehet FAT12, 16, 32), a bootloadernek azon kell lennie, hogy megtalálja az UEFI firmware és bootolni tudjon róla.

Igen, a FAT egy ótvar, elavult, MS kutyulék fájlrendszer, de régi, lejártak róla a szabadalmak, vannak rá nyílt implementációk, és csak egy bootloader-betöltés erejéig ki lehet bírni. Ezt szabványosította az EUFI, ez van. Értem, ósdi, lassú, töredezik, nincs ellenállósága adatvesztés, áramszünet, stb. ellen, nem lehet hozzáférési jogokat beállítani (bár ezt a modern OS-ek meg a Secure Boot megoldják), de a boot partíción úgyse tárol az ember túl sok mindent, és nem kell annyira sebességre, meg redundanciára gyúrni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Abban gyaníthatóan nem hagyományosan bootoltatják, hanem valahogy mindjárt memóriaterületről futtatják, minimál setup-pal. Lehet a fájlrendszer minixfs mögötte, de akkor sem igényel a BIOS/UEFI-től rendes bootot. Meg szerintem az Intel teljesen átszabta magának a Minixet, nem tudom mit variálhattak rajta, nem látuk bele a kódba. Ez a BSD licenc átka, a származék kódokat nem kötelesek nyitva tartani. A GPL-nél ezt nem tudják megcsinálni, annak pont ez a lényege, hogy nem lehet a kódot később sem senkinek bezárni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Pedig azt hittem, van egy 3,5-es HDD a CPU-ban. :)

Azt csak azért írtam, mert egyrészt rögtön az ugrott be, másrészt, ha jó a MINIX3 az Intelnek, jó lehet másnak is, akinek akár lehet szüksége arra is, hogy minix3fs-ről bootoljon, mint ahogy azt a melléket ábra mutatja:

 most valaki megkeresett és megkérdezte, hogyan lehet bootolni róla

Abban gyaníthatóan nem hagyományosan bootoltatják, hanem valahogy mindjárt memóriaterületről futtatják, minimál setup-pal.

A Minix3 kernel nem is fájlokból bootol, hanem a kernele egy statikusan linkelt single binary, amiben eleve benne van minden, ami kell induláskor (az összes server és driver, bár külön taszkként inicializálódnak, de nem külön fájlból töltődnek be. A Minix2 még nem is tudott mást, a Minix3 már képes multiboot modulokat használni, de azok megint csak memóriabufferként adódnak át a kernelnek, szóval jöhetnek azok is akárhonnan, nem kell fájloknak lenniük).

De csak hogy tisztázzuk, itt most nem a Minix Operációs Rendszerről van szó, hanem csupán a fájlrendszeréről, ami másoknak is hasznos lehet. Pont úgy, ahogy a FAT-et sem csak a DOS használja, és az ext2 sem csak a Linuxé (lásd pl. SerenityOS, szintén ext2-t használ).

Ez jutott eszembe

Nekem meg az, hogy Linus is MFS-ről akart bootolni, amikor még kezdő volt és a Linux sokáig onnan is bootolt. De persze az még nem Minix3 FS volt, ami hiányossága volt akkoriban, azokat már kiküszöbölték az Minix3 FS-ben (pl. fájlnév nem 12 bájtos, hanem 60 bájtos).

Az ext használhatatlan, az ext2 már jó lenne, de az meg sajnos túl bonyolult. A Minix3 FS-t egy kellemes kompromisszumnak érzem bonyoltultság, implementálhatóság és funkcionalitás terén, szvsz ideális hobby projektekhez.

Igen, ezt is tudtam. Ezzel nincs is baj, mert akkoriban nem volt még olyan stabil fs a Linuxban, mint ma az ext4, XFS. Így ez akkor szükséges volt, ma már nem az, ahogy írtam már.

Mondom, nincs bajom sem a minix3fs-sel, se a Minix-szel. Csak a gyakorlati hasznát nem értem, hogy ki akarna erről bootolni. Meg azt se, hogy FAT-ról bootolni miért lenne szenvedés.

Még a Minixet se fikáznám, mert egy jó rendszer. Az az átka, hogy Tannenbaum nem engedett be sok mindenkit a fejlesztésbe, és sokáig proprietary licences volt, későn nyitotta ki, nem alakult ki köré fejlesztőtábor. Pedig a koncepciója jobban tetszik, mikrokernel, szeparálva futnak a driverek, minimalista kód, nagy lehetett volna benne a potenciál, ha kifutja magát időben. Pedig jó pár éve kapott egy 1 millió eurós fejlesztési támogatást, de nem kapott tőle szárnyra.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Mondom, nincs bajom sem a minix3fs-sel, se a Minix-szel.

Nem gondoltam a hozzászólásaid alapján, hogy esetleg lenne.

Csak a gyakorlati hasznát nem értem, hogy ki akarna erről bootolni.

Egyrészt nemcsak bootolni (azt is, de nemcsak), hanem úgy általában használni egy hobby projektben. (Ugye az általános használathoz hozzátartozik a bootolhatóság, de nemcsak abból áll.)

Az MFS célközönsége bárki, akinek a FAT ótvar, az ext2 (de pláne az ext4 és az XFS) meg túl komplikált. Szerény véleményem szerint nagyon jó kompromisszum funkcionalitás és bonyolultság között, és baj volt, hogy eddig nem volt hozzá rendes doksi meg betöltő. Na, most már van.

Meg azt se, hogy FAT-ról bootolni miért lenne szenvedés.

És ismét, nemcsak bootolásról van szó, hanem általános használatról. A FAT pedig önmagában is szenvedés és tárhelypazarlás, a 8.3 fájlnév manapság meg egyenesen vicc (LFN-t lekódolni meg nehezebb, mint MFS-t implementálni).

nagy lehetett volna benne [Minixben] a potenciál, ha kifutja magát

Ez csak a személyes véleményem, de szerintem sosem futhatott volna ki, méghozzá pont azért, mert túl sok volt benne a potenciál. Pl. nehéz rá kártékony kódot írni, mert nem lehet egy meghajtóbeli buffer overflow-val csak úgy tetszőleges kódot futtatni ring0-án, mint a Linux esetében. Az az alapkövetelmény, hogy egy UEFI rootkit bármikor kártékony kódot tudjon injektálni a kernelbe, már eleve elméletileg is felejtős a Minix esetén.

Úgy általánosságban azt figyeltem meg, hogy IT területen sosem a legjobb, hanem mindig a legszarabb terjed el, valahogy mindig a gagyit tolják a cégek. Ahhoz, hogy minőségre váltson a szakma, előbb mindig irtózatosan be kell fürdeniük a gagyival, máskülönben sosem lépik meg, csak ha már tényleg nincs más lehetőség.

Az utolsó bekezdéseddel is egyet értek, de én úgy látom ez nem csak IT területén van így.

Egyébként köszi és gratula! Közvetlen használni nem tudom, de elgondolkodtatott, hogy mikrokontrolleres környezetben dobjam a FAT-ot.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

de elgondolkodtatott, hogy mikrokontrolleres környezetben dobjam a FAT-ot.

Na, arra például tökéletes! Ha nem kell symlink, akkor még sokkal egyszerűbbé tehető a mfs.h (most se sok, 193 SLoC), és ha fixálod a blokkméretet 4K-ban, akkor meg a teljes memóriaigényét leszoríthatod 16K körülire, ami különösen előnyös egy mikrokontrollernél (mfs_data-nak, mfs_dir-nek elég a 4096, az mfs_buf-nak 8256 bájt, az mfs_fn meg egyáltalán nem is kell, ha nincs symlink).

( bzt | 2025. 03. 30., v – 15:36 )

Szerkesztve: 2025. 03. 30., v – 15:49

Ki akarna minixfs-ről bootolni?

Mindazok, akik jobb híjján most FAT-el szenvednek, mert az ext2 már túl sok lenne nekik.

De nemcsak bootolásról van szó (arról is, de nemcsak arról), hanem leginkább implementálhatóságról és interoperabilitásról. A Linux élből kezeli, de a repómban található FUSE meghajtó és Windows meghajtóprogram is hozzá, valamint user-space only toolok is.

Igen, a FAT egy ótvar, elavult, MS kutyulék fájlrendszer

Az, de jelenleg nincs igazán alternatíva, mert minden példakód csak FAT-et tud (esetleg ext2-es példa akad még, ha elég kitartóan keres az ember, de az meg egy hobby projekthez iszonyat overkill).

csak egy bootloader-betöltés erejéig ki lehet bírni.

A baj az, hogy a legtöbb projekt aztán megragad ezen a szinten az alternatíva hiánya miatt. Tök jó lenne látni, ha az olyan projektek például, mint a MenuetOS, KolibriOS, DexOS, BareMetal, Brutal, PDOS vagy akár a FreeDOS tudnának a FAT-en kívül bármi más fájlrendszert.

Nem állítom, hogy az MFS a legcélszerűbb választás egy hobby projekt számára, csak azt állítom, hogy SOKKAL könnyebb leimplementálni, mint a FAT-et vagy az ext2-t; és hogy csak azért nem használják, mert nem is tudnak róla (ezt az egyetlen MFS doksit sikerült csak felhajtanom a neten, nézd csak meg, milyen fos a minősége, a Minix3 forráskódja meg egy olvashatatlan katyvasz, MFS boot szektor példa meg nem is létezett egyáltalán ezidáig).

Eddig nem volt igazán választási lehetőség, most meg már van, a repóm a részletes dokumentációval és példaprogramokkal életképes alternatívát csinál az MFS-ből. Ha kell, kell, ha nem, nem, a lényeg, hogy most már választhatod ezt is. Ha a FAT túl ótvar, az ext2 meg túl bonyolult, akkor ez a neked való.