Operační systém HelenOS 0.4.1

Po půl roce vyšla v noci na dnešek nová verze open source operačního systému HelenOS 0.4.1 (Escalopino). Cílem projektu HelenOS je vytvořit plně použitelný OS. HelenOS je charakteristický dobrou přenositelností (beží na sedmi různých architekturách) a podporou více procesorů (SMP). Verze 0.4.1 přináší celou řadu významných vylepšení, zejména podpory architektur ARM a PowerPC, souborového systému, ovladačů zařízení a uživatelského rozhraní.

4.8.2009 15:06 | Jiří Svoboda | Zajímavý software

Komentáře

[thingie]

Vážně je tak důležité, že to bylo právě v noci na dnešek, a že je to půl roce? Ta zprávička je už tak dost dlouhá.

[Integral]

Vazne by se ta zpravicka tolik zkratila, kdyby se tohle vynechalo? IMHO mnohem vic otravuje cteni, kdyz nekdo jako ty (a bohuzel ted i ja) vklada takove nesmyslne komentare.

[|🇵🇸]

Jako sorry, ale šlo to zkrátil vynecháním balastu o pětinu. Přeci jen tohle nejsou články, ale zprávičky.

Jinak k věci: k čemu to jako bude dobré? Jako studentská zábava fajn, ale existuje nějaký reálný pádný důvod (bude to dřív než Hurd, má to extrémní výkonový potenciál,...), proč to používat?

[Ladicek]

Jako studentská zábava fajn

Připomíná mi to jeden projekt. Nějakej finskej studentík, jak on se jmenoval…

[|🇵🇸]

Taky mě to napadlo, jenže proto jsem přidal tu zmínku o killer feature. Tohle je teď yet another OS under open-source license.

[Ladicek]

Pár lidí z matfyzu si na tom udělá titul, to stačí, ne?

[|🇵🇸]

Bohatě stačí, jenom je otázka, co s tím bude pak.

[LuciusMare]

:D přesně to mě napadlo :)

[Marek Bernát]

Nie som linuxový kunsthistorik, ale nebolo to tak, že pred linuxom nič podobné nebolo (poriadny free operačný systém)? Dnes už ten poriadny OS máme a hoci nemám nič proti novým prístupom, to práve naopak (mikrojádra, objektovél/funkcionálne kernely, ... len pekne sem s nimi), tak začína byť celkom zrejmé, že linux je asi nedostižný (čo asi týka OS podporujúci všemožný hardvér a pod.).

[Ladicek]

Ale jo, Linus byl ve správnou chvíli na správném místě a dneska je jeho dítko na vítězném tažení celým světem. Z toho, co jsem tak letmo pochytil na titulní stránce HelenOSu, mám sice dojem, že by vývojáři možná udělali líp, kdyby se přidali k Minixu, ale třeba jdou na matfyzu trochu jinou cestou, kdoví.

[Ladicek]

Nebo možná HelenOS vznikl dřív než Minix 3?

A vůbec: jestli tohle čte nějaký z lidí od HelenOSu, mohl by osvětlit, co mají s Minixem 3 společného, v čem se liší a tak?

[Jakub Jermář]

Nebo možná HelenOS vznikl dřív než Minix 3?

 

Prvni radky kodu HelenOSu byly napsany v roce 2001 a prvni oficialni release byl v roce 2006. Jak je na tom Minix 3 nevim.

A vůbec: jestli tohle čte nějaký z lidí od HelenOSu, mohl by osvětlit, co mají s Minixem 3 společného, v čem se liší a tak?

Trunk verze nemaji spolecneho nic, az na to, ze jsou obe zalozene na mikrojadru. Lehke srovnani viz reakce na predchozi prispevek. V Networking branchi jsme si pujcili dva ovladace sitovek z Minixu, ale zrejme je budeme muset napsat znovu.

[Jakub Jermář]

m světem. Z toho, co jsem tak letmo pochytil na titulní stránce HelenOSu, mám sice dojem, že by vývojáři možná udělali líp, kdyby se přidali k Minixu, ale třeba jdou na matfyzu trochu jinou cestou, kdoví.

To by byl ale krok zpatky, alespon z pohledu kernelu.

Ten Minixovy (Minix3) jeste nedavno nedokazal vyuzit virtualni pamet  (stabilni verze to stale neumi), nema podporu SMP, v podstate bezi jen na 32-bit x86 a naslo by se toho jeste vic. HelenOS naproti tomu ma docela dobre rozvinuty microkernel, virtualni pamet mel jiz pred 0.2.0 (coz je rok 2006), SMP podporuje asi od roku 2002 a bezi "skoro" na vsem.

V userspacu ma Minix3 vyhodu, protoze je do urcite miry kompatibilni s POSIXem a tudiz nema takovy problem s nedostatkem aplikaci.

[Ladicek]

