Portál AbcLinuxu, 4. května 2025 12:43
Stav vydání jádra. Souborový systém ext4 bez omezení připojení. Citát týdne: Greg Kroah-Hartman. Konec začleňovacího okna 4.13.
Aktuální vývojové jádro je 4.13-rc1 vydané 15. července. Linus k tomu řekl: „Opět platí, že statistiky změn kompletně ovládly hlavičkové soubory GPU AMD, ale pokud tohle ignorujeme, vypadá to celkem normálně, asi dvě třetiny jsou ovladače a jedna třetina ‚zbytek‘ (architektura, jádro samotné, síťování, nástroje).“
Stabilní aktualizace: 4.12.2, 4.11.11, 4.9.38, 4.4.77 a 3.18.61 byly vydány 15. července.
Stabilní aktualizace 4.12.3, 4.11.12, 4.9.39, 4.4.78 a 3.18.62 byly mezitím revidovány a vyšly 21. července.
Ti z nás, kteří se kolem toho motají již delší dobu, mají spoustu vzpomínek na zprávu „/dev/foo has reached maximal mount count“, kterou následovala časově náročná kompletní kontrola daného souborového systému. Vzpomínek na časy, kdy člověk stál před místností plnou lidí a již tak měl zpoždění se začátkem prezentace, přináší zvláštní pocit radosti. Je však pravděpodobné, že si málokdo vybaví, kdy naposledy jsme takovou zprávu viděli na novějším souborovém systému ext4. Dokumentace nyní dohání zpoždění.
Smyslem kontroly vynucená počtem připojení bylo dosáhnout občasného spuštění fsck pro případ, že by si do souborového systému našla v tichosti cestu nějaká chyba. Příkaz tune2fs uměl tyto kontroly vypnout už v roce 1993, ale manuálová stránka byla dlouho proti:
Měli byste důkladně zvážit důsledky úplného zákazu kontroly dané počtem připojení. Vadné disky, kabely, paměť nebo chyby jádra by mohly poškodit souborový systém, aniž by byl označen jako špinavý (dirty) nebo detekována chyba.
Jediný háček je, že kontrola vynucená počtem připojení byla ve výchozím nastavení vypnuta v roce 2011. Nebo jak řekl Eric Sandeen: „Opravdu jsme ‚zvážili důsledky‘ a potom jsme ji ve výchozím nastavení zakázali.“ Pokud jde o teorii, že „tím není třeba uživatele strašit“, navrhl, aby byl tento text z manuálové stránky odstraněn a nahrazen citlivějším textem navrhujícím, že by si funkci někteří uživatelé mohli chtít zapnout. Jeden by si ale mohl myslet, že většina z nás je šťastnější bez náhodných zpoždění způsobených fsck
. Ti opatrnější z nás by si pravděpodobně raději naplánovali pravidelné kontroly v předvídatelných časech.
Pamatujte, pokud vám někdo řekne, že „jádro aktualizujeme pouze tehdy, když máme číslo CVE daného problému“, utíkejte co nejrychleji, je jasné, že nemají tušení, o čem mluví. A ano, přesně tohle mi před několika měsíci řekl šéf bezpečnostního týmu jedné hodně velké firmy.
Ke konci začleňovacího okna 4.13 bylo do hlavního repozitáře začleněno 11 258 neslučovacích sad změn, přibližně 3600 od první poloviny reportu o tomto začleňovacím okně. Do celkového počtu 12 920 sad změn, které se dostaly do 4.12, to má daleko, ale stále se jedná o běžně rušný vývojový cyklus. Následuje shrnutí nejzajímavějších z oněch >3600 nových sad změn.
Mezi významnější změny viditelné uživatelům patří:
Změny viditelné vývojářům zahrnují:
ar
popsány takto:
gnu ar může volitelně vytvořit tenký archiv, který obsahuje index symbolů a odkazy na původní kopie členských souborů v archivu. Je to užitečné při vytváření knihoven pro použití v místním sestavení stromu, kde se očekává, že přemístitelné objekty zůstanou dostupné a kopírování obsahu každého objektu by bylo ztrátou času a prostoru.
Výsledkem této změny by měla být o něco rychlejší a úspornější sestavení jádra.
__GFP_REPEAT
, který byl dlouhá léta předmětem diskuzí, byl konečně odstraněn. Nahradil ho __GFP_RETRY_MAYFAIL, který snad lépe popisuje, jak funguje. Viz tento commit, kde se probírají možnosti, jak říct alokátoru, jak moc se má snažit uspokojit jakýkoli požadavek.Pokud čekáte na změnu RDMA ve 4.13, pak budete zklamáni, tento subsystém se nedostal do začleňovacího okna a bude muset počkat na 4.14.
Jádro 4.13 je nyní ve stabilizační fázi, přičemž finálního vydání se dočkáme pravděpodobně na začátku září.
Pamatujte, pokud vám někdo řekne, že „jádro aktualizujeme pouze tehdy, když máme číslo CVE daného problému“, utíkejte co nejrychleji, je jasné, že nemají tušení, o čem mluví. A ano, přesně tohle mi před několika měsíci řekl šéf bezpečnostního týmu jedné hodně velké firmy.Nějak mi to připomíná diskuzi o 0day uživateli v systemd unitách
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.