Jaderné noviny – 5. 7. 2012: Jaderné urychlení D-Busu (diskuse)

[Jardík]

Řešení přece existuje. Forknout linux!

[kei.101]

To spíš přejít na BSD.

[Salamek]

Ono kazda distribuce je vice mene fork vanila linuxu :)

[pavlix]

Řešení čeho?

[pavlix]

Najděte si prosím velkou pastelku a na čelo si napište „když opravuji chybu, tak vždy musím popsat dopad této chyby na uživatele“.

Zkoušel sis kreslit pastelkou po kůži?

http://en.wikipedia.org/wiki/Crayon

[Jardík]

sis?

[zxtlpn]

Mhm?

[Jardík]

Hmm... nikdy jsem to neviděl ^^.

[pavlix]

Člověk se pořád učí.

[Peter Golis]

Stačí trošku nahriať.

[aaaaaaaaaaaaaaa]

8k stacky jsou na x86-64 příliš malé při stále složitějších úložných vrstvách a hloubkách volání o více než 100 funkcích.

To myslia vazne? Ja si nedokazem udrzat "globalny pohlad" uz pri necelych 20 neprazdnych vrstvach v Jave, takze zo mna asi kernel developer nebude :-/.

[stativ]

Rekurze?

[pavlix]

Ten AF_BUS zní docela zajímavě a mohl by z toho být pěkný flame.

[BFU]

Mohl ? ...

[chrono]

Možno by celkom stačilo, aby si aplikácie cez DBUS neposielali obrovské množstvo dát (a ak už musia, tak aby radšej posielali jednu veľkú správu, ako 100 malých).

[Jardík]

Já jsem zatím nenarazil na SW, co by posílal nějaká velká data přes dbus. Zatím tak možná networkmanager, udisks(2), kdysi HAL, ... a ty všichni posílájí pár informací o které si řeknete. Potom ještě GTK aplikace používající G(tk)Application se usídlí na dbusu a ty si většinou posílají akorát argumenty do předchozí instance aplikace, aby běžela jen jednou.

[Luboš Doležel (Doli)]

No to je geniální. A jako řešení nedostatečných diskových kapacit prostě nebudeme ukládat data.

a ak už musia, tak aby radšej posielali jednu veľkú správu, ako 100 malých

Tak tě odpojíme od Internetu a na konci měsíce nám vždy dáš soupis toho, co chceš za data. Abys to měl jako jeden velký download místo X malých.

[Michal Vyskočil]

Až na to, že tohle neřeší žádný z problémů (latence, context switch, inverzní priority), které má AF_BUS řešit.

[Martin Mareš]

Přes několikeré výzvy v LKML jsem neviděl, že by proponenti AF_BUS ukázali naměřená data, ze kterých by bylo vidět, že tyto problémy doopravdy existují. Zatím jenom máchají rukama a mají plnou tlamu řečí o tom, jak moc je to potřeba, ale to v komunitě okolo jádra vážně nefunguje. Jinými slovy nejprve by měli ukázat, že AF_BUS řeší nějaké reálné problémy, nejen hypotetické.

[pavlix]

+1

A ideální by bylo, kdyby se to opravdu netýkalo jen dbusu ale i dalších obdobných systémů.

[dumblob]

A ideální by bylo, kdyby se to opravdu netýkalo jen dbusu ale i dalších obdobných systémů.

+1

[Michal Vyskočil]

Tak já o tom víc docela kulové, takže jsem napsal má řešit.

[stativ]

Dřív jsem to považoval za zbytečné bobtnání jádra, protože jsem uvažoval d-bus jenom za jakousi ptákovinu, která mi umožňuje volat nějaké funkce různých programů. Když jsem si neuvědomil, že to vlastně není nic jiného než nástroj pro meziprocesovou komunikaci, tak jsem svůj názor rychle změnil.

Něco takového mělo být v jádře už dávno. Potřeba komunikace mezi procesy je vcelku častá věc. Kvůli tomu tady spousty různých implementací běžící v userspace, a všechny mají problém s řešením latence. A za bloat se to moc považovat nedá, uvažujeme-li, že prostředky pro meziprocesovou komunikaci jsou základním kamenem mikrokernelů.

[pavlix]

Dřív jsem to považoval za zbytečné bobtnání jádra, protože jsem uvažoval d-bus jenom za jakousi ptákovinu, která mi umožňuje volat nějaké funkce různých programů. Když jsem si neuvědomil, že to vlastně není nic jiného než nástroj pro meziprocesovou komunikaci, tak jsem svůj názor rychle změnil.

+1

Stejným vývojem bude procházet množství jaderných vývojářů. Ale podle mě je dobře, že AF_BUS nechtějí, protože to vytváří tlak na revizi AF_BUS vzhledem k ostatním IPC službám. A tím, že budou vývojáři potřebovat podporu vývojářů jiných IPC, se zajistí univerzalita a kvalita této implementace.