Díky! To "srovnání" jsem myslel z pohledu architektury a ještě spíš cílů projektu, ne implementace. Ale myslel jsem, že taky implementujete POSIX, jestli ne, bod pro vás, staré struktury je třeba opouštět a hledat nové cesty

[Marek Bernát]

 

staré struktury je třeba opouštět a hledat nové cesty

Súhlas. Ale OS bez aplikácií, to musí byť ťažké :-/

 

[Martin]

No, to je podle mě prokletí, ze kterého se jen tak nedostanem.

[Budoucí uživatel :D]

Pro to není od roku 2001 (?)  ještě ani jedna aplikace? Co takhle systém dostat víc do povědomí tím, že se aspoň jedna napíše. Berte to jako názor laika, možná to nejde ...  Třeba textová kalkulačka, kvůli které to aspoň bude stát za to rozjet v tom Virtualboxu. Rychlá instalace z jiného OS a boot z usbčka n. FDD by nebyl od věci. Třeba může každý výsledek od 1 do milónu okomentovat nějakým vtipným komentářem - statistickým údajem. Komentáře vám budou psát a dodávat fanoušci, tak zjistíte, kolik jich máte.

[Ladicek]

Je tam textový tetris

[Jakub Jermář]

No ale vzdyt my mame nekolik malo aplikaci. Zkuste treba /app/tetris.

Nicmene psani aplikaci neni momentalne nas nejvetsi problem ani priorita.

[Marek Bernát]

Ja to určite neskôr vyskúšam

To je pochopiteľné a ja vám držím palce, nech je z toho nový a lepší linux Len problém je, že je to začarovaný kruh: aby išiel vývoj rýchlejšie dopredu, systém sa musí dostať do povedomia používateľov a programátorov. A bez aplikácií sa to stane asi dosť ťažko. Ten fínsky študentík to v tomto ohľade mal strašne jednoduché a byť Vami, tak ma to trochu štve A keď sme pritom (neviem, či sa to tu niekde riešilo, ak áno, poprosím link na komentár), je veľmi veľký problém pridať nejaký translačnú vrstvu *nixových systémových volaní do tých HelenOSových? Prípadne (a lepšie), je realizovateľné napísanie kompilátoru, ktorý bude využívať vašu libc a pomocou ktorého by sa dali skompilovať bežné *nixové programy (samozrejme okrem tých, ktoré explicitne volajú kernel mimo libc, tam asi nič iné ako úplný prepis programu nie je alternatíva)?

[Jakub Jermář]

Tak treba ten tetris je "trochu" prizbusobeny BSD tetris, ktery si muzete nainstalovat treba v Linuxu. Z toho je videt, ze do urcite miry se aplikace portovat daji. Nas souborovy system trochu pripomina POSIX, takze by to zas nemuselo byt tak tezke. Horsi je, ze neimplementujeme treba signaly.

Teoreticky by bylo mozne mit nekolik verzi libc (~personalit) a POSIXove aplikace linkovat s POSIXovou libc a nativni HelenOS aplikace s nativni libc atp. Ale to jsou zatim jen rane uvahy.

[Jira]

Ano, jistě. Text takového rozsahu by v tvém případě jistě vyšel jako článek, je by byl bohatě doplněný vysvětlujícími ilustracemi (tzv. screenshoty). Jenže ty bys psal na nějaké vysoce odborné téma (např. o webovém prohlížeči) a také ne pro mrzké zisky jako někteří jiní zde.

[|🇵🇸]

Tady někdo poobědval vtipné kaše, že?

Text takového rozsahu by v tvém případě jistě vyšel jako článek...

Ne. Článek musí mít nějakou minimální délku.

...také ne pro mrzké zisky jako někteří jiní zde.

Mohu vědět, kdo tu píše pro mrzké zisky?

[Jakub Jermář]

 

Jinak k věci: k čemu to jako bude dobré?

Muzete to treba pouzit jako operacni system Pridame vim, a muzete to pouzivat treba k editaci a uchovavani textovych dokumentu na platforme dle vaseho vyberu. Pridame networking a muzete to pripojit k siti a provozovat na tom nejaky jednoduchy web server. Nebo si naprogramujete tu killer aplikaci sam a strcite to do cerne krabicky a treba to i nekomu prodate...

 

Jako studentská zábava fajn,

 

Proc zrovna jako studentska? Vyvoj HelenOSu je urcite zajimavy i pro ty, co uz studenty nejsou (a treba ani nikdy nebyli).

 

ale existuje nějaký reálný pádný důvod (bude to dřív než Hurd, má to extrémní výkonový potenciál,...), proč to používat?

Bude to drive ci pozdeji, uvidime. Samozrejme ze to ma extremni vykonovy potencial - napr. kdyz pustite nekolik paralelnich /app/tester loop1, tak to za chvili extremne roztoci vetraky na plny vykon.  Spis bych ale hledal jine duvody, proc se HelenOSem zabyvat - treba jestli ma citelny a srozumitelny kod, jestli ma zajimavy design a jestli je stabilni a zda ho kazda chybka slozi na kolena.

 

 

