kdbus

Dlouhodbou absenci kvalitního IPC pro GNU/Linux řeší projekt kdbus Grega Kroah-Hartmana. Doposud nezávislý vývoj dospěl do stadia zařazení do hlavní větve jádra, s čímž se počítá pro verzi 3.19.

30.10.2014 16:08 | Petr Ježek | Zajímavý projekt

Komentáře

[trekker.dk]

Dlouhodbou absenci kvalitního IPC pro GNU/Linux

Tohle je přinejlepším věc názoru...

[Hans1024]

+1

to je zase "zpravicka"

[Heron]

Především je ta věta nesmyslná. Co není na například sdílené paměti kvalitní?

Někteří tydíít chápou pojem IPC po svém a podle toho to potom vypadá.

[backinabag]

Nic, ale pro spoustu situaci je vhodejsi IPC ala dbus.

[Heron]

Například? Už jsem se tu na to ptal 2x a na první dotaz mi nikdo neodpověděl a na druhý jsem dostal standardní arogantní odpověď.

[kralyk z abclinuxu]

Sdílená paměť není moc dobrá třeba na notifikace a podobné, tj. menší objemy dat, ale "interaktivní". Asi je blbost někde cyklicky číst kus sdílené paměti a čekat, až se tam změní hodnota, že...

Jinak sdílená paměť je synchronizační primitivum, zatímco D-Bus je v podstatě high-level framework, čili to bych moc nesrovnával. Doporučil bys případně nějakou alternativu k D-Bus, která by poskytovala podobně high-level API?

[TM]

Prozradím vám jedno tajemství. Již desítky let se na Unixu jako IPC používá _nejen_ sdílená paměť.
Jako domácí úkol se na to mrkněte a třeba i vyzkoušejte. Budete překvapen.

[kralyk z abclinuxu]

Heron se ptal, na co není vhodná sdílená paměť, alespoň tak jsem to pochopil. O ostatních sync. primitivech taky něco tuším, neboj

[pavlix]

Nebylo by lepší takový komentář vůbec nepsat?

[Andrej]

Proč by se ve sdílené paměti něco četlo v cyklu? Mám-li na něco čekat, od toho jsou standardní synchronizační primitiva (například podmínkové proměnné nebo semafory) a flag PTHREAD_PROCESS_SHARED.

[kralyk z abclinuxu]

*facepalm*

[Andrej]

Jo, přesně takový dojem jsem získal už z výše uvedeného nesmyslu, že sdílená paměť je prý „synchronizační primitivum“. Takový výrok je vskutku na facepalm. Jinak ani náznakem nehájím ten či onen typ IPC, jen jsem si zkrátka všiml nesmyslu (zaprvé tohoto a zadruhé toho s opakovaným čtením paměti), na který jsem (off-topic) zareagoval.

[pavlix]

+1

[kralyk z abclinuxu]

Pardon, sdílená paměť není synchronizační primitivum, ale IPC primitivum... Myslel jsem A napsal jsem B.

a zadruhé toho s opakovaným čtením paměti

Zprávička: (...) Dlouhodbou absenci kvalitního IPC pro GNU/Linux (...)
Heron: Co není na například sdílené paměti kvalitní?
kralyk: Sdílená paměť není moc dobrá třeba na notifikace a podobné, tj. menší objemy dat, ale "interaktivní". Asi je blbost někde cyklicky číst kus sdílené paměti a čekat, až se tam změní hodnota, že...
Andrej: Proč by se ve sdílené paměti něco četlo v cyklu? Mám-li na něco čekat, od toho jsou standardní synchronizační primitiva (...)

Já nikdy žádné cyklické čtení paměti nenavrhoval, pouze jsem se snažil Heronovi napsat příklad, kdy sdílená paměť není vhodná pro IPC. Opravdu nevím, proč jsi mi napsal, že by se to mělo řešit jinak, když právě to byla pointa mého komentáře. Odtud ten facepalm.

[pavlix]

Až do toho facepalmu to vypadá na nedorozumění, pak už spíše neschopnost to nedorozuměmí rozeznat a napravit.

[Heron]

V zprávičce je napsáno: Dlouhodbou absenci kvalitního IPC. To znamená že dle auta zprávičky není žádná metoda IPC v linuxu kvalitní. Já jsem si tedy z té množiny IPC vybral zrovna shm a zeptal se, co na metodě IPC sdílené paměti není (nejlépe bych očekával odpověď od samotného autora této myšlenky) kvalitní. Odpovědi jsem se nedočkal. To, že shm se nehodí na všechny problémy světa je mi tak nějak jasné už hodně dlouho.

[kralyk z abclinuxu]

To znamená že dle auta zprávičky není žádná metoda IPC v linuxu kvalitní.

Autor to napsal natolik vágně, že nevíme, jak to myslel. Jinak na tvou otázku vlastně nedá odpovědět jinak než "Nic." Takže moc nevím, proč se vlastně ptáš. Ještě mně napadá to, že jsou pro shm dvě různá API, SysV shm a POSIX shm, ale počítám, že to taky nebude známka nekvality...

