Portál AbcLinuxu, 24. dubna 2024 08:45

Jaderné noviny – 29. 10. 2014: Seznam přání pro jádro pro pracovní plochu

28. 11. 2014 | Tadeáš Pelech
Články - Jaderné noviny – 29. 10. 2014: Seznam přání pro jádro pro pracovní plochu  

Aktuální verze vývojového jádra: 3.18-rc2. Seznam přání pro jádro pro pracovní plochu

Obsah

Aktuální verze vývojového jádra: 3.18-rc2

link

Aktuální vývojové jádro je 3.18-rc1, vydané 26. října (odkaz). Linus k tomu řekl:

Doufal jsem, že vydání rc1 způsobí, že se probere pár opozdilců a rychle všechno pošlou a zbytek rc pak bude probíhat normálně. Ale ne, celý týden se mi hrnuly žádosti o začlenění do hlavního stromu a rc2 je větší, než bych chtěl. Snad nejvýznamnější z těchto žádostí byl union systém souborů overlayfs, který byl nakonec začleněn po letech snažení.

Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace. Aktualizace verzí 3.17.2, 3.16.7, 3.14.23, a 3.10.59 byly v době vzniku tohoto textu v procesu kontroly, lze je očekávat nejdříve 30. října.

Seznam přání pro jádro pro pracovní plochu

link

Vývojář GNOME Bastien Nocera nedávno s e-mailovou diskusní skupinou jádra sdílelseznam přání“, ve kterém navrhl celou řadu funkcí, které GNOME a další projekty prostředí pracovní plochy rády viděly v jádře přidané nebo rozšířené. V následné diskusi byly některé položky ze seznamu vyškrtnuty, ale mnoho ze zbývajících vyvolalo velkou diskusi, která by v průběhu času mohla vést k přidání nových funkcí do hlavního jádra.

Nocera zahájil svůj seznam tím, že GNOME i dříve vedl plodné diskuse s vývojáři jádra a že aktuální seznam se skládá z „položek, o kterých vývojáři jádra ani netuší, že bychom je chtěli využívat; nebo nevědí, že by se nám v případě začlenění hodily.“ Většina z těchto položek spadá do jedné ze dvou hlavních kategorií: řízení spotřeby a vlastnosti systému souborů. Najde se ale samozřejmě i dost dalších.

Nižší spotřeba

Pod řízením spotřeby Nocera uvedl nativní podporu hybridního pozastavení (na určitém hardwaru označováno jako Intel Rapid Start), podpora připojení v pohotovostním režimu, „implementace režimu spánku, která nepoužívá odkládací prostor,“ a několik menších položek (například zřízení jednotné sémantiky pro nastavení podsvícení obrazovky a lepší dokumentace pro správu napájení USB).

Hybridní pozastavení je funkce na úrovni firmwaru určená k minimalizaci času potřebného k obnovení systému z režimu spánku. Funguje tak, že nejdříve pozastaví systém do paměti RAM, ale pak po určitém čase zapíše obsah paměti na disk (přímo z firmwaru) a přejde do režimu hibernace. Před vypršením tohoto časového limitu probíhá probuzení velmi rychle, systém si navíc zachová svůj stav bez ohledu na to, jak dlouho je pozastaven. Matthew Garrett napsal opravu zavádějící podporu funkce v polovině roku 2013, ze které Nocera následně vytvořil požadavek na začlenění do hlavního stromu. Který ovšem nakonec uvízl na mrtvém bodě. Ozývaly se kritické připomínky, že funkce hybridního pozastavení Intelu bude nakonec nahrazena režimem připojení v pohotovostním režimu, novějším režimem napájení ve stavu nečinnosti, který umožňuje některým procesům na pozadí pokračovat v práci. Garrett také pracoval na přístupu k připojení v pohotovostním režimu.

John Stultz požadoval upřesnění jedné z dalších žádostí týkajících se řízení spotřeby: exportu příčiny události probuzení. Nocera to rozvedl – vysvětlil, že cílem bylo zjistit, zda zařízení probudil uživatel nebo hardwarová událost (např. alarm hodin v reálném čase), aby bylo možno adekvátně reagovat na různé situace. Citoval příklad použití v kódu uživatelského prostoru, který by zjišťoval a určoval, zda je vhodná doba ke spuštění dříve naplánovaného zálohování: pokud by uživatel probudil počítač otevřením víka notebooku, pravděpodobně by nebyla vhodná chvíle k zahájení zdlouhavého procesu zálohování. Pokud by šlo o automatické probuzení, zálohování by mohlo pokračovat.

Stultz, však namítl, že hlášení příčiny probuzení by nedokázal plně uspokojit všechny možné případy použití – zčásti proto, že druhů událostí probuzení mezi probuzením jádra a okamžikem, kdy se může spustit kód uživatelského prostoru, může být příliš mnoho (navíc, protože jsou asynchronní, by mohly dorazit v nepoužitelném pořadí). Ale ještě důležitější je (jak se zmínil Zygo Blaxnell), že to, která událost je nejnovější, je mnohem méně podstatné než to, zda (například) uživatel počítač právě používá; Což je možné zjistit jinými způsoby, například činností klávesnice. Alan Cox naopak podotkl, že v dlouhodobém horizontu většina předpokladů, které provázejí současné představy o stavech pozastavení, obnovení a hibernace, mohou zastarat:

Otázky systému souborů

