Jaderné noviny - 15. 4. 2015: Překážky pro kdbus

19. 7. 2015 | Redakce

Články - Jaderné noviny - 15. 4. 2015: Překážky pro kdbus  

Stav vydání jádra. Citáty týdne. Překážky pro kdbus.

Stav vydání jádra

Kernel 4.0 byl vydán 12. dubna. K oznámení Linus poznamenal:

Co se týče funkcí, nenabízí 4.0 nic speciálního. Hodně se toho udělalo díky patchovací infrastruktuře kernelu, ale to nebyl hlavní důvod pro změnu číslování verze. Mnohem větší změny byly v jiných verzích. Takže se jedná o vydání s velmi pokročilým kódem.

Kromě (nedokončeného) mechanismu pro live-patching, obsahuje toto vydání následující: Došlo k odstranění systémového volání remap_file_pages(), vylepšení podpory perzistentní paměti, připojení lazytime, a také byl přidán KASan (sanitizér adres jádra).

Začleňovací okno 4.1 je otevřeno, pro shrnutí vtažených novinek se podívejte na článek níže.

Stabilní aktualizace: 3.19.4, 3.14.38 a 3.10.74 byly vydány 13. dubna.

Citáty týdne

Pokaždé když nějaký prodejce dodá 32bitový time_t OS pro 32bitový počítač, vytváří potenciální možnost, že se někdo nachomýtne k jedné z mnoha nepříjemností spojených s rokem 2038 (je jich několik, podívejte se na Wikipedii a zaměřte se také na NTP). Dnes je potenciál malý, ale s tikajícím časem time_t se zvyšuje...

-Theo de Raadt

JSI PING. PROČ SE VŮBEC STARÁŠ O TO, KTERÁ VERZE KERNELU JE AKTUÁLNÍ.

-Dave Jones

Policie zastaví autobus a ptá se, kdo je uvnitř. Protože programátoři většinou neodpovídají, když na ně někdo promluví, zvlášť když se jedná o policii, předá jim revizor seznam všech občanských průkazů. Tomu se říká introspekce bez podpory pasažérů autobusu. Revizor si udělá kopii VŠECH OBČANSKÝCH PRŮKAZŮ lidí, kteří nastupují do autobusu, aby pomohl policii (tj. debuggerům) zjistit, kdo je uvnitř.

-Daniel Mack (parafrázoval Greg Kroah-Hartman) vysvětluje kdbus

Díky tomuhle vláknu jsem si uvědomil, že i když se mi daří vyhradit si více času na údržbu IB (InfiniBand), nemám již potřebu trávit svůj čas udržováním IB subsystému. Vzhledem k tomu, že moje současné nasazení škodí komunitě, rozhodl jsem se jako maintainer odstoupit .

-IB maintainer Roland Dreier jde dál. (dík Yannu Droneaudovi)

Mailing list pro záležitosti okolo roku 2038

Byl nastaven nový mailing list pro všechny developery, kteří pracují na odvrácení katastrofy roku 2038. "Připojte se, pokud se chcete přidat k diskuzi na toto téma, nebo chcete posílat patche. Cílem je ponechat tento mailing list otevřený nováčkům, takže budeme, kromě těch dobrých, dostávat hodně chybných patchů. Patche je možné zasílat pro úvodní kontrolu před tím, než se dostanou ke skutečným maintainerům. Pokud víte co děláte, můžete spolu s patchem přidat seznam na Cc."

Celý článek

Překážky pro kdbus

Patch set kdbus (přidává do kernelu D-Bus messaging), si za poslední rok prošel několika koly kontrol. Počet komentářů klesal s každým novým kolem a vypadalo to, že by se kód mohl celkem snadno dostat do vydání 4.1. Bližší pohled ovšem odhaluje jakousi zbytkovou nespokojenost z posledního kola, která měla velkou šanci vzplanout v aktivní opozici v okamžiku, kdy byl proveden pokus o vtažení. Přesně to se stalo 13. dubna, když Greg Kroah-Hartman odeslal Linusovi žádost o vtažení kdbus.

Diskuze je v době psaní tohoto článku v plném proudu, takže snažit se o nějaký souhrn by zde nemělo smysl. Ve zkratce jde o to, že námitky mají několik podob. Jde o nespokojenost s výkonem kdbus - což je trochu překvapivé, protože výkonnost je jedním z motivačních faktorů celého vývoje. Je zde celá řada obav, které se týkají bezpečnosti, hlavně kolem sběrnice a toho, jakým způsobem sbírá a odesílá metadata připojených procesů. Kdbus ještě stále nefunguje dobře s kontejnery. Někteří vývojáři shledávají tuto problematiku jako skličující.

Jádro sporu lze nalézt v Gregově zprávě. V ní souhlasil, že design (kdbus) je "nešťastný" (i když později své prohlášení stáhl), a řekl, že kdbus by se měl přijmout ve své aktuální formě - i když není ideální.

D-Bus je dostupný již déle než deset let. Nenavrhujeme nic nového, naopak se tuto specifikaci snažíme implementovat tak, jak byla navržena. Musíme být kompatibilní se stávajícími uživateli DBus, nemáme možnost měnit základní věci a nemůžeme očekávat, že se okolní svět přizpůsobí jen proto, že design (dbus) není tak čistý jak by měl/mohl být.

Je to jako snažit se zprovoznit hrozný hardware, někdy je třeba napsat podivný kód. Nebo implementovat síťový protokol, který nebyl správně navržen, ale používá ho několik stovek milionů systémů, takže nám nezbývá, než být kompatibilní. To je vše, co zde děláme.

Mějme na paměti, že se to jmenuje kDBUS, a nikoli kGENERICPC, bez ohledu na to jak rádi bychom, aby se to z hlediska kernelu jmenovalo.

Bylo by fér zde poznamenat, že ti, kdo jsou proti zavedení kdbus v jeho současné podobě, by byli raději, kdyby se skutečně jmenoval kGENERICPC. Mají pocit, že by měl podporovat vše co je nutné, k efektivní implementaci D-BUS, ale že specifické části D-BUS by měly jít do uživatelského prostoru. Konec konců do kernelu se dá vtáhnout jen určitý počet meziprocesních komunikačních mechanismů. Ten, který vtažen bude, by podle developerů neměl obsahovat žádné známé chyby, a měl by umět víc, než jen reimplementovat protokol D-Bus.

Prozatím je těžké odhadnout jakým směrem se diskuze bude ubírat, nebo jak se nakonec Linus rozhodne. Je celkem velká šance, že se proti vtažení kdbus do aktuálního vývojového cyklu vyjádří velký počet významných vývojářů. K začlenění kódu do kernelu sice není vždy zapotřebí konsensu, ale prosadit vtažené kódu při silné opozici je stále velmi těžké. Vypadá to, že dohadování o kdbus, bude ještě nějakou dobu pokračovat.

Diskuse k tomuto článku

[Petr Tomášek]

Je celkem velká šance, že se proti vtažení kdbus do aktuálního vývojového cyklu vyjádří velký počet významných vývojářů.

To by bylo jedině dobře.

[Michal Kubeček]

Ne "by bylo", to už se stalo. Je potřeba mít na paměti, že výraz "aktuálního" se vztahuje v době, kdy byl psán původní článek, konkrétně k pokusu dostat kdbus do jádra 4.1.