Jaderné noviny – 7. 1. 2015: Odkaz dávné historie

23. 3. 2015 | Tadeáš Pelech | Jaderné noviny | 4732×

Stav vydání jádra. Citáty týdne. Odkaz dávné historie.

Obsah

• Stav vydání jádra
• Citáty týdne
• Odkaz dávné historie

Stav vydání jádra

Aktuální verze vývojového jádra: 3.19-rc3 Vývojové jádro 3.18-rc3 vyšlo dne 5. ledna (oznámení). Linus k tomu uvedl:

Je o jeden den opožděné – důvodem nebyl žádný konkrétní problém ve vývoji, ale včera jsme zkrátka doma obkládali koupelnu. Ale rc3 je už venku a všechno probíhá celkem v klidu. Opravdu doufám, že to znamená, že verze 3.19 vypadá dobře, ale je stejně dobře možné, že je to jen proto, že se všichni stále zotavují z dovolených.

Verze 3.19-rc2 byla vydána, s minimálním počtem změn, 28. prosince.

Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace. Aktualizace verzí 3.10.64, 3.14.28, 3.17.8 a 3.18.2 jsou v době vzniku tohoto textu v procesu kontroly, lze je očekávat nejdříve 9. ledna. Připomínáme, že verze 3.17.8 bude poslední aktualizace v sérii 3.17.

Citáty týdne

„Nové a vylepšené“ je ve skutečnosti vlastně jen vylepšené, pokud do toho zahrnete zpětnou kompatibilitu, místo abyste prohlásili: „Teď musí všichni všechno dělat nově a vylepšeně – a jinak.“

– Linus Torvalds

To, že v téhle fázi musím pořád žebrat, aby někdo opravil bufferbloat, je dost otravné. Podle té záplavy problémů jsem si vážně myslel, že si k nám všichni už dávno vyšlapou cestu a začnou používat to nepřeberné množství informací a kódu, které jsme pro vás zveřejnili on-line. Doufali jsme, že všichni řešení bufferbloatu nasadí, hlavně v extrémních případech, jako jsou letadla, přístup ve třetím světě a v odlehlých oblastech.

– Dave Täht

Odkaz dávné historie

Proslulé zásady vývoje jádra uvádějí, že nejsou povoleny změny, které by poškodily programy v uživatelském prostoru; oprava, která by něco poškodila, musí být vrácena. Tyto zásady byly spuštěny ve zkušebním provozu minulý týden, kdy byly dvě takové změny vyřazeny z hlavního repozitáře. Tyto akce ukazují, že vývojáři jádra myslí princip regrese vážně, ale také ukazují, co to znamená, když se tyto zásady opravu dodržují.

Odkaz bezdrátových rozšíření

V temných dobách před přelomem století byla podpora bezdrátových sítí v jádru optimisticky řečeno minimální. Ovladače, které existovaly, se většinou snažily, aby se bezdrátové adaptéry podobaly ethernetovým kartám s několika parametry navíc. Po čase byly tyto parametry standardizované v určitém stylu, v rámci rozhraní „bezdrátových rozšíření“. Toto rozhraní založené na ioctl() nebylo nikdy příliš oblíbené, ale několik let svůj účel plnilo, dokud se vývojáři v roce 2006 nezahnali vlastní vinou do kouta. Problémy s konflikty kompatibility nakonec vývoj tohoto API ukončily; dobrou zprávou bylo, že již existoval plán jeho nahrazení tehdy zaostalým API nl80211.

S odstupem času je nl80211 standardním rozhraním bezdrátového subsystému. Bezdrátová rozšíření, která jsou nyní jen kompatibilním rozhraním nad nl80211, jsou již několik let zastaralá a odpovídající vývojáři by se jich rádi zbavili úplně. Takže asi ani nikoho nepřekvapilo, že byla do verze 3.19 začleněna oprava, která odstranila možnost konfigurovat bezdrátová rozšíření do jádra.

