Vlákno názorů k článku
Bcachefs má v plánu dodávat modul do jádra jako DKMS od cc - A přitom stačilo jen to, aby se choval...

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ě.

Já s vámi ohledně out-of-tree modulů souhlasím. Rozhodně to není tak, že bych si myslel, že je to optimální situace nebo že s tím případným udržováním kompatiblity s nejrůznějšími verzemi jádra nepřibyde práce.
Jen si úplně nemyslím, že je to nutně faktický konec a nikdo to teď nebude používat, jak naznačoval @cc. Ale samozřejmě záleží, jak to K. Overstreet pojme.. (možná jsem naiva, co se snaží tu sklenici vidět vždycky spíš poloplnou :) ) Ani upřímně nevím, jestli má třeba potenicálně víc reálných uživatelů s mainline jádry, nebo by byl užitečný fokus i na držení kompatibility DKMS modulu s těmi server distribucemi (RHEL/klony, Debian, SLES/Leap atp.).

Chápu jaké problémy to s sebou nese. Bojoval jsem s hromadou převážně proprietárních modulů a nějakých shimů, co se odmítaly sestavit na konrketním jádře, nejen od NVIDIA, ale i IBM, Quantumu atp. Naposled třeba u modulu pro video I/O karty Blackmagic, která má podmíněné části kódu podle detekované verze jádra, podobně jak jste zmiňoval. Chodí třeba se starším RHEL nebo novějším Ubuntu.. ale na Leapu (jádro 6.4) to vyžadovalo manuální intervenci, aby si to sedlo do správné varianty a šlo sestavit přes DKMS.

Jinak vlastně si ani nevzpomenu, že by nějaký modul z mainline jádra vyletěl kvůli jiným důvodům než, že to není udržované a podobné "extempore" vlastně registruji poprvé.
Nedovedu odhadnout, jestli je status: externally maintained definitivní, nebo by se to mohlo časem ještě vrátit.
Jak už jsem tu někde zmiňoval, pro mě je tam obecně pořád strašně velký bus factor (viděli jsme u Hanse Reisera).. pokud by se podařilo získat nějaké investice, zájem firmy, která by v tom viděla potenciál pro své služby, možná by to mohlo změnit situaci. Třeba v tom smyslu, že by k sobě mohl dovolit mít trvale pár dalších lidí, co by do toho trochu víc viděli, starali se o víc o ty release cykly, testy a možná trochu "bufferovali" komunikaci s okolím.
Ale těžko říct, srovnání třeba se ZFS kulhá, tam šlo o projekt, co měl za sebou koordinovaný vývoj pod Sunem/Oraclem s týmem lidí. A jakmile se to uvolnilo, objevily se další komerčních subjekty, co na tom stavěly, přispívaly do projektu a třeba zaměstnaly nebo najaly i některé původní vývojáře.

Ad „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.“

Což je ale v podstatě stejný stav, jako kdyby to bylo přímo v oficiálním jádře – tam by asi taky aktuální verzi modulu podporoval pouze pro aktuální jádro a do starších by portoval maximálně opravy, ne?

Což je ale v podstatě stejný stav, jako kdyby to bylo přímo v oficiálním jádře – tam by asi taky aktuální verzi modulu podporoval pouze pro aktuální jádro a do starších by portoval maximálně opravy, ne?

Jak se to vezme. Pokud je modul součástí mainline, backportují se tam opravy podle stejných pravidel jako u zbytku jádra, ať už v rámci distribuce nebo "usptreamového" LTS procesu. Pokud je out of tree a nikdo si nedá práci s tím, aby šel přeložit - a také fungoval - i se staršími jádry, pak jste odkázán na tu verzi, kde to s vaším starším jádrem (distribučním nebo LTS) ještě fungovalo, ale pozdější opravy vám do ní nikdo backportovat nebude.

Chápu, že zpropagovat opravu do starší větve v rámci jednoho repozitáře je trochu jednodušší, ale jinak v tom nevidím moc rozdíl – tu práci (vyřešit případné konflikty, zkompilovat, otestovat) stejně musí někdo udělat. Nebo to bylo myšleno tak, že v případě změny API tu práci za autora modulu udělá někdo jiný?

Tak zrovna u té nvidie na to docela nadávám, nějakou dobu jsem čekal na novou nvidii aby šla zkompilovat proti 6.12, pak 6.16...
Obvykle mám chuť (a čas) si hrít jen s něčím. Tohle oddělení od vanilla kernelu to dost komplikuje.

Tak nejak by som ocakaval, ze to zacne byt problem pre samotneho/samotnych vyvojarov Bcachefs.

Lebo ako out-of-tree modul proste nebudu mat moznost sahat do casti kernelu mimo svoj modul + nesynchronizovana kompatibilita s viacerymi verziami jadra bude pozierat strasne mnozstvo vyvojarskeho casu.

Pozor. oni sahat na casti kernela mimo svoj modul mozu; symboly co obmedzuju pouzitie su zalozene na licencii (resp. licencii inej ako GPL), nie na tom, ze je nieco externe/interne.

Právě proto, že jsem si chtěl vyzkoušet ZFS, jsem přešel na FreeBSD. Mít DKMS a po každém update jádra ještě kompilovat jaderní modul je hrozný opruz a u storage systému značná nezodpovědnost. Data jsou to nejdůležitější co mám.

Doba, kdy jsem se chtěl doma drbat s patchováním kernelu jsou dávno pryč. Řešit proč patch neprošel, proč to pak nejde zkompilovat, nebo proč to po zkompilování nefunguje? To opravdu ne. Ani DKMS nemusí být všespásné, ale aspoň se předpokládá, že se někdo jiný zaručil za to, že to funguje.

Duvody, proc neni neco v kernelu muzou byt i pravni / licencni, coz je ostatne i pripad ZFS - ono jeho CDDL licence neni kompatibilni s GPL.

Proč by si měl život komplikovat kvůli FS, kterých je v jádru tak 10? Jaké super výhody mi tent FS přináší? Ext4 je default všude a XFS je good pro Cloud a různé storage řešení (třeba minio doporuřuje XFS).

Prostě není důvod se piplat s FS, který je na cestě už se nikdy zpět do Linuxu nevrátit.

Treba proto, ze dotycny FS poskytuje vlastnosti, ktere jaderne filesystemy nemaji. Jiste, nektere vlastnosti ZFS se postupne dostavaji treba i do BTRFS, ale je to beh na dlouhe trati a ne vse tam je dotazene.

Tak to asi nebude případ bcachefs ;-)