Jaderné noviny – přehled za červenec 2019 (diskuse)

[xkucf03]

Stojím si za vyjádřením, že kdokoliv tvrdí, že chce stabilní API pro ovladače, po technické stránce neví, co dělá. Množství balastu, které se v průběhu let a desetiletí nahromadí v interních API, operační systém zabije a máme dřívější příklady, kdy se tak stalo.

Tak zrovna k tomuhle slouží sémantické verzování – tzn. zpětná kompatibilita se nemusí udržovat donekonečna¹, ale jen v rámci major verze. Pokud se mění jen minor a patch verze, tak by to mělo mít kompatibilní rozhraní.

_{[1] takže nehrozí, že by jádro bylo zaneřáděné nějakými historickými a nepoužívanými API}

[luky]

Jenze ted se API meni i v patch verzich, kdyz je to nutne pro opravu chyb. Jak by se podle tebe takove chyby resily? Mne prijde lepsi rozbit externi ovladac, nez nechat v jadre diru.

[xkucf03]

API = rozhraní. Je skutečně nutné ho měnit kvůli opravě chyby? Pokud ano, tak je to chyba návrhu a chtělo by to k němu příště přistupovat zodpovědněji. Někdy k tomu může dojít, ale měla by to být výjimečná situace. Může se např. stát, že někdo s tou chybou počítá – a pak je vlastně oprava chyby zpětně nekompatibilní změna.

A hlavně ten argument, na který jsem reagoval, byl:

Množství balastu, které se v průběhu let a desetiletí nahromadí v interních API, operační systém zabije

Tzn. obava o to, že by se v Jádře hromadil starý kód resp. stará rozhraní, která reálně už nikdo nepoužívá. To je ale zbytečná obava, protože tato rozhraní lze vyházet při povýšení major verze. Tzn. třeba jednou za rok za dva nebo jiné dohodnuté období se udělá čistka a zahodí se zastaralá rozhraní – ale všechny verze mezi tím budou zpětně kompatibilní.

Jsou dva extrémní přístupy: a) dodržovat zpětnou kompatibilitu navždy a b) neřešit ji a dělat nekompatibilní změny kdykoli. A pak je tu to sémantické verzování, které nekompatibilní změny nezakazuje (takže lze kód/rozhraní čistit), ale dělá tyto změny řízeně a předvídatelně.

Chápu, že Linux je trochu specifický projekt v tom, že tam je snaha mít všechen kód v jednom gitu a spravovaný centrálně (byť mnoha různými přispěvateli) a udržovat si nějaké moduly bokem není úplně běžné, ale i tak si myslím, že není nutné na tu kompatibilitu takhle úplně rezignovat.

[luky]

Tvoje predstava je mimo realitu vyvojoveho cyklu kernelu. Stabilni minor verze kernelu se udrzuje treba v Redhatu pres 10 let. EOL na RHEL6 je nekdy v 2020 a ma kernel 2.6.32 z 2009 (EOL te verze v upstreamu byl 2016, takze zila pres 7 let). Nikdo nechce udrzovat nejake rozhrani 10 let, kdyz ani nevi, jestli ho vubec nekdo mimo oficialni strom pouziva.

Udrzujeme +-500000 radek jaderneho kodu a cas potrebny na rebase kernelu na vyssi patch level je zanedbatelny (trva mi to vetsinou mene nez 1MD), zejmena kdyz vetsina zmen v rozhrani je z duvodu opravy chyb a tudiz bychom kod museli stejne menit. Changelog pri updatu kernelu musis cist tak jako tak.

Vzhledem k tomu, ze rozhrani jadra je rozsahle, musel bys semanticky verzovat jednotlive soubory pripadne subsystemy, protoze jinak bys musel zmeny bud odkladat a nebo casto zmenit major verzi jadra, takze minor a patch cislo by bylo k nicemu. Predstava, ze kopa semantickej cisel by tu praci ulehcila, je naivni.

[xkucf03]

Stabilni minor verze kernelu se udrzuje treba v Redhatu pres 10 let … Nikdo nechce udrzovat nejake rozhrani 10 let, kdyz ani nevi, jestli ho vubec nekdo mimo oficialni strom pouziva.

Lidé obvykle používají stabilní verze softwaru proto, aby měli jistotu, že se v nich nebude nic měnit, že se budou jen opravovat chyby a že se jim při těchto aktualizacích nerozbije nic, co dříve fungovalo. Pokud z toho budeš nějaké API vyřazovat, protože „se ti ho nechce udržovat“, tak už tam jaksi chybí ta žádoucí vlastnost, že po aktualizaci bude fungovat vše, co fungovalo dřív, a popírá to smysl té stabilní verze, ne?

[luky]

Lidé obvykle používají stabilní verze softwaru proto, aby měli jistotu, že se v nich nebude nic měnit, že se budou jen opravovat chyby a že se jim při těchto aktualizacích nerozbije nic, co dříve fungovalo. Pokud z toho budeš nějaké API vyřazovat, protože „se ti ho nechce udržovat“, tak už tam jaksi chybí ta žádoucí vlastnost, že po aktualizaci bude fungovat vše, co fungovalo dřív, a popírá to smysl té stabilní verze, ne?

Vubec ne, protoze ten, kdo tem lidem dodava jadro jim patricne upravi i ostatni casti, tak aby byly kompatibilni. Pokud nejaka distribuce aktualizuje jadro a ta zmena vyzaduje patch mimojadernych modulu, dojde k aktualizaci a prekompilovani modulu behem updatu. Naproste minimum lidi si udrzuje vlastni jaderne moduly a proto od stabilni verze jadra ocekavaji minimalni zmeny v chovani (napriklad zmeny logiky planovace) a ne stabilni API.