Neméně překvapivý byl ovšem i příval stížností, který následoval v rychlém sledu. Zdá se, že správce sítě wicd stále používá API bezdrátových rozšíření. Ale možná ještě důležitější je, že nástroje uživatelského prostoru (například iwconfig), které byly součástí bezdrátových rozšíření, je stále používají – a ty se zase stále používají v bezpočtu skriptů. Takže to vypadá, že tato změna pravděpodobně rozbije pár systémů. Proto také Jiří Kosina zveřejnil opravu, která tuto změnu odvolává, a Linus ji okamžitě přijal.

Objevily se stížnosti vývojářů, že se uživatelé sami od sebe nikdy starých příkazů nevzdají a že je potřeba na ně trochu přitlačit. Ale jádro není pro takový nátlak nejvhodnější. Lepším přístupem, jak navrhl Ted Ts'o, by bylo:

Co se napíchnout do zpětné kompatibility příkazu „iw“ tak, že pokud argv[0] je „iwlist“ nebo „iwconfig“, poskytnout starším příkazům omezenou sadu kompatibility. Pak už vám jenom postačí, když přesvědčíte distribuce, aby nastavily pravidla tvorby balíčků tak, aby „iw“ kolidovalo s wireless-tools, a podaří se vám, aby všichni přešli na iw nejpozději do sedmi let.

Takový přístup by umožnil zabránit rozbití uživatelských skriptů. Ale i tak by trvalo dlouho, než by všichni uživatelé starých API přešli jinam, takže jádro musí podporovat API bezdrátových rozšíření do 20. let tohoto století.

Bogomips

Podstatně starší než bezdrátová rozšíření je koncept „bogomips“, odhad rychlosti procesoru používaný v jádře (některých verzích) pro smyčky s krátkým zpožděním. Hodnota bogomips zobrazená během startu (a uložená v /proc/cpuinfo) má jen volnou vazbu na skutečný výkon procesoru, ale lidé stejně rádi hodnoty bogomips porovnávají. Zdá se, že některé kódy uživatelského prostoru používají hodnotu bogomips pro vlastní účely.

Název bogomips nemohl působit důvěryhodně ani v začátcích a všechna ta léta mu příliš nepřidala. Funkce jako škálování napětí a frekvence způsobí, že se skutečný výkon procesoru v průběhu času mění. Hodnota vypočtených bogomips se může významně lišit podle toho, jak úspěšný je procesor v predikci smyček při spuštění kalibrační smyčku. Heterogenní procesory situaci ještě více komplikují. Ze všech těchto důvodů skutečné využití hodnoty bogomips v jádru v průběhu času klesá.

Kód architektury ARM na novějších procesorech tuto hodnotu vůbec nepoužívá, raději místo toho dotazuje časovač s vysokým rozlišením. U některých podarchitekturách se hodnota vypočtených bogomips značně lišily od toho, co někteří uživatelé považují za skutečnou hodnotu, což vede ke stížnostem. Vývojáři pro architekturu ARM se proto rozhodli jednoduše hodnotu bogomips z /proc/cpuinfo zcela odstranit. Oprava byla přijata do vydání verze 3.12 v roce 2013.

Téměř o rok a půl později si Pavel Machek stěžoval, že tato změna v jeho systému rozbila pyaudio. Když si všiml, že si stěžují i další, zveřejnil opravu, která tuto změnu ruší. Šlo podle něj o regresi uživatelského prostoru, tedy proti zásadám jádra.

Návrat této změny nepřijali v táboře ARM příliš pozitivně; Nicolas Pitre se jej snažil zablokovat se slovy: „Žádná konfigurace, která opravdu spoléhá na tuto zcela falešnou hodnotu bogomips neodrážející žádnou vazbu na skutečný hardware, nebyla označena za ‚funkční‘.“ Linus s tím ale nesouhlasil a prohlásil, že takové regrese nejde tolerovat a že: „Jádro slouží uživatelskému prostoru. To je naše práce.“ Tato změna byla řádně vrácena; jádra pro ARM počínaje verzí 3.19 budou znovu hodnotu bogomips exportovat; dá se předpokládat, že tato změna se dostane i do stabilního stromu.

