L4/Fiasco
Unod már, hogy domain0, domainU és egyéb szerencsétlenségeket kell létrehoznod?
Ki nem állod hogy hetente változik a Xen API, és tele van backward compatilibity hack-ekkel?
Akkor ideje megnézni miféle értelmesebb elképzelések vannak amiket érdemes lenne ehelyett támogatni...
Itt van például az L4 mikrokernel API és a rá épülő hard-realtime mikrokernel: a Fiasco! Hja kérem, ez bizony az opensource piacon fellelhető egyetlen hard-realtime operációs rendszer aminek értelmes környezete van. Értem ezalatt például, hogy egy komplett device driver environmentje van arra, hogy a Linux device drivereit szinte egy az egyben fel tudja használni, így egy-egy feature portolása csak rövid időt vesz igénybe. Az L4-ből többek között az USB driver valamint az egyik TCP/IP stack említhető, ami a Linuxból származik.
Na tehát itt van ez a komplett, multiplatform (ppc, arm, mips, x86) környezet, ami egy rakás fejlesztésre teljesen jó alapot nyújt, de mire tudja az r=1 user használni? Na, hát vágjuk nyakon egy Linux-szal szegény jobb sorsra érdemes mikrokernelt, elvégre sok helyen van arra szükség, hogy legyen egy realtime környezet, de tudjon futtatni komplex nonrealtime bugware bloat applikációkat is.
Az L4Linux. Ezen a ponton érdemes talán megnézni ezt az egységsugarú usereknek szánt demo CD-t, amelynek egyik része azzal foglalkozik hogy minden egyes klikkre feldob egy linuxot, dejó. Azért a valóságban látványosabb. Az is, hogy a bootolás megkezdésétől számított 5. másodpercben már egy teljes, hard-realtime grafikus ablakkezelő rendszer fut, és ez is csak a CD drive sebessége miatt tart ennyi ideig.
Architektúra, na. Linus amúgy teljesen idióta elképzelésnek tartja ezeket a rendszereket, dehát minden szentnek maga felé hajlik a keze, hát még neki. /me pets Linus
Na, ha mindenki megnézte a gyakorlatban hogy miről van szó, akkor lássuk hogy is lehet ezt összetákolni @ home. Nem vesződnék most step-by-step magyar howto létrehozásával, mert a gyári leírások segítségével elég egyszerű az L4, a Fiasco, és az L4Linux lefordítása (értsd: nem jár több szopással mint egyéb F/OSS komponensek összeizgatása, tehát full szopás). Nagy vonalakban a következőkről van szó:
1. Fel köll rakni egy normál Linux diszribet, amit nem sajnálunk majd utána óriási lelkesedéssel letörölni (ezért hát Debiant használtam, úgyis csak a /bin/sh érdekel első körben, az meg még működik benne).
2. Ezen a rendszeren le kell fordítani a fent említett stuffokat, fogni egy módosított grub-ot (ami ismeri a modaddr opciót) például az említett CD-ről, mert a CVS-ben lévő verzió mindent csinál csak épp lefordítani nem lehet nullára szopás nélkül. Majd ezeket a dokumentációban részletezett módon installálni. A kernel kompilálásnál a siteon leírtakon kívül fontos, hogy a PCI buszhoz ne a BIOS-on keresztül akarjon a limugz hozzáférni, mert abból max panic lesz, sokkal jobb neki a "Direct" hozzáférés (persze azért nem árt ha ilyen dolgokhoz csak az egyik Linux tud hozzányúlni, mert különben gyönyörűszépen összeverik egymást a hardver accessért;). Úgy általában az input eszközöket, VGA text konzolt (FB marad!) és ACPI, APM meg hasonlókat kell teljesen kivágni, PCI busz, IDE/SCSI és hálókártyák maradhatnak ha szükséges.
title L4Linux
kernel /boot/L4/bootstrap
modaddr 0x02000000
module /boot/L4/fiasco -nokdb -serial -serial_esc -comport 1 -comspeed 115200
module /boot/L4/sigma0
module /boot/L4/roottask task modname "bmodfs" attached 7 modules
module /boot/L4/events
module /boot/L4/names --events
module /boot/L4/log --prio 0xA1 --buffer 0
module /boot/L4/dm_phys --events
module /boot/L4/simple_ts -t 300 --events
module /boot/L4/rtc
module /boot/L4/ore --events
module /boot/L4/l4io --noirq --events
Ablakkezelő environment nélkül (L4Con):
module /boot/L4/con --events --l4io --cpuload
module /boot/L4/loader --events --fprov=BMODFS l4run.cfg l4linux.cfg
Vagy vele (L4Dope):
module /boot/L4/l4dope --events --l4io --cpuload
module /boot/L4/loader --events /boot/L4/proxygon --fprov=BMODFS l4run.cfg l4linux.cfg
module /boot/L4/bmodfs
module /boot/L4/libloader.s.so
module /boot/L4/libld-l4.s.so
module /boot/l4linux
module /boot/l4linux.cfg
module /boot/l4run.cfg
module /boot/L4/run
vbeset 0x111
Az l4linux.cfg:
task "l4linux" "earlyprintk=yes mem=32M video=l4fb root=/dev/hda1 ro console=tty0 init=/bin/sh"
all_sects_writable
allow_cli
És az l4run.cfg:
task "run"
Ezutóbbi két file mondja meg a loader-nek, hogy az ott megadott defaultban indítandó modulokat milyen paraméterekkel csapja nyakon. A "run" egy egyszerű kis app, amivel majd boot után is el lehet indítani pl TFTP-n, vagy - mint jelen esetben is - a bmodfs-el boot közben memóriába töltött modulokat (pl néhányszáz újabb Linuxot), az "l4linux" nevű meg szerintem elég triviális (amúgy a task nevének kell egyeznie a modul nevével nyilván, így találja meg hogy mi melyikre vonatkozik).
A boot képei, Mac OSX/ppc-n futó QEMU alatt. Itt nem a Dope-t használom, mert QEMU alatt a grub vbeset opciójával elég szépen kifekszik az egész. Szerencsére azonban az L4con-nak van egy --vbemode kapcsolója, amivel úgyszintén át lehet kapcsolni grafikus módba, csak ez még működik is.
Az üres L4con, még nem fut semmilyen modul
A run már elindult
A linux is behúzta magát végre, a 2-es konzolra (shift+Fx a váltás)
A háttérben egyébként a soros konzol kimenete látszik (Qemu fícsör). Elég hasznos, tekintve hogy mindkét grafikus interface (l4con, dope) természetszerűleg elfedi az L4 Fiasco outputját.
Nos, ennyi lenne ez a gyors ismertető, amatőrök és gentoofanboyok ne kezdjenek bele, a többiek meg RTFM.