[pavlix]

Já chápu heronův dotaz především jako upozornění na tendenční formu zprávičky. A s tím s ním bohužel musím souhlasit. Ono se dá o technologiích buď diskutovat z pohledu jejich kvalit a užitné hodnoty, nebo se dají velebit na základě toho, že buď pochází od, nebo jsou schvalovány, určitou privilegovanou skupinou lidí. Styl zprávičky napovídá, že se jedná o to druhé.

[backinabag]

Napriklad kdyz potrebujes publish-subscribe nebo komunikovat formou posilani zprav. Konkretne muzes napriklad chtit dostat notifikaci kdyz se zmeni hlasitost.

[Heron]

Konkretne muzes napriklad chtit dostat notifikaci kdyz se zmeni hlasitost.

Já věděl, že se nemám ptát, protože hrozilo, že dostanu odpověď.

Takže k vůli notifikaci o změně hlasitosti (no, snad vím, že jsem změnil hlasitost, to mi to nemusí psát) se musí psát modul do jádra?

[backinabag]

Proc je potreba dbus - nekdy to je lepsi zpusob meziprocesove komunikace nez alternativy jako je sdilena pamet. Napriklad pokud potrebujes publish-subscribe, konkretne muzes chtit ukazatel hlasitosti synchronizovany se systemovou hlasitosti.

Proc to davat do jadra - napriklad kvuli rychlosti, dalsi duvody viz http://en.wikipedia.org/wiki/D-Bus.

[Heron]

Mě se líbí, jak se všichni chytají té sdílené paměti. To byl příklad. Navíc ten nejextrémnější, protože běžně různé procesy (nedej bože různých uživatelů) nemohou zasahovat do paměťového prostoru jiných procesů. Sdílená pamět se používá hlavně pro sdílení dat mezi vlákny. Jen těžko může být něco rychlejšího.

Jinak IPC prostředků existuje pochopitelně daleko víc, od prostých souborů, trubek, socketů, signálů, zpráv až po tu paměť.

To, co umí (K)DBUS se jaksi dá realizovat už desítky let. Jinými prostředky. Je to zcela nadbytečné. A přijde mi uhozené, že cosi, co vzniklo pro kraviny typu "notifikace hlasitosti" (proboha proč? copak uživatel je takovej debil, že ani neví co dělá a musí se mu to ještě explicitně zobrazit?) se má najednou dostat do jádra. Aby se ta notifikace poslala o 200ns dřív a o dva context switche méně? Vážně?

Služby typu DBUS vypínám už více než 8 let (první dotaz). Teď se to projistotu dává do jádra. Aby to mohl systemd začít vyžadovat. Userland spojený s jádrem. Paráda.

[backinabag]

Mě se líbí, jak se všichni chytají té sdílené paměti. To byl příklad.

Ja si uvedomuju ze to byl priklad, proto jsem psal "nez alternativy jako je sdilena pamet". (Zaroven jsem psal, ze dbus je lepsi nez alternativy jenom nekdy.)

To, co umí (K)DBUS se jaksi dá realizovat už desítky let. Jinými prostředky. Je to zcela nadbytečné.

Takze tvrdis, ze ve vsech pripadech kde se dnes dbus pouziva je vhodnejsi pouzit neco jineho? Ze si ti vyvojari vybrali spatne?

Mimochodem, jaky existujici IPC prostredek bys pouzil pro publish-subscribe?

kraviny typu "notifikace hlasitosti" (proboha proč? copak uživatel je takovej debil, že ani neví co dělá a musí se mu to ještě explicitně zobrazit?)

Kdyz se divam na film ve fullscreen, tak chci mit ovladac hlasitosti primo v tom prehravaci.

Aby se ta notifikace poslala o 200ns dřív a o dva context switche méně? Vážně?

Nevim, ale myslim ze o 200ns rychlejsi notifikace o zmene hlasitosti neni duvod proc to prepsali do kernelu.

[Michal Kubeček]

Já se spíš obávám toho, aby kdbus nebyl zbytečně moc jednoúčelový. Docela se mi líbila myšlenka multicastu pro PF_UNIX sockety. To bylo sice zamítnuto s tím, že implementace unix domain socketů je už takhle dost zmatená na to, aby se tam ještě doimplementoval multicast, ale nová implementace lokální multicastové komunikace s minimálním overheadem by IMHO byla prospěšnější než specifický framework psaný s vidinou a šitý na míru jen a pouze D-busu.

[luky]

Mimochodem, jaky existujici IPC prostredek bys pouzil pro publish-subscribe?

netlink - nl_socket_add_memberships()

[Heron]

Takze tvrdis, ze ve vsech pripadech kde se dnes dbus pouziva je vhodnejsi pouzit neco jineho? Ze si ti vyvojari vybrali spatne?