Přesto však zůstává drobný problém, že hodnota bogomips vypočtená pro současné procesory ARM porušuje očekávání uživatelů; lidé se diví, když jejich zbrusu nový procesor udává hodnotu 6,0 bogomips. I systémy ARM by měly být rychlejší. Problémem podle Nicolase je, že tato vypočtená konstanta, která by měla pomoci se smyčkami zpoždění založenými na časovači, byla uložena jako hodnota bogomips; tradiční hodnota bogomips nebyla vůbec počítána. Podle něj neexistuje žádný skutečný důvod ke spojení těchto dvou hodnot. A tak zveřejnil opravu, která umožňuje vypočítat bogomips podle načasování spuštění těsné smyčky, která „nedělá nic“ – tak, jak se to dělalo na začátku.

Hodnota bogomips již dávno přežila svou hodnotu pro jádro samotné. Počítá se pouze pro uživatelský prostor, a i tam je tato hodnota přinejlepším marginální. Jak uvedl Alan Cox, hodnota bogomips se většinou vypisuje „pro uživatele, aby si ji mohli zkopírovat a tweetovat o tom, jak skvělé je jejich nový počítač.“ Ale protože některé programy závisí na přítomnosti této hodnoty, jádro musí toto hloupé číslo i nadále poskytovat, navzdory skutečnosti, že přinejmenším odráží realitu přinejlepším chabě. Ale i zbytečné číslo má hodnotu, pokud zabrání programu v havárii.

       

Komentáře

[Petr Tomášek]

Whiskey Tango Foxtrot!?!

To má být jako čeština? Který h@vad@ to překládalo? „... používá bezdrátová rozšíření API“ - co to propána je (*)? „Nástroje uživatelského prostoru“ - ať žijí zbytečné genitivy, jo jo, jen ať to zní co nejkomplikovaněji...

(*)Jestli tam v originále je „wireless extension API“, tak to do češtiny musí jít jako „API rošíření pro bezdrát(ové sítě)“.

[Sadfasfasdf]

prvni grammar-nazi byl editor knihy mein kampf.

bajdvej, nebyl to tvuj pradeda?

[Petr Ježek]

Nepletete si gramatiku se sémantikou?

[Petr Tomášek]

Ale prdlajs grammar-nazi. Když musím číst větu pětkrát, bych ji pochopil, protože překladatel je lempl, tak se ozvu, ne?...

[nobody]

ne... kdyz to musis cist petkrat asi je lepsi uvedomit ze ty jsi h@vad@ co misto premysleni radeji nekomu/naneco nadava... a nejlepe za neco co sam neudelas vubec, natoz lepe...

[Petr Tomášek]

Blbost, prostě překlad je mizerný a ničím to neokecáš.

[nobody]

to neni okecavani, proste misto nadavani udelej lepsi preklad, pokud neudelas tak nadavej sobe ;)

[ʚĭɞ 🍉]

Nemusím být kuchař, abych poznal nepovedené jídlo.

[nobody]

a pokud je to jidlo zadarmo a nikdo te nenuti to jist, budes chodit a kricet jak je to jidlo nepovedene a proc radeji kuchar neobjednal donasku ?

[ʚĭɞ 🍉]

To vůbec není o penězích. Pojďme se bavit o Fricových „překladech“…

[nobody]

o tech 22 prekladech co cetlo celkem 68774 uzivatelu ? tak nejspis je zrusit/zakazat kdyz jsou tak spatne ? nebo, vlastne nechat a nadavat ??

Petr Tomášek si rad zanadava, nedokaze si to odpustit a misto toho dodat radeji .patch clanku, nenabidne ze bude pomahat s korekci, nenavrhne ze bude udrzovat "kernel AN->CZ slovnik"...

[ʚĭɞ 🍉]

