Minixes tapasztalatok

Egy interjúban Tanenbaum ezt mondja: "Monolithic kernels are only used on systems where the reset button is considered a good solution to bad software". Értse ezt mindenki, ahogy akarja. Mindenesetre Tanenbaum sem egy mimóza.

Tudom, hogy semmi értelme, de engem az érdekel, hogy van-e olyan szinten a Minix, hogy portoljam rá a CCC-t. Elkezdtem ezért nézegetni, hogy s mint működik rajta a fordítás.

A doksi a pkgsrc-ből való fordításra a

figlet

csomagot hozza fel példaként, hát én is azzal próbálkoztam először. Az eredmény:

                 _
 _ __  _ __ ___ | |__   __ _   ___ _______ _ __ ___ _ __   ___ ___  ___ 
| '_ \| '__/ _ \| '_ \ / _` | / __|_  / _ \ '__/ _ \ '_ \ / __/ __|/ _ \
| |_) | | | (_) | |_) | (_| | \__ \/ /  __/ | |  __/ | | | (__\__ \  __/
| .__/|_|  \___/|_.__/ \__,_| |___/___\___|_|  \___|_| |_|\___|___/\___|
|_|                                                                     

Nem mértem, de a fordítás 30-60 percig tartott. Ok, kvm nélkül a qemu piszok lassú. A lassúság fő oka mégis a minix. Részletezem az élményt. Az idő nagy részében ilyesmi látszik:

Checking for long long...

Eltelik 10-20 másodperc -

yes

. Na végre. Így persze könnyen összegyűlik az 60 perc. Nézegetem mire használja a processzoridőt. A minix (tehát nem a natty, hanem az emulátorban futó minix) topjában ilyesmi látszik:

62 processes: 1 running, 61 sleeping
main memory: 2078372K total, 1799088K free, 1779928K contig free, 158128K cached
CPU states:   4.41% user,  42.97% system,  52.62% kernel,   0.00% idle
CPU time displayed (press 't' to cycle): user 

  PID USERNAME PRI NICE    SIZE STATE   TIME     CPU COMMAND
    7 root       5    0   1228K        74:32  20.14% vfs
   12 root       2    0   2032K        45:28   9.20% vm
   28 root       7    0    884K   RUN   1:54   5.58% procfs
   62 service    5    0  48752K        32:18   3.78% mfs
 1921 vermes     7    0    708K         0:00   2.96% top
   37 service    5    0   6012K        24:25   2.35% mfs
    5 root       4    0    212K         8:21   1.83% pm
 1373 root       7    0    648K         0:00   1.29% sh
   89 service    7    0    100K         0:00   0.15% random
   10 root       1    0    236K         0:26   0.05% tty
    6 root       4    0     32K         0:17   0.04% sched
  104 service    7    0    196K         0:04   0.01% rtl8139
    4 root       4    0    324K         0:00   0.00% rs
    8 root       3    0   3444K         0:03   0.00% memory

Ezek az adatok nagyjából tipikusak fordítás közben, bár a user CPU gyakrabban 2-3 mint 4%. Ez azt jelenti, hogy a tényleges feladatra a CPU idő 3%-a fordítódik. A top lista állandó éllovasai a vfs (virtual fs), vm (virtual memory manager), mfs (minix fs), ezek a system CPU-t fogyasztják (feltételezés). A kernel (az a bizonyos hatezer sor) tipikusan 50-60%-ot fogyaszt. Nagyon sokáig kell figyelni, hogy a topban egy-egy pillanatra felbukkanjon a gcc vagy a cc1. Összehasonítás képpen NetBSD-n hasonló fordítás közben a user CPU 20-50% között mozog. Következtetés: a NetBSD legalább 10-szer hatékonyabban használja a processzoridőt.

Hogy világosabb legyen. A gép fordít. Eközben a kernel (6000 sor) elfogyaszt 50% CPU-t, de a kernel maga biztosan nem fordít. A vfs (absztrakciós réteg a konkrét fájlrendszer felett) elfogyaszt 20%-ot, de a vfs maga biztosan nem fordít (sőt még csak konkrétan nem is ír/olvas, hanem requesteket közvetít). Akkor mi fordít? Hát a maradék 3% CPU egy része.

Jelenleg az mc-t fordítom pkgsrc-ból, most két napja megy (éjjel le volt állítva). Persze csak az az érdekes, hogy egyáltalán a végére tud-e jutni (már csak napok kérdése, jelenleg a glib-nél tart). Van idő tehát néhány megjegyzésre.

Bár logikusnak tűnik, hogy kis eszközbe kis os-t (minixet) tegyünk, szerintem a beágyazott rendszerek piacán nem létezik az a rés, amit Tanenbaum látni vél. Javítsatok ki, ha nem így van, de mintha mindenben Linux volna. Amellett a Minix nem is elég kicsi. Nincsen benne dinamikus linkelés (so), emiatt minden végrehajtható fájl nagy, gyorsan fogy a hely. A dinamikus linkelés hiánya funkcióvesztést is hoz, pl. látom, hogy valaki panaszkodik a minix levlistán, hogy a python-ban nincs bz2 modul. Nincs, mert a python nem tudja felszedni az so-ként implementált modulokat.

Az marha jó, hogy a saját vackok helyett átálltak a pkgsrc-re. Viszont tudatosítani kellene, hogy a pkgsrc (tízezer emberév munka) sokkal nagyobb érték, mint a minix. Ezért nincs értelme az olyan mondásoknak (szintén levlistában), hogy a pkgsrc-ben levő EDE még nincs portolva minix 3.2-re. Ehelyett úgy kellene hozzáállni a kérdéshez, hogy tegyük a minixet a pkgsrc alá, hozzuk olyan állapotra, hogy a pkgsrc-on a lehető legkevesebb (0) változtatásra legyen szükség. Szerintem ez kutatási témának is érdekesebb. Azt is el tudom képzelni, hogy elérhető volna a bináris kompatibilitás, vagyis a NetBSD binárisok futtatása minix felett. A FreeBSD is tud futtatni Linux binárisokat.

64 bit kell. Lassan 10 éve az ipar csak 64-bites processzort gyárt. Nehogy már azt a hatezert sort ne tudja úgy megírni, hogy annyi bitesen működjön, amilyen a processzor. Minél tovább halogatja, annál több baja lesz vele.

A minix fs marha jó flopidiszkre. Fejlődés viszont csak akkor várható, ha a minix felkerül a programozók fizikai pc-jére (nem emulátorba), ahhoz viszont kellene egy normális fájlrendszer, ami minimum a most kapható diszkeket kezeli, pl. egy SATA-t. Ehhez képest a doksi azt írja, hogy a minix kezel "egyes SATA diszkeket". Ami Tanenbaumot illeti, ő azt nyilatkozata, hogy Solaris és Windows XP van a gépein.

Végkövetkeztetés: Nem ellenszenves a Minix. Nem is állna messze attól, hogy használhatóvá váljon, ha a többi os nem fedné le teljesen a piacot. A mikrokerneles filozófiája miatt még így is érdekes. A NetBSD-vel való együttműködés jó ötlet. Ahhoz hasonló projekt kéne, mint a FreeBSD kerneles Debian.

Majd még ideírom, hogy sikerült-e lefordítani az mc-t.