Odpověď na názor

Naopak to DKMS občas skýtá i výhody, zvlášť pokud se projekt nějak rapidněji vyvíjí, člověk používá třeba LTS verzi jádra a chce novější modul nebo pohodlně zkoušet různé verze bez toho, aby pořád aktualizoval jádro, případně si to ručně přerážel syvými sestaveními toho modulu.

Právě tohle je ale v praxi jeden z největších průšvihů s out-of-tree moduly, protože pokud se má stejný zdroják překládat proti širokému rozsahu verzí jádra, znamená to vzhledem ke změnám API hromadu #if ů na mnoha místech, což kód dost znepřehledňuje. A pokud to má fungovat i s jádry z aspoň nejrozšířenějších distribucí, je to ještě komplikovanější: někdy ten test, jaká verze API se má použít, nejde udělat jinak než podle čísla verze, jenže pak zjistíte, že v konkrétním RHEL nebo SLE jádře by sice podle verze měla být starší varianta, ale už je tam nabackportovaná novější. Kdo někdy něco upravoval v nějakém větším out-of-tree modulu, dobře ví, o čem mluvím.

Jsem zvědav, jak dlouho a jak důsledně si s tímhle bude chtít Kent Overstreet hrát. Nebo jestli se na starší jádra vykašle a bude to udržovat jen pro aktuální mainline, nanejvýš pár verzí zpátky.

Mimochodem, kvůli tomuhle je taky trochu naivní ta představa, že s DKMS se po upgradu jádra moduly automaticky přeloží a uživatel nebude muset hnout prstem. Vzhledem k tomu, že jsem docela dlouho provozoval host moduly pro VMware Workstation s aktuálními upstreamovými jádry, vím o tom svoje. Případů, kdy po upgradu na novou verzi jádra šly moduly přeložit bez úprav, byla tak polovina, možná ještě méně.