[|🇵🇸]

Muzete to treba pouzit jako operacni system

Skvělé! Jenom teda operační systém, na němž nejsou aplikace, je obvykle dost naprd operační systém.

Proc zrovna jako studentska? Vyvoj HelenOSu je urcite zajimavy i pro ty, co uz studenty nejsou (a treba ani nikdy nebyli).

Jasné. Já akorát na webu četl, že je to vyvíjeno na UK.

...treba jestli ma citelny a srozumitelny kod, jestli ma zajimavy design...

Ha! To mě napoprvé nenapadlo, dobrý nápad. Beru.

[ed]

mozno sa tu v okoli pohybuju ludia, ktori pracuju s embedded vecami a trebars niekedy v minulosti potrebovali dostat nejaky multitaskingovy operacny system s podporou filesystemu do nejakeho extra vykonovo chabeho prenosneho zariadenia (napriklad im nevyhovovalo, ze linux dlho bootuje, ma velky image, potrebuje velky userspace a pod.). nez pisat si cele jadro po vlastnej osi sa im moze zist nieco ine, co nema pol gigabajtu zdrojovych kodov, da sa pomerne lahko upravit a pripadne ma potencial nahackovania driverov z inych projektov, ak je to potrebne. mozno niekedy v minulosti na tento projekt narazili, ale povedali si, ze este stale nestoji za to sa s nim zaoberat a tato spravicka im to pripomenie spolu s tym, co pribudlo.

[cronin]

Na vete "Cílem projektu HelenOS je vytvořit plně použitelný OS." sme sa s kolegami tiez celkom dobre pobavili. A hned nasledujuca veta "HelenOS je charakteristický dobrou přenositelností (beží na sedmi různých architekturách) a podporou více procesorů (SMP)." je tiez hodna obdivu. Vskutku zaujimavy OS; este par rokov vyvoja a dobehne aj Hurd.

[thingie]

No, o tom by se taky dalo diskutovat, ale narozdíl od informace, že to vyšlo v noci při měsíčku to aspoň něco říká…

[|🇵🇸]

...cílem tedy zjevně není vytvoření nepoužitelného operačního systému.

[thingie]

To, zcela překvapivě, není to jediné, co z věty „Cílem je vytvořit plně použitelný OS.“ lze vydedukovat.

[|🇵🇸]

Ještě jde vydedukovat, že to má být "OS" a že je cílem jej vytvořit, nikoliv okopírovat (malí a měkcí vědí). O "plné použitelnosti" by se dalo pochybovat, ale nevím, co to má být.

[Jira]

A takový budoucí matfyzák jako ty z toho dokáže třeba usoudit, že to nejspíš ještě není plně použitelný OS.

[|🇵🇸]

Můj jazykový cit si tím není tak docela jistý, ta věta se mi totiž sama o sobě nelíbí... ^_^

[dayvee]

Jiste, na zaklade teto vety lze mimo jine predpokladat, ze cilem projektu neni vytvoreni jen castecne pouzitelneho OS.

[thingie]

Píšu za jedna.

[thingie]

To zcela překvapivě není to jediné, co z věty „Cílem je vytvořit plně použitelný OS.“ lze vydedukovat.

[thingie]

(Wtf.)

[Jiří Svoboda]

 

Na vete "Cílem projektu HelenOS je vytvořit plně použitelný OS." sme sa s kolegami tiez celkom dobre pobavili. A hned nasledujuca veta "HelenOS je charakteristický dobrou přenositelností (beží na sedmi různých architekturách) a podporou více procesorů (SMP)." je tiez hodna obdivu. Vskutku zaujimavy OS; este par rokov vyvoja a dobehne aj Hurd.

Jsem rád, že jste se pobavili. My se s kolegy v práci taky rádi pobavíme . Když prof. Tanenbaum psal MINIX, jeho cílem bylo vytvořit učební pomůcku. Když Microsoft psal Singularity, chtěli si ověřit princip operačního systému napsaného v managed kódu, nechtěli ho prodávat. Cílem Open Kernel labs je dodávat OKL4 jako mikrokernel, nikoli jako operační systém. Takže ta věta říká dvě věci: chceme, aby to bylo reálně použitelné (to, ač vás to možná překvapí, není vždy cílem) a druhá je, že to má být kompletní operační systém (to taky není zřejmé). Navíc už se našlo pár lidí, kteří si mysleli, že HelenOS je Linuxová distribuce.

 

