Jaderné noviny – 15. 9. 2010: D-Bus v jádře? (diskuse)

[miki.lbc]

Tak tyhle jaderný noviny se mi líbí. Konečně jedny, který celý chápu. Tyhle témata se asi týkaj všech.

[kralyk z abclinuxu]

D-Bus nebyl navržen pro výkonnost tak jako MPI ...

Ano, to jsme si všimli

[stativ]

D-Bus v jádře? Jen to ne…

[Dusan]

Zníži to bezpečnosť? Prípadne pravdepodobnosť chýb? Prípadne zamŕzanie kernelu z externého zdroja? Zníži to výkon? Predĺži čas vývoja a opravy chýb? Prosím popíš prečo si myslíš, že je to zlé.

[Petr Tomášek]

Proc?

[Martin Mareš]

Právě že default je "D-bus v jádru není", takže by především měli dodat nějaký dostatečně pádný argument ti, kdož by tam jeho podporu rádi viděli.

Takovým argumentem by mohl být například benchmark, který by ukazoval, že reálné (a rozumně naprogramované) aplikace tráví v D-busu nezanedbatelné množství času.

Zkrátka k tomu, aby se do jádra přesouvalo něco, co lze vyřešit v uživatelském prostoru, by měly být setsakramentsky pádné důvody.

[trekker.dk]

takže by především měli dodat nějaký dostatečně pádný argument ti, kdož by tam jeho podporu rádi viděli.

Zvýšení výkonu dbusu (meziprocesového zasílání zpráv) s minimálním dopadem na zbytek jádra pro ty, kteří to v konfiguraci vypnou.

Zkrátka k tomu, aby se do jádra přesouvalo něco, co lze vyřešit v uživatelském prostoru, by měly být setsakramentsky pádné důvody.

V takovém případě by se z jádra měla odstranit třeba podpora pro sdílenou paměť. Lze ji vyřešit v uživatelském prostoru zapisováním sdílených dat do souboru.

[Jindřich Makovička]

Zvýšení výkonu dbusu (meziprocesového zasílání zpráv) s minimálním dopadem na zbytek jádra pro ty, kteří to v konfiguraci vypnou.

Jenže to zvýšení výkonu mi nepřišlo zas tak zásadní. Navíc, když už někdo chce tlačit skrz DBUS tisíce transakcí za sekundu, stálo by za to zamyslet se spíš nad tím, jestli je potřeba ty zprávy procesům posílat po jedné. Třeba u hlášení stavu IM kontaktů by agregace rozhodně pomohla.

[Martin Mareš]

Naprosto cokoliv lze zrychlit přesunem do jádra, ale to neznamená, že dává smysl tam postupně přestěhovat úplně celý user space.

Naopak přesun do jádra dává smysl jen tehdy, když:

(1) ukáže se, že implementace uvnitř jádra je výrazně rychlejší než v uživatelském prostoru a

(2) na té rychlosti opravdu záleží. Sdílení dat mezi paralelně běžícími procesy je často časově kritické a spousta programů tím (smysluplně) tráví 50 a více % času. Naproti tomu komunikace po D-busu je záležitostí spíše okrajovou, která se na celkovém výkonu aplikací nemá jak projevit.

[kralyk z abclinuxu]

Naprosto cokoliv lze zrychlit přesunem do jádra, ale to neznamená, že dává smysl tam postupně přestěhovat úplně celý user space.

Určitě souhlasím, nicméně rychlé IPC by tam být mohlo, ne?

[Martin Mareš]

UNIX-domain sockety? Netlink? Sdílená paměť? Co chybí?

[Vskutečnosti Saýc]

Posilani zprav.

[Martin Mareš]

Zprávu můžete triviálně poslat přes socket, co chcete víc?

[Vskutečnosti Saýc]

Abych mohl posilat zpravy mezi N procesy, budu potrebovat N socketu a drzet si nejakou mapu toho, ktery socket kam vede. To bych za trivialni neprohlasil.

[Martin Mareš]

A nestačí, aby měl každý proces jeden socket a používal sendto()?

[Vskutečnosti Saýc]

Jiste ze to staci. Ale mit mechanismus pro predavani by bylo rychlejsi a pohodlnejsi.

Koneckoncu, kdyby to nebylo potreba, nebude Dbus nacpany v kazde aplikaci. Jiste ze pokud aplikace kterou delam zavisi na rychlem rpedavani zprav, muzu ji proste napsat v erlangu a bude, ale to porad neznamena, ze by to nebylo fajn.

[Martin Mareš]

Ale mit mechanismus pro predavani by bylo rychlejsi a pohodlnejsi.

Ale sendmsg() je mechanismus pro předávání zpráv.

Koneckoncu, kdyby to nebylo potreba, nebude Dbus nacpany v kazde aplikaci.

