Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Současné vývojové jádro 2.6 je 2.6.27-rc6 vydané 9. září.
Do hlavní řady bylo od 2.6.27-rc6 začleněno mnoho oprav, ale protože je mnoho hackerů, včetně Linuse, na Kernel Summitu, -rc7 se může poněkud zpozdit.
Žádná vydání stabilních jader tento týden nevyšla. 2.6.25.5 a 2.6.25.17 byla obě vydána 7. září.
Vzhledem k tomu, že návrháři souborových systémů milují hnidopišské mrňavé detaily, a já osobně ztrácím trpělivost, tak pokud budou fiemap patche dál zdržovány, pak mám v plánu začít hrát podle pravidel XFS, jednoduše vzít ext4-fiemap patch a implementovat ioctl specifické pro ext4. Až, a pokud vůbec, se linux-fsdevel komunitě podaří shodnout na fiemap patchích, ať už se to stane v 2.6.28, nebo 2.6.87, bude dostatečně jednoduché předrátovat podporu v ext4 do obecného fiemap ioctl.
-- Ted Ts'o začíná být otrávený.
Linux Kernel Summit 2008 se konal 15. a 16. září v Portlandu ve státě Oregon v USA těsně před Linux Plumbers Conference (Konference linuxových instalatérů). Na tomto shromáždění pouze pro pozvané diskutovalo přibližně 80 vývojářů o mnoha záležitostech ohledně jádra a jeho budoucího vývoje. Následující reportáž byla sepsána Jonathanem Corbetem, který se události účastnil a byl členem výboru pro program.
Vývojáři jádra se pokoušejí oživit Linusův notebook po operaci disku.
Sezení, která se konala první den:
Linux 3.0: měli by vývojáři vydat Linux 3.0 se zaměřením na vyhození staršího nepotřebného kódu?
Zprávy z minisummitů: zprávy ze shromáždění vývojářů kontejnerů, bezdrátového síťování a správy napájení.
Kdy by měly být začleněny ovladače? Široká diskuze srovnávající rychlé začleňování ovladačů do jádra a čekání na to, až budou splňovat standardy kódu v jádře.
Interakce souborových systémů a blokové vrstvy; co potřebují současné souborové systémy, aby byly schopné vytěžit ze současných úložných zařízení maximum.
Mezisubsystémové záležitosti; jak se mohou vyvíjet subsystémy, které jsou hodně využívány jinými částmi jádra?
Nástroje, konkrétně nový nástroj Patchwork.
Bootstrap kód. Proč dává každý distributor dohromady svůj vlastní kód initrd/initramfs a jak lze situaci vylepšit?
Kvalita jádra a proces vydávání, různé diskuze o tom, jak vytvářet lepší jádra a téměř rozhodnutí o přechodu na jednotýdenní začleňovací okno.
Sledování. Dlouhá diskuze o potřebách uživatelů a jak by tyto požadavky mohlo být nakonec možné splnit.
Dokumentace. Vždycky chceme více a lepší dokumentace, ale jaká dokumentace by byla nejužitečnější pro komunitu vývojářů?
Konalo se krátké sezení opravující chyby, které bylo zaměřeno na čelní položky na KernelOops.org. Během půl hodiny byli vývojáři schopni opravit 13 ze 14 nejčastějších chyb. Panovala široká shoda o tom, že to bylo produktivní využití času a během budoucích příležitostí se bude opakovat.
Další zprávy z minisummitů pokrývající virtualizaci, síťování a bobtnání [bloat] jádra.
Všechno o vláknech; o jaderném fondu vláken [thread pool] a o obsluze přerušení ve vláknech.
Projekty s velkými komponentami v uživatelském prostoru; jak můžeme projektu infrastruktury přímého vykreslování [direct rendering] usnadnit práci, aby mohl fungovat s hlavní řadou jádra?
Rafael Wysocki vedl sekci o nové infrastruktuře uspávání/probouzení [suspend/resume]. Většina hovorů byla zaměřena na API, které bylo v Jaderných novinách popsáno v březnu (originál na LWN), takže zde znovu popisováno nebude; sledujte Jaderné noviny, kde najdete detaily.
Linus se shromáždění zeptal, kolik lidí stále nemůže uspat své laptopy. Počet zvednutých rukou byl poměrně malý; v této oblasti se věci zjevně zlepšily.
Oprava projektu jaderných údržbářů. Jak můžeme do jaderné komunity lépe přivádět nové vývojáře?
Uzavírací večírek (který byl zároveň zahajovacím večírkem Konference linuxových instalatérů) se stal dějištěm každoroční volby členů Výboru technických poradců [Technical Advisory Board] Linux Foundation. Volba se tentokrát nekonala přímo na Jaderném summitu, aby se jí mohlo zúčastnit více lidí. Zdá se, že v tomto ohledu bylo dosaženo úspěchu; počet kandidátů i voličů byl rekordní. Tentokrát byli za členy výboru zvoleni James Bottomley, Kristen Carlson Accardi, Chris Mason, Dave Jones, Chris Wright a Christoph Hellwig. Christoph byl zvolen na jeden rok, všichni ostatní na dva.
Jaderný summit je na příští rok naplánován od 18. do 20. října v Tokiu v Japonsku.
Před letošním Jaderným summitem Alan Cox navrhl možné téma: věnovat vývojový cyklus na odstranění starých, nepoužívaných vlastností - s možností rozbít někde kompatibilitu - a vydat výsledek jako Linux 3.0 (vizte anketu Chcete Linux 3.0?). Alan sám se summitu nezúčastnil (protože se konal v USA), ale jím navržené téma bylo první na pořadu jednání. Výsledkem je: zdá se, že momentálně Linux 3.0 nepřijde a odstranění starých vlastností není v plánu.
Hovořilo se o ceně za údržbu starých ovladačů a rozhraní, která používá jenom pár lidí. Tento kód vyžaduje aktualizace kvůli změnám API a může obsahovat bezpečnostní díry. V mnoha případech jde o ovladače k hardwaru, který není schopen podporovat vlastnosti potřebné pro současný software, důsledkem čehož jsou stížnosti uživatelů na to, že nástroje jako PulseAudio nefungují správně.
Linus se do diskuze vložil brzy s oznámením, že z tohoto návrhu není šťastný. Tvrdí, že cena za údržbu těchto starých ovladačů je v podstatě nulová. V místech, kde nějaké náklady jsou, souhlasí, konkrétně nemá problém, pokud jsou změny API problematické; chce, aby vývojáři museli přemýšlet nad tím, jestli změna API stojí za problémy, nebo ne.
Linus také upozornil na to, že spousta hardwaru, který jaderní vývojáři považují za bezcenný šrot, je ve skutečnosti v mnoha částech světa stále užitečný. Je mnoho lidí, kteří používají staré věci, a on pod nimi nechce podtrhnout koberec. Také nemá obavy z tvrzení o možných bezpečnostních dírách staršího kódu; jestliže takové problémy existují, říká, postihnou tak málo lidí, že pro žádného crackera se sebeúctou nebude stát za to je zneužít. Takže, shrnul, jakékoliv odstraňování ovladačů by mohlo skončit odstraněním všeho všudy nějakých pěti ovladačů, což pravděpodobně za tu snahu nestojí.
James Bottomley vyjádřil znepokojení, že odmítání zabývat se věcmi, jako jsou bezpečnostní záležitosti, může vytvořit dvouúrovňový systém podpory. Starší hardware může být oficiálně podporován, ale žádní vývojáři se ve skutečnosti nebudou zabývat údržbou kódu a nikdo nemá hardware, aby ho mohl testovat.
Christoph Hellwig upozornil na to, že vytvoření velkého vydání, které by pouze odstraňovalo vlastnosti, by byla "marketingová katastrofa".
Poté se diskuze poněkud odchýlila. Dave Jones navrhl (za obecného potlesku), že za zastaralou [deprecated] by se měla označit značka zastaralosti používaná ve zdrojovém kódu jádra. Zastaralé funkce generují velké množství varování, ale nikdo se neobtěžuje je opravit; tato varování potom nedělají nic jiného, než že skrývají ostatní, mnohem důležitější hlášení. Christoph poznamenal, že skript checkpatch.pl může také vypisovat varování o zastaralosti funkcí, a tam by to bylo mnohem lepší: varování by nepostihlo každého, kdo jádro překládá, ale jen osobu zasílající patch.
Poté bylo navrženo, že by mělo cenu pokusit se o koordinovanou snahu odstranit všechna varování vypisovaná při překladu jádra. Tento nápad se také dál nedostal. GCC vypisuje nemálo falešných varování, jež si stěžují na kód, který je naprosto platný. Opravování varování znamená riziko zakrytí jiných problémů a zavedení chyb. Christoph řekl, že problémy s varováními lze vyřešit jenom v případě, že se se zdrojovým kódem jádra bude dodávat i GCC.
Trochu se diskutovalo i o nástroji sparse; varování, která generuje sparse, jsou většinou považována za mnohem užitečnější. Ale, jak poznamenal Linus, sparse má svou vlastní sadu chybných diagnóz a také to není perfektní řešení.
Po návratu k původnímu tématu vývojáři mluvili o údržbě rozhraní kompatibility starobylých systémových volání. Linus mluvil o tom, jak hezké je vědět, že je stále možné spouštět binárky z roku 1991; na to, že by vývojáři měli být pyšní. S tím spojené náklady jsou opět poměrně malé. Matt Mackall řekl, že jestliže budou tato rozhraní udržována navždy, nemá cenu diskutovat o odstranění ostatních rozhraní.
Závěrem této diskuze je to, že k žádné změně nedojde. Kompatibilita se starým hardwarem a rozhraními zůstává v jádře prioritou, obzvláště když je cena za udržení této kompatibility malá.
V linuxových souborových systémech se toho v současnosti děje hodně; jde o situaci, která pravděpodobně nějaký čas vydrží. Jak se souborové systémy vyvíjejí, je čím dál tím jasnější, že budou zapotřebí změny v interakci mezi souborovým systémem a blokovými I/O vrstvami. Tato diskuze na Jaderném summitu řešila některá z míst, kde jsou změny zapotřebí, ale na jejich implementaci se moc nepracuje.
Chris Mason je hlavním vývojářem přicházejícího souborového systému btrfs. Jednou z položek na jeho nákupním seznamu je způsob, jakým by souborové systémy získávaly lepší porozumění o topologii a povaze úložného zařízení pod nimi. Rád by byl například schopen určit, jestli souborový systém sedí na zařízení bez rotujících částí [solid-state drives, SSD], nebo na tradičním rotujícím disku. Některá rozhodnutí se budou podle povahy zařízení lišit; souborové systémy uložené na discích bez rotujících částí například mohou být rozloženy bez ohledu na dobu vyhledávání [seek time].
Na topologii zařízení také záleží. Obzvlášť, když se používají vícecestné úložné systémy, by souborový systém rád porozuměl tomu, jaké jsou různé cesty, aby byl schopen ho rozdělit na skutečně nezávislé oblasti selhání [failure domain]. S touto informací mohou souborové systémy najít optimální způsoby, jak provádět I/O na zařízení pod sebou.
Stejně tak je potřeba, aby informace proudily opačným směrem. Nadcházející souborové systémy budou provádět rozsáhlé počítání kontrolních součtů dat, aby byly schopné informovat ukládací vrstvu [storage layer], že se blok poškodil. U zrcadlených zařízení to ukládajícímu ovladači umožní obnovit blok z nepoškozeného zrcadla - jestliže bude souborový systém schopen určit, které zrcadlo se poškodilo.
Chris žádal informace o latenci ukládání - jak dlouho lze očekávat, že budou trvat operace - a o optimálních velikostech I/O a zarovnání. Tento požadavek motivován snahou optimalizovat I/O na zařízení bez pohyblivých částí. Zde do diskuze skočil Linus a navrhl, aby se vývojáři souborových systémů "zhluboka nadechli a rok počkali". Zařízení bez pohyblivých částí se během té doby hodně změní a mnoho problémů, které dnes existují, bude do té doby pryč. Souborové systémy vyvinuté pro dnešní SSD zařízení tak budou v době, kdy se tato zařízení široce rozšíří, obsahovat spoustu zbytečného kódu. Je lepší, říká Linus, je prostě považovat za rychlé disky s náhodným přístupem a detaily se nezabývat.
Dalším požadavkem bylo, aby mohly souborové systémy alokovat své vlastní bio struktury místo používání alokačních funkcí blokové vrstvy. To by jim umožnilo uložit svá privátní data do bio bez potřeby připichování se do řetězce oddělených struktur pomocí ukazatele bi_private. Je také obecně potřeba přepracovat operace v adresovém prostoru, aby se umožnilo lepší rozvržení a racionálnější zamykání.
Pro současné souborové systémy je poněkud problematický proces kswapd. Kswapd je pověřen uvolňováním stránek pro paměťový alokátor; potřebuje být schopen udělat svou práci v čase, kdy je v systémové paměti málo místa. V současnosti se kswapd pokusí zapsat nečisté stránky, aby mohly být uvolněny. Problém je, že zapsání může vyžadovat další paměť; jak jsou souborové systémy komplexnější, množství potřebné paměti navíc, zdá se, roste. To může vést k deadlocku, jestliže tato paměť není k dispozici. Vývojáři souborových systémů by byli rádi, kdyby se kswapd zabýval výhradně čistými stránkami, které lze uvolnit bez provádění I/O.
Jednou z odpovědí, která na toto přišla, je, že VFS zpětné volání [callback] writepage() lze považovat za poradní. Tak to nyní dělá btrfs; jestliže volání writepage() přijde v kontextu procesu, který má nastavený bit PF_MEMALLOC (což znamená, že se systém pokouší uvolnit paměť), volání jednoduše selže. To je zcela v pořádku, ale může to narušit výkonnost.
Kswapd ukládá stránky, protože historicky bylo možné, že linuxový systém skončí ve stavu, kdy jsou všechny stránky nečisté. V takové situaci je jejich zapsání jediný způsob, jak znovu zpřístupnit paměť. Současná jádra jsou ale schopná hlídat, jak velká část paměti je nečistá, a výše zmíněné situaci se vyhnout. Zapisování stránek v kswapd již není nutné; místo toho může být řešeno v kontextu, kdy není paměti kritický nedostatek. Tyto změny budou pravděpodobně provedeny v blízké budoucnosti.
Posledním tématem, které bylo diskutováno jen krátce, byly I/O bariéry. Vývojáři souborových systémů by byli rádi, kdyby komplexnější úložné vrstvy - jako je softwarový RAID a kód device mapperu - implementovaly zápisové bariéry. Se současným konceptem bariér ale bude vysoký dopad na výkonnost. James Bottomley si všiml, že lepší práci by odvedlo komplexnější API bariér. Není ale jasné, jestli zisky, které by z toho vyplynuly, by stály za náklady navíc.
První den Jaderného summitu 2008 byl zakončen dvěma diskuzemi věnovanými kvalitě jader a procesu, který je vytváří. Arjan van de Ven začal řečí o datech, která získal projekt Kerneloops. Během krátkého času Arjan nashromáždil informace z desítek tisíc jaderných pádů a varování. Z těchto dat byl schopen vytvořit nějaké závěry o tom, jak jádro selhává a jak dobře si vývojáři vedou při opravování problémů.
Zpočátku Kerneloops fungoval sbíráním hlášení o oopsech z jaderných mailových konferencí. Od té doby mnoho distributorů přidalo nástroje, které hledají zpětné výpisy [tracebacks] v jaderném logu a do projektu je předávají (samozřejmě po odsouhlasení uživatelem). Tyto nástroje jsou nyní zdrojem drtivé většiny (99%) hlášení o oopsech v systému. Jednou z věcí, kterých si Arjan všiml, je, že mnoho z největších problémů, na které uživatelé naráží, není nikdy nahlášeno do jaderných mailových konferencí; hlášení o problémech, která tam lze nalézt, nijak nevystihují, co se uživatelům skutečně děje.
Deset nejčastějších chyb se podílí na celých 60 % hlášení; 25 nejčastějších chyb na 70 %. I když se tedy zdá, že je mnoho způsobů, jak lze jádro shodit, většina problémů uživatelů je způsobena velmi malým počtem chyb. Opravte tyto chyby a většina uživatelů zjistí, že jejich problém zmizel. Na druhé straně žebříčku je téměř polovina chyb, kterou reprezentuje jediné hlášení. I když některé z nich jsou důsledkem podivných problémů spojených s načasováním, většina z nich je pravděpodobně způsobena problémy s hardwarem. Mnoho nahlášených problémů ve skutečnosti nevyžaduje od vývojářů žádnou akci.
Mnoho z nahlášených chyb pochází z kódu utrace. Utrace je sledovací vylepšení vyvíjené mimo strom a dodávané Fedorou; zdá se, že tento kód není připraven na ostré nasazení. Nemálo chyb lze také připsat binárním modulům.
Linus se zeptal, kolik vývojářů občas dostává z tohoto projektu nějaké maily; ruku zvedlo asi deset lidí. Linus by byl rád, aby hlášení bylo zasláno více lidem a hlášení o regresích také. Pokud se tyto informace dostanou k více vývojářům, možná bude opraveno víc chyb.
Regrese byly přirozeným bodem, kterým se zabývala diskuze vedená Rafaelem Wysockim. Rafael ukázal mnoho grafů počtu regresí a s nimi spojených oprav; proložením hlášení o regresích logaritmickou funkcí a spojených oprav přímkou byl schopen extrapolovat bod, ve kterém se obě křivky protnou a všechny regrese budou teoreticky opraveny. Ukázalo se, že současná jádra byla vydána 1 až 3 týdny předtím, než bylo tohoto bodu dosaženo. Podle těchto dat Rafael navrhl, že optimální čas k vydání 2.6.27 by byl za tři týdny.
Jeden problém, který Rafael zmínil, bylo, že opravám regresí trvá příliš dlouho, než se dostanou do hlavní řady. Někteří správci subsystémů rádi nechávají opravy regresí sedět po nějaký čas ve stromě linux-next. Bylo upozorněno na to, že přítomnost v linux-next nepomohla najít původní regresi, takže není pravděpodobné, že by mělo cenu nechávat tam uzrát opravy; místo toho by měly jít přímo do hlavní řady.
Rafael si také všiml, že u některých regresí se neobjevuje žádná snaha je ladit; zdá se, že nikdo nemá zájem na nich pracovat. Pro uživatele může být odrazující neslyšet o nahlášené regresi vůbec nic; někdo by jim měl alespoň říci, proč se na problému nepracuje. Také si všiml, že regrese, které byly děleny půlením (aby se identifikovala změna, která jako první způsobila problém), bývají opravovány rychleji. Data z dělení půlením jsou bezpochyby užitečná, ale skutečný zisk pravděpodobně pochází z toho, že se ukáže prstem na skupinu, která je na vině a která potom pociťuje potřebu vytvořit opravu.
Další záležitost, na kterou Rafael upozornil, je malé jádro oddaných testerů; většina hlášení o regresích pochází od malé pravidelně se objevující skupiny lidí. Třeba by bylo možné některé z těchto lidí rekrutovat, aby pomohli se správou chyb. Mohli by sledovat hlášení, získávat od uživatelů více informací a rýpat do správců, aby se opravy dostaly, kam je potřeba. Tito lidé již ukázali určité množství odhodlání; dát jim tuto roli by umožnilo rozšířit pomoc, kterou mohou jaderné komunitě poskytnout.
Mluvilo se také o pokusu sledovat, jak je jádro pokryto testováním. Šlo by vytvořit nějaký mechanismus, spojený například se "smolt" systémem Fedory, který by hlásil úspěšné nabootování jádra na specifickém hardwaru. Jsou zde zjevné problémy spojené se soukromím, které je potřeba vyřešit, a celá záležitost by vyžadovala určité množství práce. Není jasné, jestli má někdo dojem, že celý tento nápad je dost důležitý na to, aby do něj bylo potřeba investovat potřebný čas.
Matt Mackall položil otázku: co by se stalo, kdyby se začleňovací okno zkrátilo na jeden týden - začlenilo se méně kódu - a vývojový cyklus zkrátil? S určitou disciplínou by bylo možné vydávat stabilní jádro každých šest týdnů. Linus odpověděl, že by byl velmi rád. Jeho hlavní motivací bylo redukovat velikost vydání -rc1, která se během nedávných vývojových cyklů hodně zvětšila. Menší -rc1 by se snáz ladilo a snad by se i rychleji stabilizovalo.
Tento nápad byl nějaký čas diskutován. Kratší začleňovací okno zjevně vyvolávalo obavy u těch vývojářů, kteří již teď mají dojem, že je čtrnáctidenní okno nepříjemně krátké. Začleňování stromů se závislostmi na jiné stromy by se ztížilo, také by bylo těžší zajistit dobré pokrytí testováním, protože by testeři měli méně času na to hrát si s každým vydáním. U některého kódu prostě trvá oprava dlouho; není jasné, jestli by šlo stabilizaci zmáčknout do kratšího cyklu. Byla by potřeba přísnější kritéria, aby se zajistilo, že je kód, který se dostane přes konkrétní začleňovací okno, skutečně připraven.
Andrew Morton se do diskuze vložil se stížností na kód, který se objevuje v hlavní řadě, ale nikdy se neukázal v linux-next či -mm stromě. Souhlasil, že to se bude dít vždy, ale tvrdil, že by to měla být výjimečná událost. Vinný správce subsystému by měl alespoň vymyslet omluvu, proč to dělá takto. Bylo řečeno, že mnoho problémů způsobují výrobci, kteří se v poslední minutě objeví s patchem, který by rádi viděli začleněný. Odpovědí bylo říci jim, že je příliš pozdě, začleňovací okno je pro správce subsystémů, ne pro výrobce.
Po návratu zpět k tématu kratšího cyklu Linus upozornil na to, že by to vyžadovalo velkou pečlivost od každého, kdo by byl zapojen, obzvláště napoprvé. Byl by zapotřebí vývojový cyklus, který nezačne se spoustou čekajícího kódu - což je problém, protože na začleňovací okno vždy čeká velká hromada patchů.
Al Viro navrhl v každém vývojovém cyklu začleňovat jenom podmnožinu subsystémových stromů a z ostatních přijímat pouze triviální patche. James Bottomley odpověděl, že kdyby jeho stromy byly v daném vývojovém cyklu vynechány, jeho definice "triviálního" by se určitě změnila. Dalším návrhem bylo prostě začleňovat linux-next, ale to se Linusovi nelíbilo. Snaží se postupovat tak, aby omezil množství kódu, který se začlení během jednoho dne, aby pomohl lidem testovat noční snapshoty repozitáře. Přetažení celého linux-next by to znemožnilo. Další možností bylo přetáhnout pouze stromy, u nichž byl požadavek na přetažení vznesen před otevřením začleňovacího okna. Po nějakou dobu byl tento návrh populární.
Právě když to vypadalo, že dojde ke konsenzu vyzkoušet uvedení tohoto návrhu do praxe, Matthew Wilcox prohlásil, že se mu nelíbí. Jeho práce zahrnuje sledování záležitostí ohledně výkonnosti, což je proces, který může zabrat poměrně dost času. Zkrácený vývojový cyklus by neposkytl dostatek času na to tu práci stihnout. Andrew Morton řekl, že pro tuto změnu nevidí reálný důvod; neřeší žádný z největších problémů a připravila by nás o úspory plynoucí z velkého rozsahu při testování většího množství změn. Dave Airlie řekl, že by bylo potřeba, aby testeři dělali dvojnásobek práce, protože by jádra -rc1 museli řešit dvakrát tak často. Ben Herrenschmidt měl obavu, že by přísnější termíny způsobily, že by vývojáři více spěchali, což by vedlo k nižší kvalitě kódu. A Dave Jones řekl, že změna cyklu by způsobila, že by budoucí jaderná vydání byla hůře předvídatelná, což by ztížilo komunikaci s prodejci a zákazníky.
Tyto komentáře diskuzi o kratším vývojovém cyklu v podstatě ukončily. Linus to uzavřel, že nakonec je lepší nehrabat se v něčem, co není úplně rozbité. Z diskuze tedy nic nevzešlo, ale bylo to zajímavé prozkoumání toho, jak by se věci daly dělat odlišně.
Ben Herrenschimdt vedl diskuzi o správě fondu vláken [thread pool] v jádře. Jaderná vlákna se typicky používají pro vykonání dlouho běžící práce (která může spát) v oddělené úloze. Hlavním mechanismem, který se v jádře nyní používá, je rozhraní pracovní fronty [workqueue], ale pracovní fronty nejsou perfektní. Staly se určitým druhem poslední záchrany pro různé druhy úloh, které potřebují běžet v kontextu procesu.
Mezi problémy s pracovními frontami patří ten, že se za sebe seřadí [serialize] všechny úkoly, i když toto seřazení není potřeba. V některých případech by seřazení dokonce mohlo vést k zaseknutí [deadlock]. Pracovní fronty nabízejí vývojářům možnost volby mezi vlastním jednoúčelovým pracovním vláknem a použitím keventd - sady vláken pro každé CPU, které se sdílí mezi všemi uživateli. Vlastní vlákno je pro potřeby vývojáře často zbytečný luxus, ale použití keventd může vést k nepředvídatelným latencím. Dobrá volba často neexistuje. Je zapotřebí API, které by umožnilo, aby se na jednom CPU dělo víc věcí naráz, ale stále poskytovalo sdílená vlákna a nízkou latenci.
Jedním z návrhů je umožnit rozvětvení [fork] keventd. Mohla by například vzniknout nová forma pracovní fronty s nastaveným příznakem "asynchronní" [asynchronous]. Když by byla do fronty zařazena úloha, keventd by se rozvětvil a zpracoval úlohu okamžitě. Mělo by být celkem snadné tuto změnu zavést, ale byla by poněkud neefektivní - rozvětvení je drahé.
Další volbou by bylo použít některou z existujících implementací fondu vláken; několik jich již je v oběhu. Démon pdflush má jednoduchý mechanismus, který může fond zvětšit i zmenšit podle potřeby. Btrfs má fond vláken, který je ušitý jemu přesně na míru; jeho velikost se nemění, ale poskytuje nízkou latenci. Kód sunrpc má fond vláken, který Ben popsal jako "děsivý". Také je zde návrh Davida Howellse pro mechanismus "pomalé práce". Z daných voleb je nejobecnější a také podporuje změnu velikosti.
Jednotlivé volby byly trochu diskutovány; Linusův návrh byl nakonec takový, aby se rozhraní pracovní fronty jenom rozšířilo tak, aby poskytlo malý fond pevné velikosti. Ben odpověděl, že kód pro změnu velikosti fondu je dostatečně jednoduchý a nemá smysl ho vynechávat.
Thomas Gleixer vedl diskuzi na spřízněné téma: obsluha přerušení ve vláknech, která v současnosti žije v realtime stromě. Zdá se, že realtime vývojáři se konečně vzpamatovali z převzetí údržby x86 kódu a nyní se vrací k přemýšlení o začlenění zbývajícího realtime kódu.
Realtime strom je nastaven tak, aby byla téměř všechna přerušení obsluhována ve vláknech, ale to by v hlavní řadě nefungovalo. Některá zařízení dále poběží se synchronním zpracováváním přerušení a nápad řešit softwarová přerušení ve vláknech se nelíbí vývojářům síťování. Bylo tedy navrženo poskytnout novou verzi request_irq(), která by ovladači umožnila nastavit obsluhu přerušení ve vlákně. Pokud by správce ovladače žádnou změnu neprovedl, obsluha přerušení by nadále běžela synchronně.
Linus požadoval, aby byla přidána nová funkce místo změny v samotné request_irq(). Zdá se, že stále cítí bolesti předchozích změn request_irq(), které vyžadovaly opravu ohromného množství ovladačů. Nová oddělená funkce byla v plánu od začátku; potřeby jsou značně odlišné. Ovladače, které budou používat obsluhu přerušení ve vláknech, budou muset stále poskytnout krátkou synchronní obsluhu, která určí, které zařízení přerušení vyslalo. Bez této obsluhy by bylo obtížné zajistit správné fungování obsluhy sdílených přerušení.
Následovala diskuze o detailech, ale žádné námitky k plánu jako takovému. Je tedy velká šance, že obsluha přerušení ve vláknech bude zaslána do vývojového cyklu 2.6.28 nebo 2.6.29.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz