Stav projektu Debian GNU/Hurd

Michael Banck sepsal poslední dění v projektu Debian GNU/Hurd. Popisuje stav základního systému a toolchainu, píše o podpoře Xenu nebo množství sestavovaných balíčků a shrnuje výsledky letošního Summer of Code.

16.9.2008 08:29 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Kverulant]

Zase ho vyhrabali? Chudak HURD, nedaju mu pokoj ani na vecnosti...

[Drom]

Jak na vecnosti? Ja porad verim, ze nez umru, ze ho aspon jednou budu pouzivat v nejaky dodelany podobe :)

[the.max]

to driv zamrzne peklo

[Jakub Lucký]

Podle tohohle?

http://www.trdlo.cz/funtext_peklo.php

[Jakub Lucký]

Vždyť každý rok je stanovené nějaké datum (už si nepamatuju), ve kterém bude HURD vydán. Že už to odkládají 15 let, to nic neznamená ;)

[jyrki]

Dalsi datum vydani je stanoveno na 1.4.2009

[Drašar]

[Pavel Půlpán]

Kua a já myslel, že datum a čas synchronizovali s první kolizí v LHC.

[Filip Jirsák]

Spíš s poslední, ne?

[M. Lox]

Jaký je v tom rozdíl? To je furt jedna a ta samá, ne?

[Pavel Půlpán]

[Shadow]

Náhodou, já se na GNU/HURD těším.

[Käyttäjä 11133]

To já taky, jen už ani nedoufám...

[Drašar]

Jestli se nemylim, tak uz pomerne dlouho setrvava problem s vyberem vhodneho mikrojadra. GNU Mach pouzivany v hlavni vetvy trpi strasnou pomalosti komunikace mezi procesy v userspacu (zpravy se prenasi pres buffer v jadre), coz melo odstranit pouziti mikrojadra L4 Pistachio (zpravy se nemusi kopirovat pres jadro a posilaji se primo mezi procesy), nicmene tam narazily zase na jine problemy. Uvazovalo se i o tom, ze pokud se nenajde nejake vyhovujici (jiz existujici) mikrojadro, tak se implementuje nove od nuly primo na miru Hurdu. Tohle je teda situace dva roky zpatky, treba se to zase nekam pohlo, i kdyz tomu moc neverim.

[Drašar]

...v hlavni vetvi...

[Drašar]

...nicmene tam narazili...

[Jakub Jermář]

To by me tedy zajimalo, jak si predstavujete tu komunikaci "primo mezi procesy". Spis jde o to, ze Mach ma asynchronni IPC a tedy zprava se musi v jadre bufferovat nez si ji adresat vyzvedne. V L4 je IPC synchronni, takze odesilatel se zablokuje dokud adresat neodpovi a jadro proto nemusi pro zpravu nic alokovat a zbytecne ji kopirovat.

[Drašar]

Je to tak jak rikas, asi jsem se jen nepresne vyjadril. Tim "primo mezi procesy" jsem mel na mysli skutecnost, ze zprava jde u L4 proces1 -> proces2 narozdil od proces1 -> u-kernel -> proces2 u Machu

[skywaker]

tiez fandim Hurdu.. ale zacinam mat pocit ze to nikdy nedokoncia... a podla toho ako sledujem oficialne stranky a sem tam changelogy tak velke zmeny sa nedeju. trochu ozivenia som si vsimol vdaka Google Summer Projectu inac nic velke sa tam nedeje aspon nie na vonok

[Josef Kufner]

Že je asynchroní neznamená, že se musí kopírovat. Stačí vhodně měnit majitele kusu paměti.

[Jakub Jermář]

To je pravda - asynchronni je pouze o tom, zda se ceka na odpoved nebo ne.

Volajici by mel zustat majitelem toho kusu pameti, jehoz "kopii" posila, protoze by mu melo byt povoleno do nej zacit po odeslani zpravy okamzite zapisovat neco jineho, aniz by to ovlivnilo odeslanou zpravu. Navic zmena majitele kusu pameti se da udelat jen na urovni stranek, takze by se muselo davat pozor, aby se zmena majitele netykala dat, ktera nejsou pro cizi oci/usi.

[Josef Kufner]

A tohle celé je jen o definování a implementování dostatečně krásného API

Navíc není důvod k tomu, aby mu nebyla paměť pro zprávu dočasně nepřístupná, a/nebo aby zprávy nebyly alokovány v paměti sdílené oběma procesy. Další možností je copy-on-write, takže by se data kopírovat většinou nemusela. Nějaká možnost se už najde.

[skywaker]

len tak sa opytam.. jeden cas chceli implementovat aj nejaky kernel Coyotos.. neviete ako to s tym je?

[Drašar]

Pred 2 roky byl Coyotos horky kandidat, jenze byl tenkrat teprve ve stavu navrhu a nikdo jaksi nemel tuseni, jak bude s Hurdem fungovat. Ale divam se, ze uz na webu Coyotosu existuji i nejaky buildy, tak se treba rozhodovani o vhodnem mikrojadre nekam pohlo.

[Jakub Jermář]

