Vlákno názorů k článku
Nový způsob distribuce driverů od Novellu
od anonym - Prosím vás, co je tohle za výsmysl? Přečtěte...
-
Prosím vás, co je tohle za výsmysl? Přečtěte si např. http://en.opensuse.org/Kernel_Module_Packages.
Ve zprávičce jsou tři zásadní nesmysly:
"Součástí YaSTu v nové verzi SUSE Linuxu je i kABI" - kABI je název (binárního) rozhraní mezi jednotlivými částmi kernelu. Není to žádná součást YaSTu.
"Tento binární interface by měl zajistit řešení problému binární kompatibility driverů a kernelu." - Nikoliv. kABI se mění s každou verzí jádra (nikoliv však proto, aby se ztížil život autorům binárních ovladačů - viz dále), tedy i s každou verzí SUSE Linuxu. Dokonce nejenom to, kABI se může změnit i během normálních aktualizací.
Celkově: To, co je novinkou v SUSE Linuxu 10.1, je podpora balíčků s jadernými moduly (Kernel Module Packages, KMP). Znamená to, že správce balíčků je schopný při aktualizaci jádra poznat, zda jaderný modul z již nainstalovaného balíčku bude fungovat/nebude fungovat s novým jádrem. Pokud bude (protože příslušná část kABI, kterou daný modul využívá, se nezměnila), zařídí to tak, aby i nové jádro tento modul používalo. Pokud modul fungovat nebude (příslušná část kABI se změnila), začne se shánět po aktualizované verzi balíčku s modulem.
Není to tedy snaha Novellu o prosazení stabilního kABI, není to ani žádný "wrapper", jak tu zmiňovali někteří diskutující. Jde o vyřešení problému "Jak poznat, které moduly po aktualizaci jádra nebudou fungovat, a co s tím".
A ad stabilní kABI: to, že se kABI velmi často mění, není způsobeno tím, že by vývojáři chtěli schválně znepříjemňovat život autorům binárních ovladačů. Oni na ně prostě jen neberou ohled. kABI se mění jen a pouze tehdy, když je to výhodné - přinese to zvýšení výkonu, umožní to zavedení nových funkcí nebo je to nutné k odstranění chyby. Rozhodně to není tak, že by si Linus řekl: tak, a teď tady trochu změním kABI, abych rozbil tady tenhle ovladač. Schválně, zkuste do LKML poslat patch, který samoúčelně mění kABI, co vám na to vývojáři řeknou. -
Milan Jurik (neregistrovaný)Hlasite jsem doufal, ze aspon nejaka snaha vznikla, protoze tech zmen v ABI je extremne mnoho na stabilni radu. Bez zjevne snahy s tim neco delat :-( Ne kvuli binarnim ovladacum, ale kvuli ovladacum jako takovym. To siroke podpore tezko prospiva.
To, ze LT deklaroval, ze tvurcum binarnich ovladacu stabilnim ABI praci neusnadni, je realita. To, ze kod nepatchuje schvalne pro rozbiti, je samozrejme jasne, takhle svym casem neplytva. Ale za jistou formu obrany to brano je.
Asi je cas zkusit se podivat do kodu te veci od vas a aspon prostudovat, jak to tam delate :-) -
Milan Jurik (neregistrovaný)Zaprve - nekdo musi ty prislusne ovladace upravit ve vanille a ten nekdo muze svuj cas venovat necemu jinemu.
Zadruhe - ne vse je ve vanille, i kdyz je to open source. Nektere alternativni veci jsou mimo ni, nektere ovladace ve vyvoji jsou mimo ni. A ti vsichni musi sledovat a prislusne upravovat svou praci. -
Musim sa priznat ze som podlahol zavadzajucemu popisu, najme vete: "Tento binární interface ...". Z toho som usudil ze ide o wrapper. Mal som si precitat originalny clanok, takto doslo k zbytocnej diskusii. Dakujem za vysvetlenie.
> Rozhodně to není tak, že by si Linus řekl: tak, a teď tady trochu změním kABI, abych rozbil tady tenhle ovladač
Tym bola asi myslena moja veta:
> Caste zmeny v API su prave kvoli stazeniu vytvarania binarnych ovladacov.
Myslel som to tak, ze pokial by neexistoval problem s binarnymi ovladacmi, tak nevidim problem v tom aby existovalo stabilne API aj ABI pre ovladace. Taketo rozhranie je mozne urobit bez toho aby to malo vplyv na vykon samotneho jadra (pokus o zavedenie takehoto rozhrania uz bol). Znacne by to ulahcilo vytvaranie a udrzbu ovladacov aj v zdrojovom tvare a nemuseli by sa ovladace kompilovat pre kazde jadro/distribuciu. Ulahcilo by to zivot ovladacom mimo stromu kernelu a vyrobcovia by mohli dodavat ovladace AJ v binarnom tvare (jeden modul pre vsetky distribucie) a nemuseli by sa pri kazdej zmene jadra znova kompilovat. Problem je v tom, ze AJ by sa zmenilo na LEN.
Caste zmeny su prave kvoli tomu, ze taketo rozhranie neexistuje a to neexistuje prave kvoli binarnym ovladacom (bez dostupnosti zdrojoveho kodu). Preto sa vylepsovanie vykonu a zavadzanie novych funkcii deje pomocou zmeny ABI aj API, inac je to aj logicky najednodusia cesta. Pridanie novych funkcii je mozne aj pri zachovani spatnej kompatibility na urovni API aj ABI.
Ale ako povedal Linus (z ceskeho prekladu jadrovych novin http://www.abclinuxu.cz/clanky/jaderne-noviny/jaderne-noviny-245):
Vůbec mě nezajímá stabilní ABI pro moduly kernelu, a dokonce se aktivně snažím bránit všem pokusům o něj. Chci, aby si lidé byli vědomi toho, že vnitřnosti kernelu se mění a že tomu tak bude i nadále.
Pro binární moduly není žádná dobrá omluva. Některé mohou být technicky legální (díky tomu, že nejsou odvozenou prací) a povolené, ale i když jsou legální, tak jsou pořádnou osinou v zadku a vždycky příšerně chybové.
Občas si mi výrobci stěžují na můj nezájem o alespoň snahu pomoci binárním modulům. To máte těžké. Je to obousměrná ulice: když nepomůžeš ty mně, nepomohu já tobě. Binární moduly Linuxu nepomáhají, spíš naopak. Jako takovým nemáme důvod jim pomáhat, aby byly ještě rozšířenější než teď. A máme spoustu důvodů proti. -
disorder (neregistrovaný)>> Myslel som to tak, ze pokial by neexistoval problem s binarnymi ovladacmi,
>> tak nevidim problem v tom aby existovalo stabilne API aj ABI pre ovladace.
http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt -
Milan Jurik (neregistrovaný)Ano, pohled GregKH na vec. V nekterych kusech se snazi z oponentu delat primo idioty ("There is no way that binary drivers from one architecture will run on another architecture properly."). Jinde obhajuje prekotny vyvoj (3x prepsane USB) ci primo "vyhrozuje", ze jinak nelze delat security fixy. Ano, tvurci zmeny se prace ulehci, tvurci stavajiciho kodu ztizi. Typicky GregKH.
-
disorder (neregistrovaný)Zle to chapete. Nerobi z nikoho idiotov. Totiz kernel moduly mozu pri roznych procesoroch a dokonca uz i pri roznej konfiguracii kompilovaneho kernelu obsahovat rozdielne struktury. Nehovori tu o tom istom binarnom ovladaci, ale o tom istom ovladaci pre rozne architektury.
"Prekotny vyvoj" je podla vas zavne nieco zle. Preco?
Bezpecnost je asi tiez zla, ze? Pokial sa zisti chyba v designe, musi sa napravit. Netreba pozerat na to, ci prestanu fungovat ovladace. -
Milan Jurik (neregistrovaný)Ja velmi dobre vim, ze se meni struktury pri ruzne konfiguraci jadra, to jsem nerozebiral. Ovsem binarni interface pro celou platformu x86 napriklad muze byt stejny, navic on to opravdu sepsal tak, ze to vyzniva, ze ten sam ovladac samozrejme nemuze bezet na x86 a ppc treba. Coz temer nikdo neceka snad :-)
A ano, prekotny vyvoj je velmi zle. Protoze se napriklad 3x prepisovalo USB, jak sam pise. Misto toho, aby se nejdrive udelal navrh, nejdrive se neco zprasi. Vsak ono to nejak funguje. Kdyz k tomu pripoctu slabe testovani nekterymi vyvojari, tak drive byl pretizen LT, ted AM. I ten opovrhovany MS se takhle nechova.
Ne, bezpecnost neni zla, nema cenu me zesmesnovat, to zvladam sam ;-) Ale chyba v designu souvisi jednak s tim prekotnym vyvojem, jednak v obcasne snaze rychle "to nejak poresit, jen aby to uz bylo". Pravda take je, ze si aktualne nevybavuju, ktera zasadni zmena ABI ovladacu perifernich zarizeni souvisela se security, ale to bude hlavne tim, ze uz me pred casem prestalo bavit to studovat.
Uz jen to, ze ovladace perifernich zarizeni se nedari rozumne oddelit od zbytku systemu, neni optimalni. To, ze to lze udelat, dokazuje vetsina ostatnich OS. -
Navrh na oddelenie API aj ABI pre ovladace uz raz bol a velmi dobry (musel by som pohladat na to nemam moc casu), ale pochopitelne bol odmietnuty. Oddelit API aj ABI je mozne, aj ked niektory subsystem prerobite aj 10x. Je mozne zachovat kompatibilitu smerom k vyssim verziam jadra. To znamena, ze starsi driver vam bude fungovat na novom jadre, pravdaze nemusi (ale moze zavisi od rozsahu a typu zmien) vyuzivat moznosti novsich jadier.
Udrzba takehoto rozhrania je narocnejsia z pohladu jadra. Zase jednoducha z pohladu ovladacov. Problem by bol v tom, ze by ale vznikali len binarne ovladace.
Pre vyvojarov jadra by to bolo zrejme schodne v tom pripade pokial by ovladace boli sirene v zdrojovom tvare, ale pre pouzivatelov by bol k dispozicii prekompilovany v binarnej podobe, ktora by ulahcila jeho instalaciu bez ohladu na distribuciu (s ohladom na platformu). Zlahcilo by to zivot pouzivatelom a nebolo to zneuzivane vyrobcami hw na sirenie len binarnych ovladacov.
Je mozne spravit ovladac aj platformovo "nezavisly". Jedna sa o format binarneho suboru, ktory by obsahoval kod pre viac platforiem (prvy krat tusim pouzite pri NeXTe), tak ako Appletacky format binariek, ktore obsahuju kod pre intel aj pre powerpc.
V takom pripade nahra loader do jadra len kod pre prislusnu platformu. Na druhej strane toto asi nutne nieje naco stahovat subor, ktory obsahuje kod napr. pre 10 platforiem a z celeho suboru vyuzivat len 10% kodu ;).
Vyzera to tak, ze najskor musia "dospiet" vyrobcovia HW az potom "dospeje" linux a to bude velmi tazka a dlha cesta pre linux.
Na jendu vec sa ale este "zabuda", momentalne je dolezitejsia skor stabilita API/ABI v uzivatelskom priestore. Smer kniznice -> aplikacie. Myslim, ze zatial sa to podarilo len libc. Linux (respektive jeho pouzivatelia) potrebuje na rozsirenie aj komercne aplikacie, ktore sa inak ako v binarnej podobe sirit nebudu. Lenze udrziavat aplikaciu pre napr. 3 balickovacie systemy a 10 distribucii, nieje nic co by nadchlo komercne firmy a uz vobec nie pouzivatela, ked nenajde balicek pre tu svoju distribuciu. -
disorder (neregistrovaný)sa k tomu len strucne vyjadrim:
sr*t na uzivatelov! pre mna je dolezity hlavne spolahlivy system a nie zlozitost (na ktoru sa nestazujem). Nikdy som nemusel kompilovat kernel kvoli nejakemu ovladacu ako to bolo vyssie spominane. Je mi uplne jedno, ze to odradi firmy pisat proprietarne ovladace a programy. Radsej nech ich nerobia, alebo nech to je OpenSource. A nie som ziaden fanatik, ak to tak vyznelo :)
API v user space stabilne je. Tam si hlavne treba ustrazit ci su v systeme verzie kniznic proti ktorym boli nalinkovane. -
Milan Jurik (neregistrovaný)Kdo vam natloukl do hlavy, ze spolehlivy system je ten, ktery se neustale prekotne meni?
Kdo vam natloukl do hlavy, ze stabilni API zvysuje zasadne slozitost systemu? U ABI lze o tom diskutovat, to uz ale souvisi se strukturou Linuxu jako takoveho.
To neodrazuje firmy od psani proprietarnich ovladacu, to odrazuje firmy od psani jakychkoliv ovladacu, i tech open source.
A udrzovani vice verzi knihoven v systemu je vysoce nevhodna vec, protoze ty starsi muzou obsahovat zasadni chyby, treba i bezpecnostni povahy, ktere jsou v novejsich verzich fixnute. A to uz se vzdalujeme zase jeste jinam. -
disorder (neregistrovaný)sa k tomu len strucne vyjadrim:
sr*t na uzivatelov! pre mna je dolezity hlavne spolahlivy system a nie zlozitost (na ktoru sa nestazujem). Nikdy som nemusel kompilovat kernel kvoli nejakemu ovladacu ako to bolo vyssie spominane. Je mi uplne jedno, ze to odradi firmy pisat proprietarne ovladace a programy. Radsej nech ich nerobia, alebo nech to je OpenSource. A nie som ziaden fanatik, ak to tak vyznelo :)
API v user space stabilne je. Tam si hlavne treba ustrazit ci su v systeme verzie kniznic proti ktorym boli nalinkovane. -
Oddelit API je mozne a pri urcitem poctu "klientu" dane API vyuzivajici je to i dobry napad, i kdyz to nepochybne da dost prace. Osobne myslim, ze nektere API v jadre uz jsou napsane tak dobre, ze se v minor verzich nemeni. Oddelit ABI je vyrazne tezsi a snahy o to zpusobi zpomaleni a vetsi pametovou narocnost pri komunikaci pres to ABI.
