Vlákno názorů k článku
Linux se zbaví historických síťových ovladačů, v éře hledání chyb s AI nedává údržba smysl od Harvie .cz - Asi jsem byl naivni, kdyz jsem si myslel,...

Asi jsem byl naivni, kdyz jsem si myslel, ze AI zjednodusi udrzbu legacy ovladacu.
Stare ovladace uz se prilis nevyviji, maji nejak ustalenou funkcionalitu, v jadre jsou tak dlouho, ze je mozne v gitu zkoumat, jak byly v prubehu casu portovany na novejsi jaderne subsystemy. AI tak ma v gitu za ty roky k dispozici treba 3 ruzne , ale funkce identicke implementace ovladace. Zaroven se tamtez muze divat na dalsi podobne ovladace, ktere vyuzivaji podobna API a na postup, kterym tyto ovladace byly modernizovany. Ackoliv jaderny ovladac neni jednoducha webovka, tak ma AI pomerne slusne sance ho udrzovat, protoze jde o reseni pomerne hezky definovaneho problemu. Navic s tim, jak se v prubehu casu zvysuje komplexita software, je urcita sance, ze legacy kod nebude tak slozity, jako moderni kod.

Nedavno jsem uspesne pomoci AI portoval V4L ovladac vyrazeny v kernelu 2.6 na kernel 6.12, perfektne to naportovalo na vsechny moderni subsystemy, V4L2, atd... Jediny hacek byl v tom, ze jsem pak zjistil, ze ten ovladac byl puvodne vyrazen, protoze nefungoval ani v tom 2.6 a i tuto vlastnost se podarilo dokonale naportovat :-)

Ta snaha branit stabilnimu API (napr. jak existovalo NDIS) je velice spatna.

Nekdo rika, ze by to pak nebyl linux.. ale praxe ukazuje ze by to uz k dospelosti bylo potreba.

Prave na hromade vyhozeneho/vy­louceneho kodu je videt, ze kdyby existovalo pevne API, aby code-non-grata bylo delegovano do OOT repa, tak by cela ta saskarna nemela takovou pachut a negativni emoce.

A ano - jsem ochoten akceptovat, ze takove OOT moduly budou vetsi (protoze musi replikovat jinak sdileny kod, kdyz nedosahnou na vsechny exporty, resp puvodne pouzivane funkce vymizi), a ze budou pomalejsi, kvuli potrebe pripadne translacni vrstvy mezi aktualni strategii moderniho kernelu a timto zamrznutym "sunset API".