Ne, netvrdím, že ve všech. Tvrdím, že to šlo realizovat i dříve. A je možné, že si někde vybrali špatně.

Mimochodem, jaky existujici IPC prostredek bys pouzil pro publish-subscribe?

Žádný.

Kdyz se divam na film ve fullscreen, tak chci mit ovladac hlasitosti primo v tom prehravaci.

Tohle jsem nepochopil. Pominu-li můj setup (12 kanálový mixpult), tak hlasitost se nastavuje na budiči (předzesilovači) koncového zesilovače. Takže když mám film na fullscreen, tak sáhnu po IR dálkovém ovládání zesilovače a tam to řeším. Pokud tohle z nějakého podivného důvodu nechci dělat, tak se dá pořád ovládat ona aplikace a zeslabit výstupní signál z ní. Prostoru pro to je na těch 24b docela dost. (Stejně je ten audio stream 16b, takže je zde 256 úrovní hlasitosti než to začne ztrácet informaci. HW mix čipy mají 64 úrovní zisku a stačí to.)

[backinabag]

Ne, netvrdím, že ve všech. Tvrdím, že to šlo realizovat i dříve. A je možné, že si někde vybrali špatně.

Super, takze dbus ma smysl. Drive slo samozrejme realizovat vsechno co umi dbus, dbus je jenom nadstavba nad existujicimi IPC mechanismy.

Tohle jsem nepochopil.

V podstate chci mit synchronizovany ovladac hlasitosti v panelu a ovladac hlasitosti v prehravaci. Umi to treba VLC, ale nevim jak to dela.

[Václav HFechs Švirga]

Nemám pulseaudio. Alsa má dva kanály - master a PCM. Používám přehrávač mocp na hudbu, ten mi umožňuje vybrat si, jestli, když v něm změním hlasitost, se změní kanál PCM nebo se změní hlasitost jen v aplikaci (aplikace si to přepočítá a sniží amplitudu - softwarový kanál). To stejné umí mplayer (přehrávač videa). U VLC jsem to nezkoumal. První případ je synchronizovaný s hlasitostí na panelu, protože ta taky ovláda kanál PCM a od alsy ví, jakou má uroveň (pravděpodobně to kontroluje nějakým poolingem, nebo ji snad i alsa notifikuje - netuším, do alsa api tolik nevidím). Jde mi o to, že tenhle usecase v Linuxu běžně léta funguje a nic jako dbus (a ani pulseaudio) nepotřebuje. Podotýkám, že funguje i když hraje více aplikací naráz a nic se nemusí nastavovat (protože jsem už slyšel FUD, že softwarové směšování zvuku z více aplikací naráz přineslo pulseaudio - nepřineslo, stará se o to dmix).

Přitom dbus se mi líbí, ale pro tohle použití je, aspoň teda na architektuře s alsou, do pulseaudia nevidím, naprosto zbytečný a nepoužívá se.

[Václav HFechs Švirga]

vidím, že už reagovali ostatní níže , tak sry za spam :P

[Václav "Darm" Novák]

PA asi nějakou formu IPC potřebuje, protože tam má každá aplikace vlastní šavli v mixeru.

[trekker.dk]

copak uživatel je takovej debil, že ani neví co dělá a musí se mu to ještě explicitně zobrazit?

Příklad: změním hlasitost v mplayeru, automaticky se změní poloha ovládacího prvku v kmix. Totéž když změním hlasitost v jiném xserveru. Proč je to dobré? Protože ten posuvník neukazuje něco jiného než skutečnost. A tím pádem když začnu měnit hlasitost v jiném programu, tak se začne měnit od aktuální hlasitosti, ne od té, kterou si ten program myslí, že je aktuální.

Tím neříkám, že kvůli tomu musel vzniknout kdbus, na tohle dbus bohatě stačí.

[petr_p]

Stačí vyhubit pulseaudio. ALSA tohle umí. (Pusť si dva alsamixery a v jednom měň hodnoty. Je to udělaný tak, že událost o změně přijde přes zařízení /dev/snd/control*.)

Každý subsystém má vlastní způsob zasílání událostí (například přes netlink můžete sledovat, jak se vám mění tabulka spojení ve stavovém firewallu, přes X11 rozmístění oken na plochách). Tím neříkám, že je dobré, aby každý subsystém měl vlastní mechanismus.

Problém D-Busu je, že místo univerzálního mechanismu je to opět řešení šité na jedno použití (zeptejte, kam se ztratila síťová přenositelnost X11, kam se ztratila rychlost netlinku).

Doufám, že kdbus něco z toho vyřeší a že to do budoucna bude další krok k mikrokernelu. Jen je škoda, že to je opět linuxově specifické řešení. Unixové sockety pro D-Bus alespoň byly všude.

[trekker.dk]

Stačí vyhubit pulseaudio.

Nemám.

Je to udělaný tak, že událost o změně přijde přes zařízení /dev/snd/control*

Ok, tohle jsem nevěděl.