Navíc není důvod k tomu, aby mu nebyla paměť pro zprávu dočasně nepřístupná, a/nebo aby zprávy nebyly alokovány v paměti sdílené oběma procesy.

Ta pamet by musela byt nepristupna behem doby, co s ni pracuje adresat. Aby nemohlo dojit k podvrzeni nejake zpravy (poslu neco hezkeho a pak to zapisem do pameti zmenim na neco oskliveho), tak by musela byt nedostupna pro odesilatele i okamzite po odeslani. Tedy musela by byt nedostupna celou dobu. Cili uz se moc nebavime o asynchronni komunikaci. Navic zkopirovat kus pameti muze vyjit lacineji nez vytvaret sdileni a pak to sdileni zase rusit. To same plati o COW.

[Josef Kufner]

Asynchronost spočívá v tom, že mezi odesláním zprávy a přijetím odpovědi je možné dělat něco jiného. Samotné odeslání i přijetí jsou atomické operace, takže žádné úpravy těsně po odeslání se nekonají. Odesílatel zavolá systémové volání a ještě před jeho návratem mu jádro odebere přístup k odeslanému kusu paměti. A nepřístupnost jednoho kusu paměti ještě neznamená, že program nemůže mezi tím dělat něco jiného, třeba si připravit druhý kus paměti.

Jaký způsob předávání dat bude nejefektivnější prozradí spíš sada označkovaných laviček, jen jsem naznačil, že možných řešení existuje povícero

[Jakub Jermář]

To uz asi nemusime opakovat, co je a co neni asynchronni komunikace. Jenom rikam, ze by odesilatel nemel byt omezovan v pristupu k pameti, kde lezi predloha zpravy. Proc by jako mel alokovat nejakou dalsi pamet, kdyz proste chce vyuzit tu co ma? A nebo kus, ktery lezi par desitek bytu za puvodni zpravou, ale bohuzel na stejne strance, ktera je ted read-only? To by musel mit pro kazdou zpravu samostatnou stranku. Co kdyz bude chtit poslat 1000 4-bytovych zprav? Kdyz to bude resit hezke API, tak data te druhe zpravy bude muset prekopirovat nekam jinam nejspis standardni knihovna. Uz jenom to samotne premapovani na read-only bude pravdepodobne drazsi nez prekopirovani (az) par kilobytu zpravy do kernel bufferu a potom do druheho adresoveho prostoru (podle mne to jde zoptimalizovat na jedno kopirovani). V kazdem pripade se bude muset udelat 2x TLB shootdown - jednou kvuli premapovani na RO a podruhe pri odmapovani z adresata.

[Josef Kufner]

A proč by neměl být omezován? Omezení bude, protože se mi prostě chce. Postup "Vyrobit buffer, naplnit buffer, předat buffer, počkat na výsledek." mi nepřijde nijak zvrácený. Spolus s recyklací jednou vyrobených bufferů to bude i rychlé (s výsledkem bude buffer vrácen pro další použití).

Aby nebyl problém s velkým množstvím malých zpráv, můžou se umístit do jedné stránky, která bude read-only pro příjemce. Ten sice bude smět číst i jiná data než je obsah aktuální zprávy, ale to mu bude k ničemu, protože tam budou buď nuly nebo předchozí/následující zpráva. Samozřejmě pro různé příjemce bude potřeba alokovat samostatné stránky.

API by mohlo být podobné tomu pro práci se soubory, ale funkci na odeslání zprávy (tj. obdoba write()) by se předával blok alokovaný zvláštní funkcí a nikoliv malloc(). Obdoba open() by připravila stránku, volajícímu (odesílajícímu) procesu by dala read-write přístup, příjmajícímu read-only a pak už nikdy žádné kopírování není třeba. Že příjemce má read-only přístup nevadí, protože ten už si to zkopíruje přirozeně zpracováním zprávy. Prostě stejný princip jako sdílená paměť, jen hezčí obal.

[Jakub Jermář]

A proč by neměl být omezován? Omezení bude, protože se mi prostě chce. Postup "Vyrobit buffer, naplnit buffer, předat buffer, počkat na výsledek." mi nepřijde nijak zvrácený. Spolus s recyklací jednou vyrobených bufferů to bude i rychlé (s výsledkem bude buffer vrácen pro další použití).

A kam se podelo to poslu zpravu a muzu delat neco jinyho, kdyz to neco jinyho je treba poslat dalsi zpravu nebo pracovat s daty, ktera jsou na stejne strance?

Myslim, ze se to takhle nedela prave proto, ze to ma jiz zminene problemy s: bezpecnosti, asynchronnosti, vykonem a neprakticnosti. Jestli to kvuli pouziti bude kopirovat odesilatel nebo prijemce, tak fakt nevim, kde je ta vyhoda, kdyz zamerem bylo vyhnout se kopirovani.

[linus]

a v podstate za to, ze sa ukoncil vyvoj hurdu, priamo moze Linus Torvalds a Richard Stallman, ktori sa rozhodli zahrnut linux do projektu GNU:))))))))

[Shadow]

Linux nebyl a není součástí projektu GNU.