o tech 22 prekladech co cetlo celkem 68774 uzivatelu ? tak nejspis je zrusit/zakazat kdyz jsou tak spatne ? nebo, vlastne nechat a nadavat ??

Pleteš si uživatele a zobrazení. Navíc to nic neříká o kvalitě těch článků – na lŽivě nebo PCT taky občas otevřu článek, ale neznamená to, že je dobrý.

Ostatně, ty Fricovy překlady nejspíš někdy (i opakovaně) viděl každý uživatel české lokalizace linuxového desktopu nebo souvisejících aplikací (včetně Qt Creatoru).

nenabidne ze bude pomahat s korekci

Já to udělal. Odpověď jsem už ale nedostal. Netuším, kde ty moje e-maily skončily. Možná v /dev/null, možná ve spamu, možná prostě není zájem.

[snajpa]

Myslim, ze kritika *timhle* tonem, neni nejlepsi napad. Sam jsem na to velmi alergicky. Takovym pak rikam akorat - jdi a udelej lip, nebo umis jenom kecat?

[Petr Tomášek]

Sorry, ale ta úroveň překladu je prostě děsivá. To už byste líp udělali, kdyby se to nepřekládalo vůbec a jenom tu byl link na originál...

[ʚĭɞ 🍉]

jdi a udelej lip

Tady? Ehm.

[pc2005]

ad BogoMIPS: Tak mě napadá proč to neudělat šalamounsky: importovat hodnotu třeba ze /sys/ a pak ji zobrazovat kernelem v /proc/cpuinfo. Tu hodnotu v /sys by mohl plnit nějaký userspace benchmark .

[Petr Ježek]

Není snad ideální bogomips prostě vypustit? Jím poskytované informace jsou k dispozici jinak a lépe.

[Petr Tomášek]

No a jak jinak porovnávat, kdo má větší péro?

[pc2005]

Očividně to vypustit nejde, když to zase vrátili. Mé řešení by alespoň problém odsunulo do userspace, což by IMO zjednodušilo přechod z těch divných programů, co ten bogomips potřebují. Navíc by to stimulovalo tvorbu univerzálního linux benchmarku pro všechny architektury, takže by se přes tohle číslo opravdu daly proměřovat penisy .

[Dreit]

Univerzální benchmark by se mi líbil, nejlíp ve dvou provedeních:

- předkompilovaný - výsledky by se daly přímo porovnávat. Nejlíp jako LiveCD s pevnou verzí benchmarku, kernelu,..

- s možností kompilace u uživatele. To by dalo uživateli skvělou možnost zkompilovat benchmark s parametry podle distribučních balíčků, potom s parametry na míru jeho procesoru a porovnat rychlost výpočtů. Konkrétně třeba AMD Bulldozer, údajně na tom nebyl výkonově vůbec špatně, ale tehdejší benchmarky jeho výkonu nedokázaly využít (někde byl článek o gcc a kompilaci pro bulldozer, kde to autor vysvětloval).

[Michal Kubeček]

Vypustit ji právě nejde, protože to rozbije programy, které parsují /proc/cpuinfo a nepočítají s tím, že by tam ten řádek najednou nemusel být. Na druhou stranu ale nemá smysl se nějak moc snažit, aby co nelépe vystihovala "rychlost procesoru", protože tuhle úlohu neplnila moc dobře nikdy (a ani to nikdy nebylo účelem) a už hodně douho ji neplní vůbec. To je to, co (někteří) vývojáři ARM architektury nepochopili, takže to nakonec vedlo k uraženým reakcím typu "tak já to prostě udělám tak, že to vždycky ukáže jedničku, a bude vymalováno".

[finn]

tak já to prostě udělám tak, že to vždycky ukáže jedničku, a bude vymalováno

Mě to přijde jako rozumné řešení. To číslo přeci (už) nemá smysl, takže jestli tam je jednička nebo jakákoliv jiná hodnota je téměř jedno.

[Otto Šabart]

typo: "... když se tyto zásady s/opravu/opravdu dodržují."

Pak me smazte.