Problém D-Busu je, že místo univerzálního mechanismu je to opět řešení šité na jedno použití

Je to řešení pro desktop - tím myslím normální desktop - a tam funguje. Bohužel někoho napadlo, že místo jednoduchých dat (událostí apod.) by bylo výborné tahat tudy všechno.

[Václav "Darm" Novák]

Nabídni plnohodnotnou náhradu za PA a zvážím jeho nahrazení.

[Frack]

Aby se ta notifikace poslala o 200ns dřív a o dva context switche méně? Vážně?

Celý kdbus se dělá především kvůli sandboxovaným kontejnerům pro linuxové aplikace. Veškerá komunikace aplikace se systémem a ostatními aplikacemi by totiž měla probíhat přes DBus. To obnáší třeba 4k video stream, což userspacová implementace DBusu nedává ani omylem. Ta kernelová by měla.

Na to, jestli se obyčejná notifikace pošle o 200ns dřív nebo ne, sere pes.

[trekker.dk]

Veškerá komunikace aplikace se systémem a ostatními aplikacemi by totiž měla probíhat přes DBus.

...protože rozhodně není možné to udělat něčím, co už existuje. Třeba pomocí socketů (silně pochybuju, že ten 4k video stream je zapotřebí broadcastovat do několika aplikací současně v tolika tak odlišných případech, aby to ospravedlnilo strkat takovouhle věc do jádra.)

[Hans1024]

4k video by ten socket mohl asi limitovat, ale tohle uz davno vyresila Xka, ktera pro prenos velkych pixmap pouzivaji MIT-SHM snad uz od devadesatych let.

[kralyk z abclinuxu]

+1 ... imho na takovou věc jedině SHM. Přes D-Bus to tak maximálně synchronizovat, jestli vůbec...

[Frack]

To je super, že to jde udělat i jinak, ale taky to musí být něco, nad čím jde udělat solidní bezpečnostní model, řízení přístupu aplikací ke zdrojům atd. Xka jsou z tohoto pohledu jeden velký průser. Standarně můžou aplikace sahat na všechno, co teče přes Xka, a access control, který tam mají implementovaný je něco tak komplikovaného, že to raději nikdo nepoužívá.

[Hans1024]

To je problem navrhu Xek jako takovych, nikoli sdilene pameti.

[JoHnY3]

To je pravda, ale problem pro sandboxovani aplikaci tim padem porad existuje.

[Hans1024]

Jo, ale kdbus na bezpecnosti Xek nic nezmeni.

[Rezza]

Tak xka do te rovnice stejne uz dneska nepatri .

[Michal Kubeček]

Já pevně doufám, že 4K video stream se před kdbus posílat nebude, ani kdyby to nakrásně šlo.

[pc2005]

+1

Takovej kdbus NUMA, to by bylo pošušňáníčko .

[Frack]

Ne, že nebude, on už se posílá. Narazil jsem někde na prezentaci, kde borec ukazoval, jak se přes DBus posílá do aplikace stream z webkamery, možná to nebylo 4k, ale už to funguje. Aplikace se zeptala přes DBus, jestli může dostat stream z webkamery, a na základě jejích práv jí to bylo umožněno a stream poslán přes DBus. A tak to plánují i pro další aplikace.

Posílal to přes userspacový DBus a mělo to problém s výkonem, proto se čeká na kdbus. Toto je naprosto nejpodstatnější důvod, proč se kdbus dělá. Nebo si snad opravdu někdo myslel, že se to dělá kvůli tomu, aby upozornění dorazilo o 200ns dřív?

[Michal Kubeček]

No, já si třeba naivně myslel, že když se mluví o efektivitě, tak mají na mysli latence a ne propustnost pro jeden stream. Ale je dobré vědět, že mne po tom všem stále ještě dokážou něčím nepříjemně překvapit…

[Jindřich Makovička]

Pokud jde o propustnost, KDBUS umí zero-copy, takže by se měl vyrovnat sdílené paměti.

[trekker.dk]

Co jsem nakoukl do toho odkazovaného vlákna na lkml, tak - pokud si dobře pamatuju - zero-copy pro IPC už jádro umí i bez kdbus

[kralyk z abclinuxu]

GOTO #21. Něco podobného se dalo říct už o D-Busu - D-Bus AFAIK v zásadě nepřinesl žádné nové teoretické možnosti IPC (z hlediska CS, řekněme)...

Představ si ale situaci, kdy máš napsat kus SW, který bude potřebovat IPC a třeba i IPC různého druhu (krátké zprávy s důrazem na nízkou latenci versus větší objemy s důrazem na throughput apod.): Co bude jednodušší, použít všelijaká synchr. primitiva, nebo využít framework jako je D-Bus? V prvním případě tě čeká poměrně hodně práce, protože ta primitiva jsou low-level, takže budeš muset řešit spoustu různých problémů (formát protokolu, řízení přístupu atd.), které už tvůrci D-Busu dávno vyřešili... Ono se imho nelze moc divit, že spousta lidí raději použije D-Bus a následně existuje snaha D-Bus zeefektivnit podporou v jádře...