Z více než 2500 balíčků, které mám na své pracovní stanici nainstalované, potřebuje D-bus sotva několik desítek. Takže tvrzení o tom, že je nacpaný v každé aplikaci, bych bral se značnou rezervou

D-bus je zkrátka jen jeden z mnoha používaných mechanismů na předávání zpráv a není ničím výjimečný. Ani nikdo neukázal, že by byl v nějakém smysluplném případě kritický pro rychlost. Takže je naprostý nesmysl ho přesouvat do jádra.

(Tím neříkám, že by si současná implementace D-busu nezasloužila přepsat. Použití XML pro konfigurační soubory ukazuje absolutní absenci citu pro návrh softwaru. A pokud se ukáže, že by se hodilo, aby se kernelové komunikační mechanismy (třeba netlink) naučily nějaké nové featurky, které D-busu pomohou, proč ne. Ale jádro má zůstat obecné, nikoliv šité na míru jednomu konkrétnímu módnímu výstřelku.)

[miso]

balicek != aplikace

[Martin Mareš]

Klidně číslo vydělte dvěma nebo třema (pak bude odpovídat počtu aplikací), řádově se nic nezmění.

[kralyk z abclinuxu]

Použití XML pro konfigurační soubory ukazuje absolutní absenci citu pro návrh softwaru.

Vždycky když se lidé podobně otírají o nasazení XML na nějakém místě, ptám se jich, co by bylo na tom místě lepší. Takže jaký formát bys pro konfiguraci D-Busu použil spíš a proč?
Měl bys například výhrady také proti JSONu?

(disclaimer: XML nemám nijak extra v lásce. Ale nelíbí se mi, když mnoho lidí kritizuje XML protože ho krizizuje mnoho lidí)

[pavlix]

Zkusím nastřelit aspoň svůj názor, když MJ ještě neodpověděl...

Konfiguraci v XML považuju za zlo (ale toleruju, pokud daná věc jinak plní svůj účel).

Konfiguraci v JSONu trochu používám pro své vlastní věci. Je to o dvě třídy lepší pro tenhle účel než XML. Je to obecné a funguje to... teda nouzově.

Na druhou stranu, nepovažuju JSON za ideální konfigurační formát, spíš dávám přednost formátům se složenýma závorkama, středníkama a klíčovýma slovama, prostě nějakou variantou takového toho c-like formátu.

Je stručnější než JSON (který je stručnější než XML), což je u konfigurace klíčová vlastnost, čím míň omáčky, tím líp...

A jedna klíčová věc... JSON je sice obecný datový formát s podporou polí a key-value slovníků, ale pokud vím tak neumí komentáře. Smysluplný konfigurační jazyk komentáře umět prostě *musí*.

Pak mě napadá ještě jedna... a to je hlášení chyb při parsování. Běžné parsery JSONu jednak parsují celý strom a ten předávají aplikaci, což by se dalo napravit nějakým SAX-like parserem... ale hlavně... aplikace nezná čísla řádků! Tudíž pokud parsování proběhe v pořádku, ale je tam nějaká konfigurační chyba, kterou aplikace detekuje, tak nemá možnost odkázat administrátora na konkrétní řádek, kde byla chyba detekována.

[kralyk z abclinuxu]

spíš dávám přednost formátům se složenýma závorkama, středníkama a klíčovýma slovama, prostě nějakou variantou takového toho c-like formátu.

Souhlasím, že tenhle formát je dobrý, problém je, že (AFAIK) bohužel neexsituje jednotný standard, a tak si to každá aplikace implementuje jinak... což je problém.

A jedna klíčová věc... JSON je sice obecný datový formát s podporou polí a key-value slovníků, ale pokud vím tak neumí komentáře. Smysluplný konfigurační jazyk komentáře umět prostě *musí*.

Hm, jo no, to je u JSONu problém. Některé parsery nicméně komentáře neoficiálně podporují, jako např. jsoncpp, který trochu znám. Ve standardu to ale už není, bohužel.

ale hlavně... aplikace nezná čísla řádků!

Hm, tohle bude spíš záležitost parseru, než formátu jako takového, ne?

[pavlix]

a tak si to každá aplikace implementuje jinak... což je problém.

Zas tak velký problém to není. Trochu to komplikuje tvorbu specializovaných editorů těch konfiguračních souborů (různých grafických nebo web rozhraní apod).

Hm, jo no, to je u JSONu problém. Některé parsery nicméně komentáře neoficiálně podporují, jako např. jsoncpp, který trochu znám. Ve standardu to ale už není, bohužel.

Potom to chce se shodnout aspoň na commented JSON :).

Hm, tohle bude spíš záležitost parseru, než formátu jako takového, ne?

Teoreticky ano. Šlo by ty čísla řádků pro aplikaci ukládat. Nějaký SAX-like parser by to mohl umět, objektový parser taky, pokud to neni nějaké implicitní mapování. Ale dělá to nějaký?