Co se týká přenositelnosti, většina hoby operačních systémů běží pouze na Intelu (vč. MINIXu a Hurdu) a SMP také nepodporují (protože jsou to vesměs výtvory jednoho autora, pro kterého něco takového byl příliš velký luxus. Mám na mysli systémy jako MINIX, Haiku, Syllable, Visopsys, SPAD, QNX Neutrino a další... S Linuxem nebo BSD se nechceme a ani nepotřebujeme srovnávat (zatím )

Dohonit Hurd v počtu podporovaných aplikací bude poměrně obtížné, vzhledem k tomu, že HelenOS není UNIX-like systém a nelze tak na něm spouštět UNIXové aplikace bez úprav. Na druhou stranu Hurd by se musel hodně snažit, kdyby chtěl HelenOS honit co do počtu podporovaných platforem. Kromě toho Hurd se v posledních letech téměř nevyvíjí a chybý mu jasný směr, takže jakýkoliv operační systém, který se vyvýjí ho musí zákonitě dřív či později předhonit.

 

 

[cronin]

Nie je to unix-like system, linuxove aplikacie na tom spustat nemozno. Takze ta spravicka je vlastne este aj off-topic.

[ss]

neskutecna arogance od cloveka ktery nic podobneho nikdy nedokazal (predpokladam)

[cronin]

... napisl niekto, kto sa ani neunuva podpisat. A to nie je predpoklad, ale fakt.

Vas predpoklad je navyse chybny. Sice som nic nedokazal v oblasti Linuxu, ale v nejakej inej oblasti ano.

[PanZvedavy]

Zdravim,

mel bych takovou kacirskou myslenku...proc vlastne vyvijite dalsi OS, ktery je jiny nez ostatni? Predpokladate, ze budete uspesnejsi nez autori stavajicich OS? Co vas vede k tomu investovat svojne zdroje do vyvoje? Zabijite jen volny cas nebo je to ftip? Vytvarite dalsi OS protoze zkratka mate tu svobodu volby si vytvaret OS???

Proc se ptam, typicky v opensource svete je charakteriskte delat jednu vec milionem zpusobu a cest. Nestaci 10 nebo 100 distribuci, ale musi jich byt 1000. Nestaci 100ky software, ktere delaji tu samou vec jen se menuji jinak a delal to jinej tonda z jine vesnice. Ne presto, ze uz mam zilion variant sw, ktery dela porad to same tak se vzdycky objevi nekdo, kdo prijde s dalsi vice ci mene zbytecnou variantou. A bohuzel spousta techto variant je naprosto nepouzitelna a jeji vyvoj vlastne skonci driv nez zacne.

Spousta lidi v open source svete se divi, rozciluje nebo nadava, ze se jejich prace nemuze protlacit mezi vetsi procento uzivatelu...tedy tech, kteri budou jejich praci vyuzivat a jsou casto duvodem proc vlastne nekdo pise aplikace.

Dokaze si vubec nekdo predstavit jakou obrovskou silu by melo sjednoceni techto open source vyvojaru a smerovani jejich usili tak, aby melo skutecne nejaky uzitek? Tim nemyslim alternativu k unifornim windows nebo smerovani k jedne jedine distribuci. Tim myslim zamerenim vyvojaru na skutecne podstatne projekty, ktere k necemu jsou a predevsim soustredeni se na kvalitu a ne jak je to dneska na kvantitu.

Pokud nekdy dojde k nazorovejsimu sjednoceni v open source komunite tak teprve pak nastane okamzik, kdy bude Linux,bsd ci dalsi OS skutecne schopny byt pripraveny pro rozsahlejsi nasazeni. Ale v situaci, kdy kvantita je dulezitejsi nez kvalita a to propastnym rozdilem tak open source bude paberkovat na okraji zajmu majoritnich systemu. Viz pomer existence linux a pocet implemetace ve svetovem meritku na desktopech.

Tedy zprava o dalsim ziliontem OS, jehoz vyvoj mozna ani nebude trvat dele nez vyexpiruje domena projektu...me tyhle zpravy frustruji. Autori budou bezpochyby odbornici, ale nebylo by lepsi, kdyby se pripojili k existujicim projektum nez plytvali sve drahocene sily na dalsi variantu varianty OS?

[Ladicek]

proc vlastne vyvijite dalsi OS, ktery je jiny nez ostatni?

Ne že bych měl s HelenOSem něco společného, ale odpověď se přímo nabízí: protože můžou! Proč Microsoft vyvíjí Singularity/Midori (a přetáhl na to člověka od Coyotosu)? Proč se Andy Tanenbaum rozhodl udělat z Minixu 3 reálně použitelný systém a dostal na jeho vývoj grant? Protože bez výzkumu bychom byli pořád na stromech.

Jedna věc je vývoj a výzkum operačních systémů, programovacích jazyků, algoritmů, a tak dále a tak dále, tady jste sakra přestřelil, druhá věc je tisíc a jeden přehrávač mp3 nebo podobné tic tac toe projekty, tam si občas sám klepu na hlavu, o co komu vlastně jde.

No nic, knížka volá

[Marek Bernát]

 

 bychom byli pořád na stromech.

Alebo dokonca na orientovaných cyklických grafoch. Bŕŕ.

 

[Jakub Jermář]

Tedy zprava o dalsim ziliontem OS, jehoz vyvoj mozna ani nebude trvat dele nez vyexpiruje domena projektu...me tyhle zpravy frustruji. Autori budou bezpochyby odbornici, ale nebylo by lepsi, kdyby se pripojili k existujicim projektum nez plytvali sve drahocene sily na dalsi variantu varianty OS? 

Doba trvani projektu - od roku 2001 - by Vam mohla napovedet, ze s nejvetsi pravdepodobnosti s jeho vyvojem jeste jen tak neskoncime. Stejne tak soucasny trend, kdy se nam pomalu ale jiste dari ziskavat nove vyvojare (a to nejen z MFF UK), vypovida o tom, ze jsme spise na vzestupu nez-li na ceste opacnym smerem.

Ackoliv jiste prehanite, k tomu ziliontemu OS bych rad dodal, ze HelenOS ma nekolik vlastnosti, ktere napr. u mikrokernelovych OSu jen tak nenajdete: velice slusnou podporu procesoru sparc64 (ze vsech OSu je lepsi uz jen Solaris, Linux a OpenBSD) nebo dynamicke linkovani (zatim v jedne z nasich branchi).

Navic, kdyz pisete servery pro mickrokernelovy OS, tak zjistite, ze to neni vubec zadna sranda a v duchu se proklinate, ze misto mikrokernelu nebastlite nejakou monolitickou rychlokvasku, kterych je opravdu spousta. To znamena, ze pri teto cinnosti narazite na problemy, ktere nemaji obecne zname/prijate reseni a razem se stavate prukopnikem. My jsme na toto narazili napr. pri navrhovani a implementaci VFS a celeho systemu souboru.

 

[dad]

ten duvod je velice jednoduchy. Pri delani editoru nebo OS neni treba mit inzenyrsky cit. Neni potreba se zabyvat s interfacemi (modularitou), Jenom par lidi ma ten talent neco takoveho uhodnout a pote take implementovat.

Vyrobci os a nebo editoru takove problemy nemaji. Interface si stanovi sami a nemusi se nikomu zodpovidat. A prave chybejici  schopnost myslet modularne zabranuje tomu, aby se vsichni tio lide spojili a delali na jednom projektu. Kazdy vidi ty sve interface a nastavi je ve svem projektu tak chybne, ze nikdo nemuze pomahat, aniz by byl seznamen s tim 'celkovym'.

Linux, bsd a vsechny tyto podobne systemy se mohly vubec alespon trochu rozvinout, protoze Thompson, Ritchie a Pike ty interface navrhli tak, jak to ma byt. A ti dnesni se maji alespon neceho drzet. Ale jakmile se to dostalo do desktopu a narostl pocet vyvojaru a  tim automaticky pocet tech, kteri na tu 'modularitu' nemaji, nastavji problemy A tito lide dnes sedi jiz na dulezitych mistech , kde dokonce rozhoduji a vysledky vidime - posledni hit byl ten nesmysl s tim mono do debianu, aby se mohl nastartovat nejaky pitomoucky program, ktery to potrebuje.

[Marek Bernát]

Toto je samozrejme tak dementný príspevok, že skoro ani nemá zmysel reagovať. Pri OS netreba mať cit? Vy poznáte niekoho schopného navrhnúť poriadny kernel? Takých ľudí je sakra málo. A Váš príklad s *NIXom je tiež mimo: je to jeden veľký a dnes už archaický bordel a kernel môže vyzerať niekoľkonásobné lepšie (*NIX "architektúra" spočíva na monolitickom prístupe + moduly a všetko sa to prasí tam. Preto v posledných rokoch v Linuxe začali objavovať Ameriku a zistili, že kopa vecí sa dá presunúť do userspacu (napr. FUSE, ale nie len)). Ak to porovnáte s čistotou mikrojadra, tak je to asi niekde inde Sám sa v týchto veciach veľmi nevyznám a klaniam sa pánom v Bell Labs a ďalším, za to, čo tu máme, ale vývoj rozhodne nezastal pred 50 rokmi

[thingie]

Ironie, to je, když někdo šíleně dlouhým žvástem kritizuje domnělé zbytečné plýtvání silami.

[ss]

Pokud vim to nekritizoval ale slusne se ptal, diky tomu ze se tento clovek zeptal, jsem se od skutecnych odborniku dozvedel pro mne velice zajimave informace. Tak uz sakra VSICHNI PRESTANTE S TIM ODSUZOVANIM!

[Kvakor]

Proč? Když se ptali horolezce Malloryho proč vylezl na Everest, tak jim odpověděl: "Protože tam je".

Nechtěl bych žit ve světě, kde se něco nesmí dělat jen kvůli tomu, že se to zdá někomu zbytečné ...

A proč zrovna operační systém? Nejlépe to asi vyjádřil Geoffreyho Jamese v The Tao Of Programming (část 3.3), pokusím se o neumělý překlad pro neangličtináře:

Byl jednou jeden programátor sloužící na dvoře válečníka Wu. Ten se jednou programátora zeptal: "Co je jednodušší navrhnout, účetní program, nebo operační systém?"

"Operační systém", odpověděl programátor.

Válečník se velmi podivil. "Účetní program je nepochybně triviální ve srovnání se složitostí operačního systému", řekl.

"To ne", odpověděl programátor, "když se navrhuje účetní program, programátor funguje jako prostředník mezi lidmi s rozdílnými názory na to, jak má program fungovat, jak mají vypadat výstupy a jakým daňovým zákonům má program odpovídat. Naprotitomu operační systém není omezen vnější podobou. Při jeho návrhu se programátor snaží nalézt nejjednodušší harmonii mezi strojem a představami. Proto je jednodušší navrhnou operační systém."

Válečník přikývnul a usmál se: "To je všechno hezké, ale co je jednodušší odladit?"

Na to programátor neodpověděl.

[petr_p]

Využiji toho, že se tu pohybuje vývojář a zeptám se jak to s API vzhledem k uživatelskému prostoru? Už bylo prozrazeno, že POSIX to není. Jak tedy definujete služby jádra? Existuje nějaký vzor, plánuje se přidání emulace nějakého zavedeného rozhraní jiného systému? Pokud žádná myšlenka není, jak vlastně testujete jádro? Stačí, že to nabootuje a servery nepadají, nebo jak tedy?

[Jakub Jermář]

Jedna se o cca 30 syscallu, z nichz velka cast je HelenOS specific IPC a zbytek slouzi pro ovladani adresoveho prostoru ulohy, vytvareni threadu a novych tasku, a podobne veci. Z toho je videt, ze jadro toho samo o sobe zas az tak moc neposkytuje a veskera buisness logic je tedy implementovana pomoci serverovych tasku jako je napr. VFS. S temito tasky se potom komunikuje prave pomoci onech IPC syscallu.

Pokud jde o rozhrani nabizene nasi libc, tak ta je do velke miry specificka (napr. funkce pro praci s UTF8 a UTF32). Cast libc je wrapper kolem sluzeb nabizenych VFS serverem a do urcite miry se podoba souborove casti standardu POSIX, ale slovo kompatibilita je v tomto pripade prilis silne.

Na jadro mame kernelove testy, ktere se daji pustit z kconsole pomoci test * (musi byt ale v jadre zakompilovany). Na userspace mame program zvany tester (/app/tester), ktery proveruje funkcionalitu ruznych casti systemu z pohledu uzivatelske ulohy. Nicmene to, zda system vubec nabootuje a zda se v nem daji uspesne provozovat operace se soubory je take docela dobrym ukazatelem stability

[petr_p]

Tak jsem se seznámil s telefonním IPC, pročetl kód připojující kořenový systém (od initu přes libc až do serveru vfs) a musím říct, že to je fakt makačka.

Zatímco monolitické jádro zavolá aplikace jednou z mnoha služeb a pak si jádro věc celou ukutí samo, tak tady aplikace zavolá knihovní funkci a ta se pak skrze jádro dohaduje se serverem jak bába na tržišti (opcode, velikost argumentu, obsah argumentu). Jakou to má proboha režii? Vždyť se na každý ipc_data_* musí dvakrát přepínat kontext (aplikace → jádro → server) a to se děje pro každý argument služby serveru dvakrát (velikost a data). Už chápu, proč v tak rané fázi umíte SMP :D

Mimochodem zkusil jsem cat /dev/con0 a všechny console se zasekly. Tak jsem chtěl zabít cat z jaderné konzole, jenže ve výpisu úloh ani vláken nebyl (navíc jsem nezjistil, jak pozastavit scrollování). Jenže příkaz kill nějak není. Asi bych si to musel přes ipc domluvit s jádrem (po nastudování zdrojáků). Je to tak?

[Jakub Jermář]

 

Zatímco monolitické jádro zavolá aplikace jednou z mnoha služeb a pak si jádro věc celou ukutí samo, tak tady aplikace zavolá knihovní funkci a ta se pak skrze jádro dohaduje se serverem jak bába na tržišti (opcode, velikost argumentu, obsah argumentu). Jakou to má proboha režii? Vždyť se na každý ipc_data_* musí dvakrát přepínat kontext (aplikace → jádro → server) a to se děje pro každý argument služby serveru dvakrát (velikost a data). Už chápu, proč v tak rané fázi umíte SMP :D

Ale ne, SMP jsme uz umeli driv nez jsme vubec nejaky userspace meli. Mate pravdu, ze posilani zprav ma nejakou rezii. A to jste jeste neprozkoumal tu cast mezi VFS a FAT serverem. Pred ipc_data_* vetsinou asynchronne posleme jeste nejakou jinou zpravu, ktera oznacuje zacatek requestu a pripadne jeste nese nejaky naklad. Diky tomu, ze to je asynchronni ale nedojde k prepnuti do serveru a zpet, maximalne se prepne na jiny fibril a pripadne se uspi cely thread pri cekani na odpoved. Trochu jsem neporozumnel tomu jak pisete, ze se to prepina pro kazdy argument sluzby serveru dvakrat. Nektere sluzby VFS serveru ipc_data_read/write() vubec nemaji, a to dvakrat mi take prijde podezrele.

Mimochodem zkusil jsem cat /dev/con0 a všechny console se zasekly. Tak jsem chtěl zabít cat z jaderné konzole, jenže ve výpisu úloh ani vláken nebyl (navíc jsem nezjistil, jak pozastavit scrollování). Jenže příkaz kill nějak není. Asi bych si to musel přes ipc domluvit s jádrem (po nastudování zdrojáků). Je to tak?

Pustil jste ten cat z /dev/vc0? Ocekaval bych, ze to zasekne ten vc, ze ktere jste to poustel a ten, ktery byl uveden jako parametr. U ostatnich bych cekal, ze to pujde normalne dal. V kazdem pripade bych to oznacil za bug, ktery je potreba opravit. Obecne lze rici, ze podobne problemy jsou zpusobeny "nedostatkem" fibrilu, ktere by nekde po ceste od aplikace pres VFS a DEVFS do console mohly vyridit nejaky dilci ukol.

 

To ze jste nevidel ulohu cat je logicke, protoze se jedna o built-in command bdsh, takze by bylo potreba zabyt jeden z bdsh tasku. Toho lze prozatim docilit z kconsole nejak takto:

call1 generic/src/proc/task.o:task_kill <cislo tasku>

Na 64-bit kernelech je potreba data call2 a jako druhy argument 0. Otazka ale je, ktery z tasku by bylo potreba zabit, aby se to zase rozebehlo a jestli by to takto vubec slo resit.

[petr_p]

Pred ipc_data_* vetsinou asynchronne posleme jeste nejakou jinou zpravu, ktera oznacuje zacatek requestu a pripadne jeste nese nejaky naklad. Diky tomu, ze to je asynchronni ale nedojde k prepnuti do serveru a zpet, maximalne se prepne na jiny fibril a pripadne se uspi cely thread pri cekani na odpoved. Trochu jsem neporozumnel tomu jak pisete, ze se to prepina pro kazdy argument sluzby serveru dvakrat.

Jde o to, že u POSIXu předám všechny parametry na jeden syscall, tak tady se posílá každý parametr samostatným voláním.

Třeba mount() v libc pošle opcode VFS_IN_MOUNT (první přepnutní) a čeká, jestli server (druhé přepnutí) jej přijme, nebo odmítne (ENOTSUP). Pak odešle další argument a tak dále. Tím neříkám, že vždy je komunikace takto synchronizována potvrzováním.

a to dvakrat mi take prijde podezrele.

Moje chyba. Viděl jsem, že klient odesílá délku i obsah argumentu jednou funkcí, ale server si je čte zvlášť. To asi přenáší najednou (pokud se nezaplní buffer).

Pustil jste ten cat z /dev/vc0? Ocekaval bych, ze to zasekne ten vc, ze ktere jste to poustel a ten, ktery byl uveden jako parametr.

Teďka to zkouším znovu ostatní vc zůstaly fungovat. Třeba mám rozbité qemu, protože mi tehdy po nějaké době padl X server :(

[Jakub Jermář]

 

Jde o to, že u POSIXu předám všechny parametry na jeden syscall, tak tady se posílá každý parametr samostatným voláním.

 

Aha. Je potreba rozlisovat mezi POSIXem jako normou a monolitickym kernelem, kteremu muzete poslat vsechna data najednou pomoci syscallu. Vy tomu nasemu libc mount()u predate take vsechny parametry najednou, ale on ten pozadavek musi rozsekat na mensi kousky. Take bychom mohli vsehna data dat do jednoho velkeho bufferu a poslat je VFS pomoci ipc_data_write(), ale proste to tak nedelame. Ten mount urcite neni nejak zasadni pro vykon. Kdyz si vezmete takovy VFS_IN_READ, tak to funguje take tak, ze se nejdrive posle uvodni zprava a potom nasleduje ipc_data_read(). Zde ma toto rozdeleni opodstatneni, protoze ta druha zprava se primo preposle cilovemu fs (treba FAT), ktery na ni odpovi primo. Takze jednim z duvodu pro takoveto cleneni na subrequesty je flexibilita a nutnost ruzne casti toho requestu forwardovat dalsim sluzbam (coz je naopak vyhodnejsi nez posilat uplne novou zpravu.)

 

Moje chyba. Viděl jsem, že klient odesílá délku i obsah argumentu jednou funkcí, ale server si je čte zvlášť. To asi přenáší najednou (pokud se nezaplní buffer).

 

To je trochu jinak. Klient posila serveru blok pameti urcite velikosti. Server se musi rozhodnout, zda se mu ta velikost libi, nebo zda prijme blok mensi. Takze to probiha ve ctyrech krocich:

1. klient iniciuje prenos a oznami velikost
2. server obdrzi zadost o prenos i s navrhovanou velikosti
3. server prijme, tj. odpovi kladne
4. kernel prenese data

 

Teďka to zkouším znovu ostatní vc zůstaly fungovat. Třeba mám rozbité qemu, protože mi tehdy po nějaké době padl X server :(

Super, prvne jste me vydesil

 

 

 

 

[ss]

Opravdu koukam, ze to maji na svedomi cesi (kolik uz sme toho svetu dali a nemame z toho nic, ze - ale to je zase jina pisnicka)

Dozvedel jsem se to jen tak, ze jsem si precetl jmena autoru na jejich (anglicke) homepage. Myslim ze zminka ve zpravicce by nikomu neuskodila  a naopak by spoustu lidi urcitym zpusobem potesila, ze i presto co se deje a jak tu s nama korporace v cele s modrym ptakem cvici, tu stale mame neskutecne chytre hlavy, experty, kteri delaji projekt takoveho rozsahu PRO DOBRO VSECH ne pro vlastni zisk.

Timto chci vyjadrit vsem vyvojarum muj respekt a dik.

[thingie]

Protože abíčko není Rudé právo, tipuju.

[ss]

kvuli tomu ze jsem se zminil o modrych ptacich, utocite na mou osobu protoze si myslite ze jsem sympatizant s rudochy? Zminil jsem je jen proto ze jsou u koryt nejdele ( po 89.) Kdyby tam byli oranzovi sasci, nebo cerveni, bylo by to UPLNE stejne, mily pratele.

Vysvetleni pro jednodussi ctenare: na barve nezalezi, je uplne jedno jestli je to modra, oranzova nebo ruda. Tito saskove jsou jen sproste loutky.

prestante o tomto polemizovat a pokouset se urazet kohokoliv, kdekoliv, ano - ani na internetu ne.

[thingie]

Děkuji za názornou ukázku jak by to v takovém případě vypadalo. Teď bychom se mohli vrátit k tomu OS.

[Georgius]

Takže zpátky k operačnímu systému HelenOS 0.4.1_32bit iso ve virtualboxu:

  Booting 'HelenOS'

root (cd)
 Filesystem type is iso9660, using whole disk
kernel /boot/kernel.bin
   [multiboot-kludge, loadaddr=0x108000, text-and-data=0x7c634, bss=0x0, entry=0x108068]
module /boot/ns
   [Multibvoot-module @ 0x185000, 0x10ddf bytes]
module /boot/boot
   [Multibvoot-module @ 0x196000, 0x1020c bytes]
module /boot/devmap
   [Multibvoot-module @ 0x1a7000, 0x116ae bytes]
module /boot/rd
   [Multibvoot-module @ 0x1b9000, 0x103d2 bytes]
module /boot/vfs
   [Multibvoot-module @ 0x1ca000, 0x14640 bytes]
module /boot/fat
   [Multibvoot-module @ 0x1df000, 0x17a71 bytes]
module /boot/loader
   [Multibvoot-module @ 0x1f7000, 0x1a969 bytes]
module /boot/initrd.img
   [Multibvoot-module @ 0x212000, 0x206000 bytes]

SYSENTER/SYSEXIT not supported. System halted.

ozvěte se za dalších 10 let, až to bude shopné bootnout alespoň do příkazové řádky ... Mimochodem, kdo z komentujících to zkusil pustit ?

[Jakub Jermář]

Hm a vy se zase ujistete, ze reportujete problem HelenOSu a ne problem VirtualBoxu, jako v tomto pripade.

 

[Georgius]

Actually this is not a bug but a feature.

Chodí to v některém z emulátorů (qemu .. ?), nebo se to musí pouštět "na holém železe" ?

[Jakub Jermář]

Chodi to v Qemu, Bochsu, VMware... Kdyz pustite amd64 verzi na virtualboxu, tak to pujde taky. Kdyz z HelenOS/ia32 odmaznete ten check na ten SYSENTER, tak to bude take normalne fungovat.

[Ladicek]

Kdyz pustite amd64 verzi na virtualboxu, tak to pujde taky.

Ale musel jsem zapnout Povolit VT-x/AMD-V, jinak jsem skončil s 64 bit long mode not supported. System halted.