[frm]

dole ale jeden pise, ze dbus bude volitelna komponenta v jadre a ze to chce klid. At se na me nikdo nezlobi, ale vidim opet ten samej scenar jako systemd.

[kralyk z abclinuxu]

At se na me nikdo nezlobi, ale vidim opet ten samej scenar jako systemd.

Wat?

[kralyk z abclinuxu]

Aha. Tak to začíná být zajímavé.

[Ivan]

A existuje i nejaky dbus-top? dbus-em jsem nepouzival, ale pozkusenostech s Oracle AQ, MQueue, popr Java JMS mam strach, ze se nejakej system zblazni, zacne posilat bambilion zprav a celej system pujde do kopru, bez toho aby se zjistilo kdo za to muze.

PS: kdo validuje, ze zprava odpovida predepsanemu formatu? Dela to sam dbus anebo si to musi aplikace nejak osefovat sama? Kdysi jsem mel problem s gnome-keyring - ta vec si nedokazala zapamatovat heslo (a nic jineho vlastne ani umet nemela). A mam takovy podezreni, ze za to mohl Evolution, ktery s ni komunikoval nejakym starsim formatem zprav.

[Tomáš Bžatek]

Od jiste verze protokolu umi D-Bus predavat filedescriptory. I kdyz bude k dispozici casem zero-copy, porad mi to prijde jako lepsi reseni.

 

Ac je to lehce hloupe na prikladu videa, uspesne se fd passing pouziva uz ted pro ruzne streamy. Programatorsky je to velice komfortni.

[pavlix]

Možná že to i někteří zaměňují s posíláním velkých dat přes D-Bus.

[kralyk z abclinuxu]

Takže k vůli notifikaci o změně hlasitosti (no, snad vím, že jsem změnil hlasitost, to mi to nemusí psát) se musí psát modul do jádra?

Ano, právě kvůli tomu. Protože IPC notifikace nemají žádný jiný usecase než notifikaci o změně hlasitosti. *sigh*

[Ondrej Santiago Zajicek]

Ono je hlavne pitomost mit separatni mechanismus na cteni hodnoty a na notifikace o zmene hodnoty. Takze pokud neco delam se zvukem, mam nejaky handle na komunikacni kanal k audio systemu (at jiz to je ALSA-kernel ci Pulseaudio) a na nem mimo jine ctu stav hlasitosti a jsem notifikovan o jeho zmene.

[backinabag]

Nevim jak se to ted konkretne resi, ale na oboje bych pouzil dbus, na cteni hodnoty by mohlo byt rpc volani. Oproti kanalu k audio systemu by to melo 2 vyhody 1) dbus rozhrani by byla abstrakce nad audio systemem, aplikace by nezavisela na konkretnim audio systemu 2) pro programatora je jednodussi pouzit vysokourovnovejsi dbus nez si posilat zpravy pres nejaky kanal.

[omg]

a co si cekal jineho nez arogantni odpoved?

navrhove je to tak kvalitni jako cekarna na urade, takze arogantni urednicka odpoved je samorejmosti.

[Michal Kubeček]

To ale neznamená že existující mechanismy nebyly kvalitní (a samozřejmě ani to, že kdbus, tak jak byl zatím poslán, je).

[deda.jabko]

Co není na například sdílené paměti kvalitní?

To, ze je to sdilena pamet. ;-]

To, ze jde sdilenou pamet pouzit pro IPC, neznamena, ze je to dvakrat dobry napad. Uz jen z toho duvodu, ze procesy by mely mit kazdy svuj izolovany pametovy prostor; ze softwaroveinzenyrskeho pohledu je zase mnohem vhodnejsi mit jasne definovany protokol pro komunikaci mezi procesy, atd. atd.

[pavlix]

To, ze jde sdilenou pamet pouzit pro IPC, neznamena, ze je to dvakrat dobry napad.

To má asi stejnou informační hodnotu jako když napíšu, že to neznamená, že je to špatný nápad.

[pc2005]

Tak pokud je zaručeno, že do tý sdílený paměti nepoleze proces, který nemá a špatná data nekompromitují ani jednu z aplikací, tak to je v pohodě ne? Některé paralelní algoritmy se bez velkých polí neobejdou (IMHO).

[backinabag]

A nekdy nejde o rychlost, ale je proste jednodussi naprogramovat to pres sdilenou pamet nez pres posilani zprav, jednou jsem delal neco vicevlaknoveho v Jave, nejdriv jsem se snazil aby mezi sebou vlakna komunikovala pouze posilanim zprav, ale nektere veci to zbytecne komplikovalo. Pokud si vzajemne vymenuji zpravy dva rovnocenni agenti (nejedna se tedy o klient-server) tak je dost slozity o tom systemu premyslet, mit jasno do jakych stavu se muze dostat.

[omg]