[Martin Mareš]

Vždycky když se lidé podobně otírají o nasazení XML na nějakém místě, ptám se jich, co by bylo na tom místě lepší.

Obecná odpověď je, že S-expressions (alias lisp-like uzávorkované výrazy) jsou v každém případě lepší než XML, protože umějí totéž a daleko jednoduššími prostředky. Ale ačkoliv jsou lepší, od optima mají v případě konfigurace stále propastně daleko.

Použil bych formát, který je především rozumně čitelný pro lidi (věci se v něm nepíší zbytečně komplikovaně) a který umožňuje konfiguraci snadno skládat z více částí (včetně toho, že lze předefinovat cokoliv už nadefinovaného, tedy například distribuční defaulty).

Jeden takový jsme kdysi s Robertem Špalkem spáchali (viz popis) a myslím, že se osvědčil. Je to docela dobrý kompromis mezi strojovou zpracovatelností, příjemností pro lidi a flexibilitou.

[tom]

V takovém případě by se z jádra měla odstranit třeba podpora pro sdílenou paměť. Lze ji vyřešit v uživatelském prostoru zapisováním sdílených dat do souboru.

Az na to, ze presne tak je to naimplementovane. Udela se soubor v "ramdisku" v /dev/shm a ten si procesy namapuji :P

[trekker.dk]

Ok, tak třeba pro souborové systémy. Ty lze taky vyřešit v uživatelském prostoru zápisem přímo na zařízení.

[pavlix]

A jak potom bude jádro spouštět ten uživatelský prostor. Myslím tím obecné distribuční jádro, ne zkompilované na míru.

[trekker.dk]

Vím já, třeba tak, že to, co se má spustit, musí začínat na disku na adrese xyz. Podstatné je pro mě to, že to jde vyřešit a to je podle všeho jediné kritérium, které toto vlákno má.

[pavlix]

Filesystém je právě abstrakce, která slouží k tomu, aby to, co se má spustit, mohlo začínat na libovolné adrese a vyhledávalo se podle jména.

Podstatné je pro mě to, že to jde vyřešit a to je podle všeho jediné kritérium, které toto vlákno má.

Až na to, že ty jsi reagoval na Martina, který rozhodně toto za jediné kritérium neoznačil.

Dokonce ve všech třech větách toho příspěvku dává najevo úplně jiné kritérium.

[Sten]

V jádře nebude D-Bus, ale podpora D-Busu. Stačilo by si přečíst tu zprávičku

[stativ]

Samozřejmě jsem si přečetl a za svým názorem si stojím. Už teď je jádro až příliš nabubřelé a přidání další věci, která může být docela snadno implementované a user space věci rozhodně nepomůže.

A proč mi vadí nabubřelost jádra? Jádro je pak náchylnější k chybám – čím víc kódu tím víc chyb. A samozřejmě když ten kód běží v kernel space, tím nebezpečnější ty chyby můžou být.

[petr_p]

Ale chápejte, že předávání zpráv musíme do jádra dostat. Jak jinak chcete z Linuxu udělat mikrojádro?

[mimi.vx]

+1

[stativ]

Já tak nějak čekal, že už tam něco je.

[Aleš Janda]

Právě že moc není. Pokud vím, tak předávat zprávy mezi procesy se dají pomocí POSIX messages, jenže to není navázané na konkrétní proces, v podstatě se to chová jako soubor a po ukončení procesu to tam zůstane (pokud ho ten proces po sobě explicitně nesmaže). Pak je tu mkfifo, což má podobný problém, pak sdílená paměť (opět, to samé, při sestřelení to zůstane viset v paměti), anonymní mmap (to skončení procesu nepřežije, ale lze předávat jen v rámci dvou procesů, kde jeden vznikne fork()em druhého. Navíc žádný z těchto způsobů neumožňuje předat data procesu s konkrétním PID. A nakonec tu jsou signály - ty jsou ale kvůli asynchronnosti jednak příšerné řešení a jednak se dá předat samotná informace „nastal signál“, ale už se nedají předat žádná data.

Takže d-bus na úrovni jádra by byl hodně fajn.

[tom]

A nakonec tu jsou signály - ty jsou ale kvůli asynchronnosti jednak příšerné řešení a jednak se dá předat samotná informace „nastal signál“, ale už se nedají předat žádná data.

Daji se predat data minimalne o velikosti adresy. A vubec toho jde delat mnohem vic - RTFM signal(7).

Pak tu jsou jeste SYS-V zpravy a sockety.

A sdilena pamet jde udelat i tak, aby potom, co ji vsichni odmapuji, byla uvolnena.

[Martin Mareš]

Signály můžete navíc provozovat i synchronně, viz signalfd(2).

[m]

Male nedopatreni: Clanek se nezobrazuje v sekci http://www.abclinuxu.cz/clanky/jaderne-noviny

Diky za opravu a za ctivy serial