Novinkou v čerstvém OpenSUSE 10.1 je i nový způsob distribuce driverů. Dosavadní stav, kdy bylo nutno při aktualizaci jádra kompilovat i drivery se s novinkou od Novellu zřejmě stane minulostí. Součástí YaSTu v nové verzi SUSE Linuxu je i kABI (Kernel Application Binary Interface). Tento binární interface by měl zajistit řešení problému binární kompatibility driverů a kernelu. Konkrétně pro SUSE Linux to znamená, že si potřebný driver pro nový hardware stáhnete jako balíček podobně jako balíček s aplikací. Toto řešení by mělo umožnit výrobcům hardware poskytovat binární drivery pro nejnovější i starší verze kernelu a mohlo by o velký kus posunout i problém driverů pro nový hardware v Linuxu.
Nový způsob distribuce driverů od Novellu
22. 5. 2006
57
nových názorů
-
Tiez to vnimam negativne. Navyse to podla mna urcite sposobi konflikt medzi vyvojarmi kernelu. Vytvorit stabilne (v zmysle zmien) ABI v jadre pre ovladace nieje problem.
Pocas vyvoja jadra sa objavilo niekolko pokusov. Boli vsak odmietnute, prave z toho dovodu aby nevznikali binarne ovladace. Pokial sa dobre pamatam tak Linus sa dokonca vyjadril v tom zmyslel, ze budu stazovat zivot tvorcom binarnych ovladacov ako sa len bude dat. Takze sa da ocakavat, ze to povedie k zmenam v jadre, ktore znemoznia vyuzivanie takehoto "wrappera".
Takze v konecnom dosledku z toho moze byt este viacej problemov ako osohu. Navyse postoj niektorych vyrobcou HW bude taky ze uz vobec nebudu uvazovat o zverejneni ovladaca so zdrojovymi kodmi ani o zverejneni dokumentacie. -
platYpus (neregistrovaný)Ktery prase neco takovyho napadlo ... ? Uz se tesim na Linuxove ovladace typu "SuSE, version XXX only". Chudak uzivatel si pak koupi vyrobek s deklarovanou podporou Linuxu a nasledne zjisti ze je mu to na dve veci.
BINARNI OVLADACE jako takove jsou HUMUS a melo by se proti nim bojovat. Krasnou ukazkou jsou ovladace Nokia D211 (jsou jen pro kernel 2.4 a funguji jen za N dalsich okrajovych podminek) nebo nekterych sitovych karet (napr. Allied Telesyn).
A ted kontrolni otazka: myslite ze Vam takove zarizeni bude fungovat za par let rekneme s kernelem 3.X ... ?
Napoveda: Vyrobce uz nebude zarizeni podporovat (jo pane, to je 4 roky stare s tim za mnou nechodte ...), dokumentace k dispozici nebude (proc bychom ji davali, kdyz ji nikdo nechce - s temi binarnimi ovladaci to prece _v_tento_okamzik_ kazdemu chodi ...).
Kde delam chybu ... ? -
glx (neregistrovaný)Vazeny.
To, ze binarni (a jine) ovladace pro Nokia D211 jsou hnus (mohu potvrdit) a zaviseji uzce na verzi kernelu, souvisi prave s tim, jak je aktualni situace k tvorbe ovladacu nepratelska. Vyrobce by za stavajiciho stavu musel byt opravdu genialni, pokud by byl schopen vytvorit dobre a siroce pouzitelne uzavrene ovladace. To dela castecne Nvidia za cenu toho, ze musi ovladace casto upravovat v zavislosti na tom, jak se rozhrani meni jako chameleon. Maloktery vyrobce si to muze dovolit, protoze to sezere spoustu casu.
Jen naivka si muze myslet, ze lze vyrobce hardwaru donutit k tomu, aby vydavali ovladace ve zdrojacich, ktere jeste budou muset po vydani temer kazde nove verze kernelu, mirne upravovat. Mnoho vyrobcu bere ovladace jako sve hardwarove know-how, proste soucast hardwaru. To uz by mohli vyrobci rovnou ke kazdemu kusu hw poskytovat i veskerou dokumentaci vcetne technologickych postupu pri vyrobe...To je samozrejme _nerealizovatelne,_zcela_nepruchodne_.
Novell jen pochopil to, co je jasne uz davno. Chvalabohu, ze se konecne nasel nekdo, kdo ma dostatek sily to prosadit. -
melkor (neregistrovaný)Naprosto genitalni nazor!
Takze by bylo v poradku, kdyby Intel a AMD prestali zverejnovat instrukce novych procesoru s tim, ze to by rovnou mohli "ke kazdemu kusu hw poskytovat i veskerou dokumentaci vcetne technologickych postupu pri vyrobe..." Pochopitelne vyroba starych procesoru by byla ukoncena a kazdy by si svobodne mohl poridit specialni Intel OS nebo AMD OS. -
glx (neregistrovaný)Jeste jednou si to, prosim, po sobe prectete at vidite, jakou pitomost jste zplodil.
Mala napoveda:
Smyslem CPU je zpracovavat instrukce. Bez toho, aby z tech instrukci nekdo delal programy, by nemela vyroba CPU smysl. Proto jsou instrukce zname - jejich dostupnost je smyslem existence CPU. -
mm (neregistrovaný)S grafickými kartami je to ale prakticky to samé, a přesto k nim opensource drivery NVidia ani ATI neposkytuje. AMD by si taky mohlo říct, že nějaké jejich nové super-duper rozšířené instrukce jsou jejich know-how a nezveřejnit k nim dokumentaci, ale jen jakýsi binární driver na CPU. Tohle je přesně to co dělají výrobci grafických karet a platí to i o spoustě dalšího hardwaru. Tzn. jděte se s tak pitomým názorem vycpat.
-
Gringo (neregistrovaný)Nahodou ja v tom vidim i jedno velky plus! Pokud jde o binarni ovladace, osobne s nima mam taky jen ty nejhorsi zkusenosti, ale v tomhle vidim moznost pokroku. Muze to zase o kousek vic priblizi linux sirsi spolecnosti, protoze ho to udela vic user-friendly.
Spolecnosti, ktery se doted brani vydavani ovladacu v podobe zdrojovych kodu, by v tomto pokracovaly i kdyby tahle moznost ted v Suse nebyla - proste by si bud vyrabeli drivery jen pro widle, nebo by delaly binarni baliky (viz. nv). Takhle udelaji drivery aspon pro tu jednu distribuci, kde __budou__ fungovat. Takze neodsuzujme to driv, nez uvidime nejaky vysledky.
G. -
Milan Jurik (neregistrovaný)Jak uz tu jeden prispevatel napsal, menici se ABI binarni ovladace nezastavilo, ukazalo se, ze jen komplikuje situaci uzivatelum.
Ovsem nezavidim tvurcum kABI, protoze za to je nekteri opravdu budou nesnaset a zaroven se musi neustale snazit ohybat menici se ABI v kernelu.
Misto kritiky stabilniho ABI by se meli zastanci opensource ovladacu snazit koupit si pouze prislusny HW a psat vlastni drivery. Ovsem nemalo z nich doma sedne za stroj, na kterem maji potichu prikompilovane binarni ovladace od nVidia nebo ATi v kernelu. -
Milan Jurik (neregistrovaný)Ono to jde, kdyz se chce. Viz broadcom wireless v posledni dobe.
Takze, ano, mnohdy to je o chybejici docu, ale nemalo je to take jen o drzkovani. Kdyz chcete donutit vyrobce HW, aby vam dodal docu/driver, prokazte mu obchodni duvod. Nebo se starejte sami (treba tim, ze si jeho HW proste nebudete kupovat). Plivanim na stabilni ABI se niceho nedosahne. -
glx (neregistrovaný)Je to vyborna zprava pro bezne uzivatele a pro nas, kteri bychom Linux radi videli mezi temito uzivateli v daleko vetsi mire nez dnes. Konecne by mohla skoncit doba, kdy po objeveni se nejakeho zajimaveho noveho hardwaru na trhu obcas dochazi k tomu, ze cekame radu mesicu na to, az ovladac nekdo "nahackuje" za pomoci zpetneho inzenyrstvi.
Je to samozrejme spatna sprava pro ortodoxni fanatiky v nasich radach. Tem to poskytne bohaty prostor pro prudeni.
Linus Torvalds je na hony vzdalen ortodoxnimu fanatismu, je velmi pragmaticky a predpokladam, ze tento krok nakonec uvita.
Bylo by sice hezke, mit vsechny ovladace otevrene - v tom souhlasim - ovsem realita sveta je jina (jak rikaji vice jak desetilete zkusenosti). Nikdo nikomu nebrani delat dal distribuce, ktere budou cimkoliv binarnim netknute. Novell se chova ciste pragmaticky, protoze spravne pochopil, ze pres ortodoxni trvani na ideologii cesta k vetsimu podilu na trhu a schopnosti konkurovat stale arogantnejsimu MS nevede. -
disorder (neregistrovaný)>> pro bezne uzivatele a pro nas, kteri bychom Linux radi videli mezi temito uzivateli v daleko vetsi mire nez dnes
ale kolki by to naozaj chceli, ked to zamena mensi pocet otvoreneho hardwaru a znizenie kvality ovladacov? netvrdim, ze sa to stane, ale vytvori sa priestor...
>> Nikdo nikomu nebrani delat dal distribuce, ktere budou cimkoliv binarnim netknute
to je pekne, ale binarne ovladace by sa proste museli pouzit (ak nechces ten kus hardwaru vyhodit). -
glx (neregistrovaný)Mensi pocet otevreneho hardwaru ? Zcela otevreneho hardwaru je dnes zanedbatelne mnozstvi a nikdy tomu nebude jinak - z komercnich duvodu, protoze tak dnes proste svet kolem hardwaru funguje.
Nizsi kvalita binarnich ovladacu ? Co je kvalitnejsi ? Uzavreny ovladac, ktery delal primo vyvojar od vyrobce se vsemi informacemi anebo ovladac, ktery vznikl zpetnym inzenyrstvim metodou pokus - omyl ? Ja bych to zdaleka nevidel tak jednoznacne !
Znovu opakuji - mit vse otevrene je krasny sen, ale je to jenom sen. Je treba trochu pragmatismu, jinak se nehneme z mista a Linux ceka stagnace. Svet nefunguje podle verozvestu typu Stallman. Na druhe Torvalds je presne ten typ cloveka, ve ktereho vkladam velke nadeje - pri svem zdravem pragmatismu s tou nesmyslnou a krajne skodlivou praxi neustalych zmen rozhrani postupne skonci. -
disorder (neregistrovaný)Ta sranda od novellu este neexistuje a uz sa predpoveda stagnacia na zaklade jej neexistencie v buducnosti? Linux nestagnuje teraz (a je taky aky je), nebude ani v buducnosti (a nepotrebuje k tomu novell).
Do Linusa vkladam i ja nadeje, kedze si mysli, ze proprietarne ovladace (kernel moduly) su prace derivovane zo samotneho kernelu, co GPL vylucuje. A nema ich rad ani z praktickych dovodov. A taktiez sa pri vyvoji Linuxu nepocita so "stabilnym API".
(pre konkretnejsie info pozri subory COPYING.modules a stable_api_nonsense.txt v dokumentacii kernelu) -
glx (neregistrovaný)Uz 10 let slycham tyto reci, kde se hovori, jak firmy, vyrabejici hw, zacnou otevirat sve ovladace a delat jejich verze pro Linux. 10 let je to stale stejne - firmy se spolehaji na to, ze ten ovladac vzdycky nakonec nekdo za ne napise a zaradi do jadra, aby ony pak mohly prodavat hw i uzivatelum Linuxu. Ze takto vznikle ovladace mnohdy nedokazi zarizeni vyuzit na 100% (neni divu, vzdyt vznikaji za pomoci analyzy bez dokumentace) je zjevne netrapi - prodaji nam to tak jako tak. Zdrojaky davat nechteji,maji pro to duvod. Udrzovat ovladace tvari v tvar se neustale menicimu rozhrani (ta hloupa a umyslna chameleonizace je jednou z nejvetsich sabotazi Linuxu) jim zvysuje naklady. Ale ve chvili, kdy budou mit jistotu stability rozhrani, ovladace samozrejme k dispozici mnozi vyrobci daji.
Znovu opakuji - nic vam nebrani psat si sve otevrene ovladace tak jako dosud. Dokonce vam to vyrobci usnadni i tim, ze vam daji do ruky ovladace uzavrene pro tyz OS. -
neurol23 (neregistrovaný)http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt
vic k tomu nemam co dodat -
> Je to vyborna zprava pro bezne uzivatele a pro nas, kteri bychom Linux radi videli mezi temito uzivateli v daleko vetsi mire nez dnes.
Pokial je pre Vas vyborna sprava znizenie stability systemu tak potom je to dobra sprava. Co myslite, ze sposobuje v 99% pripadov nestabilitu Windows?
> Linus Torvalds je na hony vzdalen ortodoxnimu fanatismu, je velmi pragmaticky a predpokladam, ze tento krok nakonec uvita.
Ufff odporucil by som Vam precitat si jeho reakcie na zavedenie podobnych rozhrani priamo do jadra. Zvykne sa v nich vyskytovat slovo NIKDY. Skor sa da ocakavat, ze dojde k upravam v jadre, ktore znemoznia pouzitie takehoto wrappera. A bude dochadzat k este castejsim zmenam v API.
Este zhrnutie niektorych dalsich prispevkov ktore obhajuju tento krok. Tak v jednom pripade z 10000 sa mozno jedna o nejake know-how. (Ake know-how ma vyrobca pri prevodniku USB - serial vid pripad spomynanej nokie). Vatsinou ide o to, ze samotny vyrobca malokedy vytvara aj driver. Ten robi zvycajne tretia strana (zmluvna firma) a v jej zaujme nieje zverejnenie zdrojoveho kodu (ide o jej biznis). Co chapem tiez.
Caste zmeny v API su prave kvoli stazeniu vytvarania binarnych ovladacov. Verim tomu, ze pokial by vyrobcovia zacali vytvarat ovladace a zverejnovat ich v zdrojovom tvare, zmenil by sa aj pristup vyvojarov jadra aj Linusa samotneho. A vytvorilo by sa stabilne rozhranie.
Ide o zacarovany kruh. Vyrobcovia nepisu ovladace, lebo kvoli castym zmenam v API sa pre nich tazko udrziavaju a vyvojari jadra menia API kvoli tomu aby stazili vytvaranie binarnych ovladacov.
Podla mna sa tymto krokom Novellu dosiahne len to, ze sa snizi stabilita systemu a este viac sa zhorsi pristup k dokumnetacii od HW, klesne pocet novych ovladacov vo forme zdrojoveho kodu a zvysi sa frekvencia zmien v API. Vznikne konflikt medzi Novellom a vyvojarmi jadra. Ja na tom nic pozitivne nevidim.
Jedna pozitivna vec, ktora dufam z toho vzide bude nejake kompromisne riesenie (nenapada ma ake) alebo strategia/najdenie modelu vyvoja/"donutenia" vyrobcov dodavat ovladace v zdrojovom tvare. -
Milan Jurik (neregistrovaný)Problem - tady nikdo asi neobhajuje binarni drivery. Tady jde o to, jakym zpusobem se proti nim Linux brani. Kdyz uz o ne nestoji, at se autori jadra porvou o GPL a nechaji je zakazat primo soudne. A ne tak, ze stezuji praci vsem.
Cim to, ze nektere ovladace pro Solaris existuji v te same binarce od verze 2.6 po dnesni opensolaris, tedy pres deset let. Ty same. A presto vznikaji uz spoustu let i open source ovladace.
Chovani vyvojaru jadra okolo ABI/API brzdi nejen binarni, ale take a mozna i vice ty open source.
Btw. D211 neni prevodnik USB<->serial :-) A zrovna v pripade techto prevodniku neni problem kupovat jen ty s open source ovladacemi.
Klicove slovo - business reason. -
Jestli to nebude tim ze vyvojari Solaris jsou za svou praci placeny. Porad tady nekdo rika, ze vyvojari Linuxu schvalne meni API. Ale nepredstavujte si to tak, ze vyvojar sedne ke kernelu a rekne si "uz jsem dlouho nezmenil API" a stravi pak hodinu tim, ze ho meni. Jde spis o to, ze vyvojari programuji naprosto normalne a umyslne ignoruji veci mimo jadro. Takze kdyz pri programovani zjisti, ze potrebuji tohleto zmenit, tak to zmeni a neztraci cas psanim nejakych obezlicek aby nekde zustalo stejne rozhranni ...
Mimochodem, kernel by mel byt rychly a mit malou spotrebu pameti. Obe tyto optimalizece jdou primo proti snaze o stabilni API. Jeden extremni priklad: predavani argumentu v registrech. To zvysuje rychlost, v nekterych pripadech muze snizit spotrebu pameti a kdekoliv je pouzito, prestane byt API kompatibilni - aniz by se ve vlastnich zdrojacich kernelu zmenilo COKOLIV. -
Pajus (neregistrovaný)Tak. Ted jste mi promluvil doslova z duse !
Pouzivam SuSe uz skoro 3 roky a tohle vitam !
Nejsem z tech, kteri si kvuli kazde prkotine kompiluji kernel.
Presto vsak chci, aby mi muj celkem bezny HW(cpu-AMD, deska-ASUS, vga-nVIDIA GeForce, ram-KINGSTOM, tisk HP-1410(all-in-one) na linuxu fungoval bez vetsich komplikaci a bez toho, ze bych stravil nekolik hodin ci dnu hledanim jak rozchodit to, nebo ono.
Vitam jakykoli krok k tomu aby mi podobne "znamy" hardware fungoval bez vetsich komplikaci. -
Chapu ze binarni ovladace jsou cestou pro vyrobce HW jak neotevrit specifikace HW a jak nikdy
nedostat ovladace do vlanila kernelu linuxu kde by mely byt.
Na druhou stranu je potreba rict, ze takhle to funguje na ostatnich unixech od od praveku.
Treba na AIXu pridam novou kartu do PCI slotu, zdetekuju novy HW a system si sam rekne, o balik devices.pci.14109100.rte. Tzn. ze PCI id zarizeni se odvodi jmeno baliku, ten si stahnu z webu(CD)
nainstaluju a vsechno funguje jak ma.(A bez rebootu). Kdyz nemenite kernel a rozhrani k ovladacum
kazdy mesic, tak jako na linuxu, tak binarni ovladace nejsou zase takovy problem. -
Boot2Lin (neregistrovaný)Proč ne, už není rok 1998 ani 2000, jsme o dost dále a navíc si M$ s těmi HastaLaVistami naštve hodně zákazníků. Je dobré, když komunita pozmění maličko strategii. Nejde o to Linux všude a za každou cenu, ale lidi potřebují alternativu, která je open-source k nim a ne proti nim. Na mizerný ovladač je možné upozornit na stránkách o hardweru pro Linux (Mimochodem, když nějaký hardware má mizerný ovladač pro Linux určitě má mizerný ovladače i pro ostatní OS a to by ho mělo znemožnit i před zákazníky). Možná by zde byla i jiná cesta a to založit nadaci, která by vyráběla drivery pro Linux a nabízela tuto službu HW firmám (open-source driver zdarma a binary pro kABI za peníze) a zároveň atestovala binary ovladače. Hnutí okolo Linuxu je dostatečně silné, aby to zvládlo.
-
kerala (neregistrovaný)Možná tento krok zrychlí přijímání linuxu na firemních desktopech a noteboocích. K čemu je mi Firefox, OpenOffice, ODF, GIMP, Evolution atd., když na nejnovější notebook TOSHIBA nedostanu linux, neboť chybějí ovladače. Takže na firemních noteboocích nakonec bude M$. Podle mě, Novell potřebuje překlenou období 2-3 let, kdy už bude LSB verze 4.
-
platYpus (neregistrovaný)Tenhle postoj nechapu.
Kdyz nejsem vyvojar (coz nejsem) tak se vzkycky na netu kouknu kterej HW uz nekomu zkusenejsimu bez problemu beha a podle toho vybiram.
Kdyz si jako koncovy uzivatel (co jsem) vyberu nejakou sracku podle barvy case, tak se pak nemohu divit ze mi na tom X veci nebeha. To je jako kdybych si koupil Skodu favorit a pak lamentoval nad tim, ze to nejezdi na diesel ... -
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.