tohle nabozenske dogma pada pri stretu s praxi. aplikace, ktera potrebuje vydojit system do posledni vypocetni operace nema cas cekat nez se ji data zkopiruji.

[Kvakor]

A nesmíme zapomínat, že mimo SysV IPC (sdílená paměť, semafory a spol.) a jejich POSIXových verzí tu ještě jsou klasické roury, unixové sockety a (dle mého málo využívané) POSIXové fronty zpráv (nebo jak se to překládají POSIX Message Queues).

Jinak velká výhoda sdílené paměti je to, že při dobém návrhu se minimalizuje počet přepnutí kontextu, takže komunikace skrz ní je velmi rychlá, obzvlášť v případě, kdy se nemusí řešit konurence a synchronizace (např. když se převážne jen čte a na změny se použije něco na způsob RCU)

[pavlix]

O sdílené paměti mi teď básnil jeden člověk v souvislosti s nscd.

[Petr Ježek]

To je vždy věcí názoru. Podstatné ale je, zda fukčnost dosavadních řešení meziprocesové komunikace vyhovuje i v podmínkách oddělování kernelspace a userspace a zda to opravdu třeba takový dbus zvládá. Bylo by dobré si o kdbusu nejprve vše přečíst... Tvrdím, že tu pořádný (rychlý, spolehlivý, sytémově homogenní...) IPC nástroj nejen chybí, ale dost zoufale chybí.

[Tomáš Bžatek]

Nejaky zdroj teto zpravicky? Kdo rozhodoval o zacleneni kdbus?

[Roger]

On kdbus ještě rozhodně začleněný není - Greg KH poslal patche, ale zatím se o nich vede diskuse. Viz https://lkml.org/lkml/2014/10/29/854

[Tomáš Bžatek]

Dik. Presne to jsem chtel videt v textu zpravicky, abych to nemusel hledat nebo se dlouze ptat.

[Michal Kubeček]

V té zprávičce je povážlivé množství věcných chyb:

• Tvrzení o absenci kvalitního IPC je přinejlepším značně subjektivní.
• Tvrzení, že tento problém řeší kdbus je přinejlepším značně předčasné.
• Totéž pro tvrzení o "dospěl do stadia zařazení do hlavní větve".
• "projekt Grega KH" - a proto je u všech 12 patchů "From: Daniel Mack"
• "se počítá pro verzi 3.19" - to tak možná autoři; když se podívám jen na počet vážných bezpečnostních připomínek, nepřijde mi představa merge do 3.19 moc reálná

[jadd]

GKH je umělecké jméno http://www.linuxexpres.cz/novinky/kdbus-miri-do-jadra Reakce na moc dlouhou zprávičku od LJ, tahle na abclinuxu je kratší a optimalizovaná pro čtenáře kteří nechtějí moc číst.

[Petr Ježek]

Michale, současné IPC mají dostatek problémů, aby se to někdo pokusil vyřešit (bod1). Projekt Kdbusu je právě oním nabídnutým řešením (bod2). Měl jsem použít nedokonavý vid v jiném čase (dospívá), protože z hlediska projektu se dospělo k nabídce zařazení do hlavní větve, přijetí je pochopitelně věc druhá (bod3). Nevšiml jsem si, že by Dan Mack kdbus jakkoli zaštiťoval a projekt zahajoval, přičemž GKH není "ten, co to jenom řídí" (bod4). Projděte si ty "vážné bezpečnostní připomínky a porovnejte je s obdobnými v minulých začleňovacích oknech - systémově pojaté věci bývají lépe řešitelné než taková ta domácí (a někdy superprofifiremní) hezky se tvářící tvořivost (bod5). Věcné chyby mají poněkud jiný charakter než n"ne zcela přesné vyjádření". Příště to do formy kompaktní zprávičky pošlete Vy, jistě to bude chybyprosté :)

[Michal Kubeček]

Za všemi pěti body si stojím a ani u jednoho nemám pocit, že byste ho vyvrátil.

[Petr Ježek]

Už to tu zaznělo, o zařazení se jedná s tím, že se to pro nejbližší aktualizaci nestihne. Jinak zdrojů je habaděj z komunikace vývojářů... Nicméně patch se jeví natolik schopně, že se ta diskuse o zařazení seriozné vede.

[yindi]

K cemu potrebuje jadro messaging system?

[tacoberu]

Pokud se příliš nemýlím, tak důvodem byl výkon. Stávající řešení si vynucovala opakované přepínání kontextu.

[Zopper]

Já slyšel i o bezpečnosti. Jak přesně to ale má fungovat netuším, moc do toho nevidím.

[backinabag]

K IPC.

[michi141]

K čemu potřebuje ovladače grafiky, síťovek, moduly, …? Když to bude mít kvalitu, určitě to má svůj smysl, přinejmenším pro userspace.

Z jiného soudku, init systém by spravovat nechtěli? Ať máme na chvili pokoj.

[David]

