Vlákno názorů k článku Jak události mění Linux od Ondrej 'SanTiago' Zajicek - Me neni jasne, k cemu je DBUS. Pokud...
-
Článek je starý, nové názory již nelze přidávat.
-
Yenya (neregistrovaný)Asi jste to moc necetl. Udev neni IPC mechanismus (ostatne i v tomto clanku se to pise). Navic: d-bus samozrejme vyuziva UNIXove sockety jako transportni prostredek.
K cemu d-bus je? Aby kdyz si zmenite v preferencich font, aby se o tom dovedely
vsechny aplikace. Aby se automaticky ztlumil prehravac hudby, kdyz vam nekdo zavola do VoIP klienta (nebo kdyz zacnete volat Vy). Aby program pro vypalovani CDcek nemusel vedet jaky typ mechaniky mate, jak se s ni pracuje, pod jakym jmenem ji v /dev najde, a zejmena aby totez nemusel resit kazdy dalsi vypalovaci program, ktery kdo kdy napise (tohle konkretne teda resi HAL, ale jako transportni mechanismus je D-Bus). Aby se desktopove prostredi dovedelo o vzniku nebo zaniku noveho hardwaru, atd. Ostatne spustte si dbus-monitor --system (nebo --session) a sledujte, co vsechno pres d-bus chodi.
-Yenya -
Ondrej \'SanTiago\' Zajicek (neregistrovaný)> Asi jste to moc necetl. Udev neni IPC mechanismus
Omlouvam se za zmateni, zamenil jsem slova UDEV/DBUS a veta mela znit 'ale stale mi neni jasna zadna konkretni vyhoda DBUSu oproti vyuziti klasickych IPC mechanismu.', jak naznacuje titulek. UDEV znam a pouzivam.
Ano, je mi jasne, co vsechno muze pred DBUS chodit, ale netusim, proc k tomu pouzivat samostatneho demona, proc nepouzit ke komunikaci jednotlivych programu standardni transportni mechanismy.
A vyuziti XML pro formatovani predavanych zprav (namisto treba jednoduchych plaintextovych, ktere by slo parsovat pomoci scanf) - to uz je maximalni overkill, ktery dost limituje pouzitelnost DBUSu - jednoduche programy asi nebudou chtit vyuzivat DBUS, aby se nemusely linkovat s obrovskymi XML parsery.
A kdyby se me automaticky ztlumil prehravac hudby, kdyz me nekdo zavola do VoIP klienta, aniz bych to do nej explicitne nastavil, to by me teda radne nastval. -
anonymní> A vyuziti XML pro formatovani predavanych zprav (namisto treba jednoduchych
> plaintextovych, ktere by slo parsovat pomoci scanf) - to uz je maximalni
> overkill, ktery dost limituje pouzitelnost DBUSu - jednoduche programy asi
> nebudou chtit vyuzivat DBUS, aby se nemusely linkovat s obrovskymi XML
> parsery.
Tak to je jejich vec, ze :-) Kdyz si kazdy bude psat svoje parsovani sam, tak
tam bude milion ruznych chyb, v kazdem programu jina. Ostatne, divam se ze ani dbus-send ani dbus-monitor se s zadnym XML parserem nelinkuje.
No, jak by ty standardni mechanismy mely vypadat, aniz by skoncily podobne jako d-bus? V ramci desktopove session musite mit neco co existuje po celou dobu te session, a pres co si muzete zasilat zpravy. Totez pro systemovou session - nekdo musi vytvorit poslouchaci UNIXovy socket, poslouchat na nem, a preposilat zpravy vsem ostatnim. A ten nekdo se jmenuje dbus-daemon. Ostatne i implementace CORBy takhle funguji. Nebo jaky jiny transportni mechanismus byste si predstavoval? SysV SHM segment nebo SysV frontu zprav? Rouru?
-Yenya -
Yenya (neregistrovaný)Multicasty na loopbacku? No fuj. Jak byste resil pristupova prava, vic zaroven pracujicich uzivatelu (vicehlavy desktop nebo prepinani sessions bez odhlaseni, atd.)?
Ad multicast na UNIXovych socketech: asi proc ne, pokud by to nekdo implementoval (a to nejen na Linuxu, myslim ze lide z freedesktop.org se snazi resit obecne UNIXove systemy, nejen Linux, cili pridejte jeste cas na to, az se implementace dostatecne rozsiri vsude), ale stejne byste musel resit veci jako kdo vytvori ten socket a jak jeho jmeno preda ostatnim (nezapomente na vice aktivnich sessions jednoho uzivatele, napriklad), pristupova prava u systemove sbernice, atd.
Samostatny demon mi prijde rozumny - na mem systemu ma po trech dnech uptime i existence session 1.1 MB RSS ten systemovy, neco pod 700 KB RSS session d-bus. To je oboji mene, nez ma napriklad bash, kterych mi bezi nekolik desitek. Rekl bych ze resite neexistujici problem.
-Yenya -
anonymníVezmeme si treba prvni Yenyuv priklad: zmenite si v preferencich font.
Takze komunikuji 2 aplikace:
A: nastavuje font, ktery uzivatel uprednostnuje.
B: pouzit defaultni font a zmenit ho, kdykoli se zmeni.
Da se naprogramovat snadno - proste B bude cekat na socketu na povel: 'Zmenil se font, tak se podle toho zarid' . Aplikace A pak ten povel nekdy posle. Snadny ukol. Bezne IPC
Problem nastane v okamziku, kdy v systemu jsou aplikace A1, A2, ... , An a B1, B2, ... Bm. Kazdou aplikaci psal nekdo jiny, takze dohoda na jednotnem IPC muze byt docela tezka.
Reseni DBUSu (pod -> si predstavuji libovolne IPC) :
Bi -> DBUS: kdyby ti nekdo rekl, ze zmenil defaultni font, dej mi vedet.
Ai -> DBUS: menim defaultni font
DBUS -> Bi: nekdo zmenil defaultni font
idea DBUSu moc pekna. Problemy mam v okamziku, kdyz po pripojeni disku se 2 oddily se objevi /media/disk a /media/disk-1 . Samozrejme, ze pojmenovani vubec nesouvisi s poradim oddilu na disku - proste je nahodne. -
Yenya (neregistrovaný)No, a jak teda by melo vypadat "to spravne" :-) reseni?
Ja jsem za nejjednodussi povazoval nastavit na filesystemu label (jak extN,
tak *FAT i ISO9660 to podporuji), takze pokud to opravdu chci rozlisit,
tak se muj Palm montuje vzdy jako /media/YenyaPalm, at uz je v systemu predtim
nebo i potom cokoli.
-Yenya -
bzz (neregistrovaný)Ja vam to vysvetlim jednoduse, ale naprosto pochopitelne jednou analogii. Vas dotaz odpovida dotazu, a k cemu je vlastne ten smtp/pop3 server, proc by si postovni klienti nemohli posilat maily primo?
DBUS slouzi ke komunikaci mazi aplikacemi, kde nektere aplikace nabizi nejake sluzby a jine je konzumuji. Pricemz jednu a tu samou sluzbu mohou nabizet ruzne aplikace, konzument nevi, k jake aplikaci se pripojit a ani ho to nezajima, on si pozada o sluzbu a tu dostane. A muze si pozadat dokonce i predem, kdyz sluzba jeste neexistuje, az se objevi, dojde k jeji poskytnuti, konzument se nemusi porad dotazovat, zda uz je sluzba k dispozici. Komunikace muze byt synchronni i asynchronni. Dale je zde standardizovany a dobre optimalizovany protokol, takze programatori nemusi neustale implementovat to same. Jestli nechapete vyhodu, tak by ch se zeptal, a k cemu je to tcp/ip, kdyz tu jsou k dispozici raw sockety, proc mit nekolik vrstev na sitovem spojeni? -
Jirka P (neregistrovaný)
Co je multicast na loopbacku? (multicast - adresa Ex.xx.xx.xx, loopback - adresa 7F.xx.xx.xx hexa) Pokud myslíte broadcast, tak by to jednak přinášelo zajímavé situace typu najdi volnou adresu na který se dá poslouchat, druhak by ten počítač nemusel rozdýchat když by vložení CD probudilo třeba všechny KDE aplikace. Pokud byste použil unix domain sockety, tak by to potenciálně znamenalo n^2 spojení, kromě toho byste nějak musel poznat jaký socket patří jaké aplikaci příp. jaké její instanci.
Tohle DBUS řeší. Vytváří jakousi síť s hvězdicovou topologií, směruje v ní data a dokáže zjistit, jaké jsou v té síti "služby".
MMCH, DBUS používá unix domain sockets, jak se můžete přesvědčit:
lsof | grep dbus. Takže ta otázka nedává moc smysl, DBUS je prostě na jiné úrovni. Asi jako "K čemu je CORBA, vždyť na komunikaci můžu použít UDP"
