Portál AbcLinuxu, 6. května 2025 20:04
Dlouhodbou absenci kvalitního IPC pro GNU/LinuxTohle je přinejlepším věc názoru...
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á.
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.
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.
a zadruhé toho s opakovaným čtením pamětiZprávička: (...) Dlouhodbou absenci kvalitního IPC pro GNU/Linux (...)
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.
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...
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?
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.
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.
Mimochodem, jaky existujici IPC prostredek bys pouzil pro publish-subscribe?netlink - nl_socket_add_memberships()
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.)
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.
, tak sry za spam :P
31.10.2014 15:54
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
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čí.
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.
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.
31.10.2014 15:55
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
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.
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.)
Takovej kdbus NUMA, to by bylo pošušňáníčko .
At se na me nikdo nezlobi, ale vidim opet ten samej scenar jako systemd.Wat?
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.
Ano, právě kvůli tomu. Protože IPC notifikace nemají žádný jiný usecase než notifikaci o změně hlasitosti. *sigh*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?
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.
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.
Nejaky zdroj teto zpravicky? Kdo rozhodoval o zacleneni kdbus?
Dik. Presne to jsem chtel videt v textu zpravicky, abych to nemusel hledat nebo se dlouze ptat.
V té zprávičce je povážlivé množství věcných chyb:
30.10.2014 16:36
30.10.2014 16:40
31.10.2014 17:17
4.11.2014 12:05
31.10.2014 12:27
From: Daniel Mack"
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.
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 ...
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.
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.
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.
31.10.2014 12:25
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Konečně někdo, kdo ví, oč jde...Překlad: konečně někdo, kdo je propagátor stejné víry, jako vy.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
31.10.2014 07:24