Dyť spravují. Mezi pány autory jsou samozřejmě i pánové Kay a Lennart

[biolog]

Jádro ho nepotřebuje, ale hodí se aplikacím. Doposud nebyl mechanizmus pro posílání zpráv všem aplikacím naslouchajícím na něčem (událost, objekt, rozhraní? co já vím jak tomu říkají). Dbus i kdbus zařizují i serializaci dat mezi těmi procesy.

Aplikace si obojí musely implementovat po svém. Ne že by to nešlo, ale je pakárna to dělat, navíc multicast bez podpory kernelu má velký overhead.

[luky]

Doposud nebyl mechanizmus pro posílání zpráv všem aplikacím naslouchajícím na něčem (událost, objekt, rozhraní? co já vím jak tomu říkají).

A co multicast v netlinku?

[Petr Ježek]

K témuž, jako Vy jasné zprávy.

[Ivan]

Docela mam strach, ze tohle rozpouta zpravovy silenstvi. Lidi nejdriv zjisti, ze se jim snadno vyvyji aplikace, ktere jsou zalozeny na zpravach a za par let si budou rvat vlasy, ze nejsou schopni ukocirovat format zprav, ktery si mezi sebou aplikace predavaji.

[pc2005]

+1 ! U něčeho jako dbus se bojím toho, že se bude každou chvíli měnit API s userspacem. Příkladem budiž ovládání poslední řady BlueZ "driverů".

BTW navíc u dbusu mi způsob adresování cíle, připadá moc redundantní (z pokusů ovládat ten BlueZ ze shellu).

[mirec]

Fuj BlueZ, kedysi som sa pripájal cez bluetooth na internet cez pand, potom niekto pand z balíka vyhodil a tak som sa musel pripájať nejakým párriadkovým nabastleným skriptom (asi 2x v živote som ho využil) a nedávno som zase potreboval bluetooth a jeje zase to nejaký expert zmenil a bez pripojenia na internet si svoj skript ani neviem upraviť. Grafické klikátka tiež nefungovali, posielali totiž po dbuse ešte rovnakú starú somarinu ako ja ...

[petr_p]

To už je skutečnost. Když jsme naučily gnomáky, co je to ABI sdílené knihovny, tak volání funkcí vyměnili za volání služeb dbusem, kde prasí úplně stejně. Oni nepotřebují verzovat protokoly. Oni rovnou přepíší celé desktopové prostředí. Podle mě je to jeden z důvodů, proč rok Linuxu na desktopu stále ne a ne přijít.

[Rezza]

(Ne)verzovani DBUSu je jeho nejvetsi pruser. A jeste dodnes si pamatuji prechod NM na 0.9 tusim. Na posledni chvili. Kolik jsme toho rozbili. Rychly hack se udelal tak, ze se nechal nechal stary verzovany interface v dbusu s necim ala _08. No, nejak nikoho nenapadlo, kolik veci to pouziva a rozbil se Sugar. A vlastne i KDE byly rozbite. Duvod? Sice zpravy sly pres DBUS a stary interface, ale hodnoty konstant ala pripojeno se braly z hlavickoveho souboru NM. Ten uz ale samozrejme byl v nove verzi :))).

[Petr Ježek]

Bohužel, tyhle prasečiny se nevyhýbají ani jinak celkem schopným lidem a týmům. Zjevně se zapomíná na obsah slova odpovědnost (bez ohledu ná právní aspekty)...

[Tomáš Bžatek]

Jestli myslis API sluzeb dostupnych na D-Bus sbernici, tak je to opodstatnena obava. Jestli myslis protokol samotneho D-Busu, tak ten je pevne dany a prichod kdbusu temer nic nezmeni.

[Rezza]

Mysleno je na 100% to API sluzeb dostupnych na DBusu.

[Tomáš Bžatek]

Pred obedem jsem nestacil reagovat na tvuj post, takze ano, s tim souhlasim. Lidi si stale neuvedomuji, ze vyexportovane API pres D-Bus je stale verejne API a mely by se na nej vztahovat stejne pravidla, jako pro jakekoliv jine formy a jazyky. Pokud by se bezne delal soname bump, melo by se zmenit napr. jmeno sluzby. Diky pekne introspekci, ktera se na D-Busu pomalu stava standardem, lze z interface generovat bindingy a proto stabilita je jeste vice dulezita, nez driv.

Mel by se idealne definovat i styl API, at je jednotny skrze projekty. Myslim tim styl parametru, pouzivani kontejneru, dictionaries atd. Zatim je to kazdy projekt jina ves.

[Petr Ježek]

Tak to podepisuji.

[marbu]

+1

[Petr Ježek]

No, je to o odpovědnosti. Týká se to nejen formy zpráv, ale také procesních podmínek. Linuxové jádro představuje výtečný precedens jak se vyhnout všemožným "stack overflow". Já se nebojím, protože o GKH a jeho schopnostech nemám po zkušenostech pochybnosti.

[little.owl]