Druhá velká kategorie požadavků na funkce se týká funkcí systémů souborů a vrstvy VFS. Za prvé, Nocera oznámil, že inotify nesplňuje potřeby nástrojů plochy v různých otázkách. Výkon na velkých adresářových strukturách spotřebovává příliš mnoho zdrojů, oznámení o vytvoření souboru vyžaduje sledování celého adresáře a sledování událostí přejmenování a odstranění souborů je u velkých adresářů nákladné na zdroje. Tato omezení ovlivňují výkon indexování souborového systému, nástrojů pro zálohování a programů, které spravují „knihovny“ souborů (např. správci hudby a videa).

Sergej Davidoff z elementary OS dané téma rozvedl. Podle něj se vývojáři aplikací pracovní plochy snaží přejít ke koncepci knihoven souborů (jaká se používá ve správě hudby a videa) i v jiných typech aplikací. Podle něj je prezentace hierarchie souborového systému uživateli mnohem méně užitečná než inteligentní sledování příslušných souborů, které uživateli umožňuje vyhledávat je a pracovat s nimi na základě jejich metadat. fanotify, jak oba poznamenali, nenabízí správnou úroveň podrobností, například hlášení událostí přejmenovaní a přesunu.

Nocera také žádal o způsob šíření změn časového razítka v hierarchii adresářů směrem vzhůru. To znamená, pokud se změní soubor umístěný v adresáři /foo/bar/, bude existovat způsob, jak tuto změnu rozpoznat nejen u souboru samotného, ale také u adresářů /foo/bar a /foo. Dodal ale, že jednoduchá aktualizace času změny adresáře s daným souborem by bylo určitě špatným řešením, protože kvůli tomu by nejspíš přestalo fungovat mnoho programů.

Zkrátka, řekl, že programy v uživatelském prostoru by měly těžit z lepšího systému oznamování změn souborů – ideálně takového, který by události konsolidoval a sledoval adresářovou strukturu bez jejího pravidelného procházení. Uvedl, že kombinace zlepšení fanotify a přidání přichycení uživatelského prostoru by mohlo fungovat, stejně jako přidání funkcí protokolu změn, které jsou nyní k dispozici v Btrfs a XFS, do jiných systémů souborů.

Pavel Machek se zeptal, zda by nebylo možným řešením přidání (hypotetické) rekurzivní verze časového razítka mtime. Davidoff odpověděl skepticky, že by to fungovalo pro sledování online změn, ale že by mělo stačit sledování protokolu změn Btrfs „víceméně v reálném čase“. Sledování protokolu změn Btrfs za běhu by mohlo alespoň zajistit, aby vše provedla aspoň vyrovnávací paměť pevné velikosti, jako protiklad neohraničené paměti, kterou by pro stejnou úlohu vyžadovalo fanotify.

Různé

Nocerova poslední skupina položek seznamu přání je celkem všehochuť. Najdeme zde lepší uživatelské API pro průmyslové vstupně/výstupní (IIO) subsystémy použité pro různé snímače, pomocníka uživatelského pro ukončování procesů mimo paměť (OOM), systémové volání dotazující se, zda byly všechny procesy mimo řadu procesů ukončeny a varianta epoll_wait(), která přijímá absolutní čas místo časového limitu.

Podobně jako v případě ostatních kategorií, některé z těchto položek vyvolaly rychlé reakce. Patrik Lundquist navrhl, aby požadované funkčnosti epoll_wait() bylo možno dosáhnout pomocí timerfd(). Na to Nocera citoval původní zdroj požadavku, Ryana Lortieho, který řekl, že samostatné volání pro nastavení timerfd() ve všech instancích, kdy jádra přechází do režimu spánku, je náročné, a že "epoll obecně trpí tím, že je příliš upovídaný o systémových voláních, která musíte provést.“ Andy Lutomirski dodal, že realizoval dotazování procfs před několika lety a že je ochoten v této práci pokračovat, pokud to bude užitečné. Dotazování procfs by umožnilo uživateli otevřít sadu adresářů proc odpovídající zvolené sadě procesů a potom se dotázat adresářů, aby zjistil, zda nedošlo k nějakému ukončení.

Pokud jde o ostatní návrhy, zatím jsme se příliš reakci nedočkali. Z řady těchto položek ze seznamu jistě vykrystalizuje zavedení přívětivějších API uživatelského prostoru. Nocera k problémům IIO a hlášení událostí probuzení podotkl, že současné rozhraní prověřující neformátované soubory sysfs zdaleka nedostačuje.

Celkově však je komunita kolem jádra zjevně vnímavá na tyto potřeby projektů prostředí pracovní plochy. Na wiki stránce přání Nocera přirovnal cvičení „přání pro instalatéry“ odeslané vývojáři jádra Kayem Sieversem, Lennartem Poetteringem a Haraldem Hoyerem. Přístup přání pro instalatéry byl samozřejmě natolik úspěšný, že příslušní instalatéři to od té doby opakují. To vytváří dobré podmínky pro Nocerova přání pro pracovní plochu.

Je docela běžné slýchat o nové práci na jádře, která vychází jak z potřeb uživatelů špičkových datových center, tak tvůrci vestavěných systémů – možná prostě proto, že firmy v těchto oblastech podnikání mají sklon najímat vývojáře jádra. Proto je vždy dobré vidět, že komunita jádra stejnou měrou reaguje na potřeby vývojářů uživatelského prostoru pracujících v jiných oblastech, pokud se tito vývojáři rozhodnou své obavy vyslovit nahlas.

Odkazy a zdroje

Kernel coverage at LWN.net: October 29, 2014

Další články z této rubriky

Jaderné noviny – přehled za březen 2024
Jaderné noviny – přehled za únor 2024
Jaderné noviny – přehled za leden 2024
Jaderné noviny – přehled za prosinec 2023
Jaderné noviny – přehled za listopad 2023

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.