A za bloat se to moc považovat nedá, uvažujeme-li, že prostředky pro meziprocesovou komunikaci jsou základním kamenem mikrokernelů.

D-bus je prostě do určité míry neoblíbený. Má to svoje důvody, i validní, o tom bych se mohl rozpovídat, ale to radši udělám, až budu mít v ruce nějakou možnost nápravy.

Ale v tuhle chvíli nevím o žádné smysluplné náhradě a spíš mi přijde, že by mělo smysl zapracovat na tom dbusu.

[stativ]

Stejným vývojem bude procházet množství jaderných vývojářů. Ale podle mě je dobře, že AF_BUS nechtějí, protože to vytváří tlak na revizi AF_BUS vzhledem k ostatním IPC službám. A tím, že budou vývojáři potřebovat podporu vývojářů jiných IPC, se zajistí univerzalita a kvalita této implementace.

Rozhodně souhlasím. Krom toho, špatně navržené API je skoro horší než žádné, protože takového API se člověk těžko zbaví.

[dumblob]

+1

[little.owl]

+1

[Ladicek]

Proto třeba Android má vlastní IPC v jádře (Binder) od samého začátku.

[Ondrej 'SanTiago' Zajicek]

Jedna vec je ze by se hodila nejaka rozumna lokalni meziprocesorova komunikace, druha vec je, zda ty detaily, ktere ma dany navrh AF_BUS, jsou rozumne. Me napadaji hned dve pripominky:

1) Je otazka, zda zavadet novou AF, kdyz mame AF_UNIX pro streamove IPC, mozna by plne stacilo ji rozsirit o (unicastovou a multicastovou) datagramovou komunikaci.

2) Pristup AF_BUS k reliable multicastum (pokud nejaky prijemce nema misto v prijimacim bufferu, selze send) je IMHO dost podivny. IMHO je daleko rozumnejsi se na reliable multicasty vykaslat, zavest pouze ordered multicasty (se zajistenim usporadani mezi unicasty a multicasty na stejnem socketu) s tim, ze pri 'vypadku' se nahodi flag a receiver se o nem tedy dozvi.

[stativ]

AF_DBUS jsem nestudoval, ale je fakt, že dobré API se musí pořádně upéct. Chtělo by to, aby se do diskuse zapojilo co nejvíce více lidí, včetně vývojářů jiných IPC řešení. Hodně by mohli pomoci lidi stojící za zmiňovaným Binderem v Androidu.

[pavlix]

AF_BUS

[Michal Vyskočil]

1) Je otazka, zda zavadet novou AF, kdyz mame AF_UNIX pro streamove IPC, mozna by plne stacilo ji rozsirit o (unicastovou a multicastovou) datagramovou komunikaci.

Pokud si pamatuji, tak AF_UNIX byl zavržen správci jádra kvůli příliš komplexnímu kódu.

2) Pristup AF_BUS k reliable multicastum (pokud nejaky prijemce nema misto v prijimacim bufferu, selze send) je IMHO dost podivny. IMHO je daleko rozumnejsi se na reliable multicasty vykaslat, zavest pouze ordered multicasty (se zajistenim usporadani mezi unicasty a multicasty na stejnem socketu) s tim, ze pri 'vypadku' se nahodi flag a receiver se o nem tedy dozvi.

Souhlasím - kdo by chtěl systém, jehož IPC je možné tak triviálně zablokovat.

[Martin Mareš]

Pokud si pamatuji, tak AF_UNIX byl zavržen správci jádra kvůli příliš komplexnímu kódu.

