A legutóbbi Solaris bejelentés kapcsán menetrendszerűen előjött, hogy bezzeg a Solarisban mennyire jó a stabil API, és Linuxban mennyire gáz, hogy folyamatos szívás van a változó API-k instabil implementációival.
Én azt nem tudom, hogy hogyan lehetne másképpen csinálni a Linux esetében? Mert egy alapvetően kereskedelmi rendszernél tudom a megoldást. Kell néhány tökös architekt, akik szép szóval - korbáccsal terelgetik a fejlesztőket a helyes irányba.
Linuxnál odáig könnyű eljutni, hogy "legyen jól megtervezett, stabil API". Csak utána a megvalósítási javaslatok el szoktak akadni.A probléma nagyon sokrétű:
- kultúra (cowboy-kódolás, "worksforme", "már csak tesztelni kell")
- technológia (nagyon sok architektúra, nagyon sok támogatott hardver, ... etc.)
- tesztelők kevesen vannak, és csak nagyon korlátozott konfigurációkon tesztelnek
- kevés kód review
- elégtelen fejlesztőeszközök
- nagyon sok ágon, sok irányba folyik a fejlesztés, az egyetlen minimális kohéziós erő a "mainline-ba kerülés" célja
...stb.
Ugyanakkor látszik, hogy a Linux ipar gyakorlatilag ehhez a helyzethez adaptálódott: a felhasználókat használják béta tesztelőnek
- "stabil" kernel kiadások pár havonta
- kb. félévente "stabil" Ubuntu, Fedora, OpenSuse kiadások, ahonnan a kitesztelt feature-ök bekerülnek az "enterprise" változatba)
Ha visszanézünk a kernelfejlesztés történetére:
2.0-nál azt mondtuk, várunk 2.0.5-ig, mielőtt felrakjuk.
2.2-nél talán 2.2.10 volt a mondás?
2.4-nél, ha jól emlékszem ez még tovább tolódott. Emlékszem olyanokra, hogy majd 2.4.30-nál...:)
Ez azt is jelentette, hogy egyre kevesebben használtak fejlesztői kernelt, ezért egyre kevésbé voltak kitesztelve, közben egyre nagyobb mennyiségű kódot kellett volna tesztelni.
Erre volt válasz a külön "fejlesztői fa" megszüntetése. Persze a felhasználó nem hülye, és most már elég ritkán van arra szükség, hogy maga fordítgasson kernelt, tehát ő használja a disztribútorok kerneleit. Ergo a vanilla kerneleknek megint kicsi a tesztbázisa, a disztribútorok tesztkapacitása véges, tehát megint a végfelhasználók fogják tesztelni...
Ezen csak több QA erőforrással lehetne segíteni, de:
-a QA néhány megszállott embertől eltekintve tipikusan "fizetett munka" jellegű tevékenység
-a cégek saját QA erőforrásaikat nyilván a saját érdekeiknek megfelelően vetik be, és nem a vanilla kernel feature by feature tesztelésére
-nincs túl nagy hagyománya az automatizált teszteknek a kernelfejlesztők körében, az LTP nekem édeskevésnek tűnik.
- elsőként el kéne dönteni, hogy _mit_ akarunk tesztelni, és mikor tekintjük a tesztet sikeresnek...egyik sem triviális
- ezt a tevékenységet valamilyen non-profit, de anyagilag jól támogatott szervezetnek kéne koordinálnia, pl. Linux Foundation. Egyelőre nem látni túl nagy mozgást ezen a téren.
"Jól megtervezett API-k":
API tervezésnek több módja van, lássuk hogyan működik ez Linux esetében (vigyázat, a következő rész erős iróniát tartalmaz):
1. Bizottság alapú:
- követelményeket gyűjtünk: ezeket az emaileket senki nem olvassa el, ha konferenciát szervezünk, arra kb. 5 ember jön el, akikkel egyébként is egyetértünk
- összerakjuk az API-t, kiküldjük reviewra: most kapunk 3 kommentet, amiből 2 a névkonvenciónkat vitatja, 1 pedig felhívja a figyelmet néhány nyelvtani hibára a kommentekben.
- implementáljuk: mire idáig eljutottunk, Gipsz 23 Jakab egyetemi hallgató már összehackelt egy megoldást a problémára, ami ugyan nem olyan jó mint a mienk, de már van 10 másik felhasználó, és ezerrel lobbiznak, hogy az övék kerüljön bele a kernelbe.
2. Evolúciós alapú:
- gyorsan eljutunk worksforme szintre
- ezerrel nyomjuk a marketinget (LWN cikk havonta a minimum :) )
- belobbizzuk a mainline-ba, amint már 1 architektúrán nem Oops-ol.
- ha egy másik architektúra/alrendszer/driver jön, hogy ez náluk így nem fog menni / lassú lesz / nem így kéne, akkor szétflameljük őket
- amig ők a flametől égő sebeiket nyalogatják, gyorsan összedobjuk a v2-t az API-ból, ami néhány dolgot javít a jogos észrevételek közül. Persze a lényeget nem.
- mivel már a mainline-ban vagyunk, v2 pikk-pakk bekerül (Andrew Morton morog egy kicsit, de senkit nem érdekel mit mond)
- ezzel egyidőben bejelentjük, hogy a current + 1 -es verziótól a v1-et nem támogatjuk, mindenki portoljon v2-re.
- ...
Mivel tudjuk, hogy a Linux esetében jelenleg kizárólag a 2. verzióval lehet eredményt elérni (akik az elsőt próbálták, nagyrészt még mindig out of tree patchként tengetik életüket), és fentebb illusztráltuk, hogy ez félkész kódokat / rossz API-kat eredményez, szerintem jobban járunk, ha nem próbálják a rossz API-kat bebetonozni, és 10+ éven át támogatni...
Persze, ha valaki rájön, hogy hogyan lehet gyorsan, jó és időtálló API-kat tervezni, amelyek kiscsillió architektúrán/hardver eszközzel működnek, egymásnak ellentmondó követelményeknek felelnek meg (embedded vs. enterprise), és Gipsz 23 Jakab egyetemi hallgató, valamint Xi Huan junior szoftverfejlesztő is képes őket használni, akkor szerintem nagyon sokan imába foglalják majd a nevét...
Nektek mi a véleményetek?
Üdv,
Gergely
- 2245 megtekintés
Hozzászólások
subscribe
"A fejlesztot azert fizetik, hogy oldja meg a problemat. Ez egy kemeny szakma." - Chain-Q
- A hozzászóláshoz be kell jelentkezni
énisénis
--
Keep it simple, stupid.
- A hozzászóláshoz be kell jelentkezni
recece
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
Elgondolkodtató
- A hozzászóláshoz be kell jelentkezni
Mire lenne jó egy stabil API azon kívül, hogy a hardware gyártók megírnák a saját szarabbnál szarabb zárt drivereiket? Ha mindenfelé stabil API lett volna a Linux 1.0 -ban, akkor mára szerintem nem sok nyílt forrású hardware driver lenne.
Mainline -on kívül szívás kódot karbantartani és ez egy erős nyomás afelé, hogy kerüljön be a kód a mainline -ba. A mainline -ba kerülő kóddal szemben vannak követelmények, amik többé-kevésbé kiszűrik a béna kódot (persze nem a hibákat), API -t követelnek amit több hasonló célú alrendszer felhasználhat (ld. selinux, vserver, openvz), így profitál belőle a kernel, míg stabil API -val a 3rd party modulok/alrendszerek hatalmas kódda hízhatnának, anélkül, hogy univerzálisan felhasználható kódot adnának a közösbe.
Jó példa erre a storage HBA-k gyári driverébe épített ezernyi feature, minden driverbe implementáljak ugyanazt (pl multipath), miközben annak egyel magasabb szinten a helye. A mainline -ba nem engedik be az efféle drivert, amíg a multipath része nem egy univerzális API. Ez a szűrő is megszűnne.
Én pár tucat Debian szerver felett felügyelek amik teljesen különböző feladatokat végeznek, az Etch (és -n'half), Lenny kerneleken eddig 3-4 hibába ütköztem összesen, többségükre van workaround. Talán eddig egyszer kellett sid kernel, hogy menjen amit szeretnék. Hogy az -rc kernelekre hány tesztelő van, nekem teljesen mindegy, elégedett vagyok a stabil disztró kiadások kernelével, egyebet nem tudok elmondani..
Bár szokatlanul jól összeszedett a témaindító poszt, szerintem igencsak egy oldalról nézed a dolgot. Szerintem sok érvednek csak akkor lenne alapja, ha a Linux még csak egy üzleti terv lenne, nem pedig egy sikertörténet.
- A hozzászóláshoz be kell jelentkezni
Mire lenne jó egy stabil API azon kívül, hogy a hardware gyártók megírnák a saját szarabbnál szarabb zárt drivereiket?
Ehelyett van sok szarabbnál szarabb nyílt driver. És sokszor még kilátás sincs rá, hogy adott cég hivatalos támogatást nyújtson a saját hw-éhez. Csodás.
- A hozzászóláshoz be kell jelentkezni
Idézet:
És sokszor még kilátás sincs rá, hogy adott cég hivatalos támogatást nyújtson a saját hw-éhez.
A valóság az, hogy manapság a kernel driverek nagy részét maga a gyártó írja, vagy támogatja. Pl még az nvidia is commit -olt a reverse engineered driverekbe, miközben megvolt a saját zárt drivere. Manapság nincs szervergyártó aki olyan chipeket szállítana, amik nem támogattak Linuxon. Mivel van konkrétan problémád?
Talán a GPU piac az utolsó bástya, de az AMD már ott is megtört, persze idő kell a használható driverekhez, de mostmár biztosak lehetünk abban, hogy lesz.
- A hozzászóláshoz be kell jelentkezni
azért wlan driver környékén is van nagy gányolás
---
/* No comment */
Ketchup elementál megidézése a sajt síkra
- A hozzászóláshoz be kell jelentkezni
Csak ugyanannyi mint minden mashol. "Worksforme" keresztbe kasul workaroundolt cuccok. :-/ (Tisztelet a kivetelnek persze.)
- A hozzászóláshoz be kell jelentkezni
Az igazi nagy bástya a webcam driverek. Létezik olyan webkamera gyártó amelyik csinál linux drivert?
- A hozzászóláshoz be kell jelentkezni
Érdekes cikk, határozottan van benne valami. Annyit jegyeznék csak meg, hogy a legnagyobb probléma ott van, hogy az API eleve architektúra függő, ezért van olyan sok verzió. Ez nem jó. Az API-nak pont az lenne a lényege, hogy egyéges felületet biztosítson, elrejtve a hardware-t. Szóval szerintem a következőket kellene tenni ahhoz, hogy jó legyen:
1. teljes szemléletváltás: egységes API-ra van szükség (ennélkül szerintem neki sem lett volna szabad állni a kernel fejlesztésének).
2. a subsystemek maintainereiből álló csapat leül a seggére, és végiggondolja az API-kat
3. előállnak egy olyan absztrakt API réteggel, ami független minden korábbi architektúrától, mégis mindegyik leírható vele (ez a leghúzósabb rész, ehhez szerintem folyamatos egyeztetés mellett is legalább 1-2 év kell, mire kialakul)
4. seggberúgnak mindenkit, aki olyan kódot küld a mainline-ba, ami nem követi a lefektetett szabályokat
Imho a fenti pontok nem lehetlenek, csak kérdés, valaha is lesz-e hozzá kellő akarat. Pont a linux kernelben tudok rá egy gyönyörű, iskolaszerű példát: a VFS. Érdekes, ott meg tudták oldani, hogy az összes filerendszer összes hülye funkciója egy egységes API-n keresztül legyen elérhető (most tekintsünk el az fsync mizériától).
A Solaris kernelben azért olyan jó az API szvsz, mert a fejlesztés legelején megvolt a 2. és a 3. pont, és asszerint haladtak az implementálásnál. Az nem érv, hogy kevés archon elérhető, mert a Sparc és az Intel pont homlokegyenest egymás ellenkezője, ezáltal széles palettát fog át (attól még, hogy a két véglet között nincsenek közbenső állomások, ez még így van). Nem hiszem, hogy különösebb gondot okozna például Alpha-ra áttenni a Solaris API-t.
- A hozzászóláshoz be kell jelentkezni
1. Mi a gond jelenlegi API-val?, a szemlelet valtast indokolni kell. Elso korben celokat meghatarozni, es jelenegi API hibait felsorolni es indokolni. Tudsz ilyet ?
2. Folyamatosan gondolkodnak
3. Hol latsz te architektura fuggo "API" -t a Linux kernelben ? Szerintem az Archok kerdese teljesen jol meg van oldva. Peldat tudsz mutatni ?
4. Most is vannak kovetelmenyek.
"A teve egy olyan lo amit egy bizottsag tervezett."
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
1: folyton változik és a külső gyártóknak (pl. nvidia, ati) a nemakaromnyílttátenni meghajtóikat folyton hozzá kell igazítgatniuk, ami ugye nekik (és felhasználóiknak) nem jó, viszont a hivatalos álláspont az, hogy "good luck, you are on your own here, you leech". A kérdés az, hogy hova álljunk be a zárt meghajtók - felhasználói szívás - "every software should be free" háromszögben úgy, hogy mindenkinek (vagy legalábbis a felhasználóknak?) jó legyen.
- A hozzászóláshoz be kell jelentkezni
Meg fognak törni a gyártók és ezzel járnak jól a végfelhasználók is.
Semmi értelme nincs egy nyílt forrású kernelnek zárt driverekkel, amikor a kernel egyik fő feladata a hardware illesztés, ebben a kérdésben nem lehet megalkudni. Az már épp elég megalkuvás, hogy licensz nem tiltja a zárt forrású driverek modulként való illesztését.
- A hozzászóláshoz be kell jelentkezni
Idézet:
Az API-nak pont az lenne a lényege, hogy egyéges felületet biztosítson, elrejtve a hardware-t.
Vagy épp a hardware elől rejti el a kernel -t. Rengeteg API van a kernelben (a VFS -en felül is) és nem kevés stabil is: pl a 2.2 -es kernel futtatni tudja a mai Debiant is (kipróbáltam), ez nyilván egy stabil API eredménye.
Ahova stabil API kell, ott (többnyire) stabil API van (ld. a syscall -ok).
Ahova praktikus egy API ott jellemzően van is. Nem stabil, de miért is kene hogy az legyen, mikor ezeknek a kliense maga a kernel és aki az API -t változtatja, az az "összes" klienst is tudja egyúttal.
Így általánosságban ez egy értelmetlen vita.
- A hozzászóláshoz be kell jelentkezni
Annak ellenere, hogy a kesobbi valtozasok nagy resze nyilvanvalonak tunik, jo / stabil API-t nem olyan egyszeru csinalni.
Inkabb valtozzon az API, mint hogy egy szar API-hoz kelljen ragaszkodni.
Lsd Microsoft is rendszeresen kidobja az API-it, ahogy a tehnologia / igenyek valtoznak. Pedig ott jopar architect dolgozik :)
Amugy a legkevesbe effektiv, ha egy tucat chief architect leul, megtervez valamit, majd odadobja a feljesztoknek, hogy "sracok, ezt programozzatok le.".
- A hozzászóláshoz be kell jelentkezni
Az szerintem se jó ha CSAK az elméleti szakemberek ülnek le, és gondolják ki hogy "nesze nektek, ezt programozzátok le". Ebből sok esetben olyan gondok születhetnek, hogy például az adot konstrukció nehéz/lehetetlen impelemntálni.
Nem tudom mennyire jó példa de pl. a tisztán microkernel is milyen jó elgondolás, de mégsincs gyakorlatban elterjed/jól működő megvalósítása.
Tehát az elméleti tervezésbe minenképpen be kell vonni a tapasztalt kernelfejlesztőket, akik már az elején azt tudják mondani, hogy igen szép és jó csak a gyakorlati megvalósítás problémákba fog ütközni.
- A hozzászóláshoz be kell jelentkezni
"Nem tudom mennyire jó példa de pl. a tisztán microkernel is milyen jó elgondolás, de mégsincs gyakorlatban elterjed/jól működő megvalósítása."
mar hogy ne lenne: QNX, Integrity, etc.
--
When in doubt, use brute force.
- A hozzászóláshoz be kell jelentkezni
Jó valóban. Csak azt nem értem, hogy ha olyan jó az a microkernel, miért csak 1-2 ilyen működő OS van, míg monolitikus/modulárisból sok száz is talán.
- A hozzászóláshoz be kell jelentkezni