kdbus bude volitelna komponenta kernelu, tak nevim s cim je tady problem. Srovnavat message framework jako je kdbus ci binder - bude tam brzo take - se sdilenou pameti je pitomost. Aplikace postavene na asynchronnim posilani zprav v zavislosti na toku informace/dat maji sve vyhody a dobre integrovana linuxova implementace umozni portovat aplikace z jinych OS, kde je to zakladni stavebni prvek IPC.

[Petr Ježek]

Konečně někdo, kdo ví, oč jde... O té volitelnosti v kernelu je sice předčasné hovořit, ale má to logiku vzhledem k potenciální nízké efektivitě na nevytížených domácích a mnoha kancelářských strojích. Právě ta asynchronnost v meziprocesních tocích je v linuxu dost popelkou...

[trekker.dk]

Konečně někdo, kdo ví, oč jde...

Překlad: konečně někdo, kdo je propagátor stejné víry, jako vy.

[omg]

ty texty zpravicek a nadpisy to prochazi redakcni bulvarizaci nebo je tak poskozeny akorat autor sam? pri pohledu na historii zpravicek mi to neprijde az tak uplne normalni zpravodajstvi. spis to vypada na fanaticky nabozensky vestnik.

[Petr Ježek]

Pán je zjevně spokojen nejen sám se sebou, že? Mohu se optat, co je bulvárního na informaci o projektu, který provází na rozdíl od jiných velmi hluboká věcná argumentace autorů? Předem děkuji za informačně neprázdnou odpověď. Mimochodem, psát to co vy dokáže každý, psát zprávičky, ne-li přímo články či kód je zjevně náročnější...

[marbu]

To bude vytka k textu zpravicky, ne k kdbusu jako takovemu.

[Jardík]

Teď ještě chybí, aby to nová verze systemd vyžadovala jako povinou součást jádra.

[Michal Kubeček]

A on snad někdo po předchozích zkušenostech pochybuje o tom, že jakmile se kdbus dostane do mainline, tohle bude záhy následovat?

[Rezza]

Tak samozrejme, ze to bude nasledovat. Jinak by kolem toho nedelali takove harakiri. A hlavne, kdo pak nebude mit systemd s kdbusem v kernelu, nebude mit LinuxApps a jestli se rozsiri, tak...

[tacoberu]

Plán je, že Systemd by mělo záviset na kdbus, ne naopak. kdbus rádi využijí i jiné aplikace, ne jen systemd.

[Michal Kubeček]

Kacířská myšlenka: co kdyby třeba systemd závisel jen na D-Busu s tím, že mu bde jedno, jestli je implementován v jádře, v userspace nebo půl na půl? Jenže to by holt asi nebyla The Systemd Way.

[pavlix]

Nechápu, proč nad tím vůbec uvažuješ, takhle to nefunguje. Plno zásadních nedostatků systemd se neřeší s odkazem na to, že se budou řešit nad kdbusem, takže se jimi v kontextu klasického dbusu nebude nikdo zabývat.

[pavlix]

A budem rádi, když se je vůbec podaří vyřešit nad tím kdbusem ;).

[tacoberu]

Mohl by jsi zmínit, o jaké věci jde? Žiju v představě, že kdbus je plus/mínus jaderná reimplementace dbus-u. A zásadní rozdílem bude rychlost.

[pavlix]

Třeba to, že je systemd neschopný korektně spravovat na dbusu založené služby a ty se tak často znovu aktivují potom, co je v systemd zastavíš. Zásadní rozdíl přenesení části dbusu je sice v rychlosti, ale je důležité si uvědomit, že ta druhá část se přenese do systemd a ten ji tím pádem uvidí do střev, takže nebude problém řešit tyhle integrační problémy. Lennart s Kayem chtějí kdbus proto, že jim to ulehčí práci a taky proto, že tak jednoduše stáhnou dbus pod kapotu systemd. Rozhodně ne proto, aby se ještě někdy v životě zabývali integrací s externím démonem.

[tacoberu]

Takhle by to samozřejmě bylo správně. Naprosto souhlasím.

[pavlix]

Já nesouhlasím, podle mě by bylo správně dbus zahodit a pro jednou navrhnout něco pořádně.

[tacoberu]

Br, br, br.

Pomyňme skutečnost, že nesouhlasíš s B, zatímco já souhlasím s A, popiš prosím, co ti na dbus-u vadí.

[pavlix]

Neházej tady po mně písmeny. Někdy si najdu čas na plnohodonotný zápisek, v podstatě jde hlavně o pohodlné používání především z dynamicky typovaných jazyků, kde se nepříčetnost dbusu projevuje naplno. Stačí si porovnat typický kód v Pythonu a v C, jsou tam velké rozdíly. Pak porovat dbusový kód v Pythonu a v C a člověk zjistí, že je obojí stejně hrozné a tedy že je dbus v podstatě jenom další těžkopádný RPC, jakých tu bylo tisíc předtím.