No právě – a teď se ty nejsložitější věci (jako předávání file-descriptorů) kopírují i do AF_BUS :(

DBUS přeci nepotřebuje tak často předávat FD, aby to nešlo vyřešit pomocným socketem v AF_UNIX.

[kralyk z abclinuxu]

Něco takového mělo být v jádře už dávno. Potřeba komunikace mezi procesy je vcelku častá věc.

Ano, ale v jádře to dost dobře nemůže být tímhle způsobem...

Ta nutnost bežícího démona je imho nějvětší nevýhoda D-Busu. Mnohem lepší by bylo, aby jádro poskytovalo dostatek použitelných IPC primitiv a nad nimi se může postavit userspace implmentace, třeba kniovna, pomocí které by aplikace komunikovaly P2P bez nutnosti centrálního bodu (mimo jádro, samozřejmě).

Je dokonce otázka, jak moc na tohle současná IPC/synchronizační primitiva poskytovaná Linuxovým jádrem stačí / nestačí. Imho by klidně mohla. Viz např. jak to řeší Chromium. Neříkám, že to má řešeno ideálně, jen se mi ta filosofie zamlouvá mnohem víc než D-Bus. Je to taky lepší z hlediska multiplatformnosti - D-Bus zrovna dvakrát přenositelný není.

[petr_p]

Linux má velké množství IPC primitiv. Bohužel žádné nesplňuje všechny požadavky. A cetrální bod je třeba – někdo musí garantovat identitu komunikujících stran a zajistit synchronizaci. Nebo chceš, aby přehrávač hudby hlasoval, jestli upowerd smí zavolat halt(2)?

[kralyk z abclinuxu]

A cetrální bod je třeba – někdo musí garantovat identitu komunikujících stran a zajistit synchronizaci.

To mi nepřijde dostatečné odůvodnění. Na to, aby mi přehrávač nesmazal systém, taky nepotřebuju démona, kterej to bude hlídat.

[Ondrej 'SanTiago' Zajicek]

Vyhoda lokalnich IPC primitiv je ta, ze autentizaci muze zajistit kernel. Treba u unix socketu se proste ridi beznymi pristupovymi pravy onoho socketu.

Zda je treba centralni dbus daemon - no nevim, bezny a leta overeny pristup je ten, ze kdo poskytuje nejakou sluzbu, ten si proste vytvori vlastni unix socket, a kdo ji chce vyuzit, tak ten socket proste otevre a preda pozadavek.

[kralyk z abclinuxu]

bezny a leta overeny pristup je ten, ze kdo poskytuje nejakou sluzbu, ten si proste vytvori vlastni unix socket, a kdo ji chce vyuzit, tak ten socket proste otevre a preda pozadavek.

Jasný, při client-server architektuře to celkem není problém. Horší je, když potřebuješ komunikovat mezi N aplikacemi, z nichž žádná není server a u žádné není známo, jestli bude ukončena dříve nebo později než kterákoli jiná.

Jako příklad viz Oxygen (Qt Styl). Ve chvíli, kdy v nastavení systému změníš barevné schéma (nebo prostě nějaký nastavení Oxygenu), tak ta aplikace, která to nastavení změnila, pošle po D-Busu zprávu všem ostatním Qt aplikacím, že si mají nastavení aktualizovat a projevit změny navenek.

Jak by se tohle řešilo bez centrálního bodu? Napadá mě akorát nějaká kombinace signálů a shmem, ale fakt nevim, jestli by to takhle šlo udělat použitelně a efektivně...

[Ivan]

Kdysi jsem na jednom sytemu zalozenem na zpravach delal. Na prvni pohled to bylo hezky a rychle se v tom vyvijelo. Vsechno bylo pekne izolovany. Kdyz ale nastaly nejaky problemy tak se to neskutecne blbe ladilo. I kdyz mate core dump, tak stejne nezjistite kdo komu poslal jakou zpravu a v hlavne v jakym poradi. Taky nebylo uplne jednoduchy dodrzet jednotny format zprav napric celym systemem.

Suma sumarum mi prijde, ze D-Bus je vylozene desktopova zalozitost. Uz treba jen to spousteni sluzeb podle potreby - kdo to potrebuje? Kdysi se Woknam vycitalo, ze se z desktopovyho systemu dela server. Linux jde dneska stejnou cestou. Veci, ktery puvodne vznikly pro desktop pomalu musi bezet i na serveru.

Pritom na je na posilani zprav zalozen i kazdy cluterware sw. Podivejte se jak funguje treba Veritas anebo Oracle RAC(evms).

[kralyk z abclinuxu]

Kdysi jsem na jednom sytemu zalozenem na zpravach delal. Na prvni pohled to bylo hezky a rychle se v tom vyvijelo. Vsechno bylo pekne izolovany. Kdyz ale nastaly nejaky problemy tak se to neskutecne blbe ladilo. I kdyz mate core dump, tak stejne nezjistite kdo komu poslal jakou zpravu a v hlavne v jakym poradi. Taky nebylo uplne jednoduchy dodrzet jednotny format zprav napric celym systemem.

Souhlasim, taky bych do toho radši nešel, ne tam, kde se dá použít jiný mechanismus. Komplexnost D-Busu se mi vůbec nelíbí. Ale někdy prostě nějaké to IPC potřebuješ.

Uz treba jen to spousteni sluzeb podle potreby - kdo to potrebuje?

Třeba já

[Josef Kufner]

DBus také umí služby spouštět až když jsou potřeba. To jde s unixovými sockety docela těžko a je to jeden z hlavních důvodů, proč je centrální démon potřeba.

[petr_p]

A co je Linux, který řeší přístupová práva k socketům? To není centrální démon? Nezapomeň, že unixové sockety nejsou jen o otevření socketu, ale také o zasílání ověřené totožnosti (SCM_CREDENTIALS), což je věc kterou s jiným socketem nebo mimo jádro neuděláš (zůstaňme na úrovni socketu; samozřejmě že je možné vytvořit autentizační mechanismus na vyšší úrovni).