GKH: az Android és a Linux kernel közösség

Kernel

Greg Kroah-Hartman nemrég eltávolította az Android kernel kódokat a Linux kernel "staging" (átmeneti) könyvtárából. Az ok: senki sem tartotta karban. Greg korábban kijelentette, hogy a "staging" könyvtárban levő kódokkal foglalkozni kell ahhoz, hogy beolvasztásra kerülhessenek a mainline kernelbe. Ha ezekkel a kódokkal senki sem törődik, akkor eltávolításra kerülnek.

Mi a baj?

Greg szerint nem is ez a legnagyobb probléma. Az Android kernel kód sokkal több, mint néhány fura driver a drivers/staging/android könyvtárban. Ahhoz, hogy egy Android rendszer működjön, kell egy, az Android fejlesztők által létrehozott új lock típus, és szükséges, hogy a core rendszerben jelen legyenek azok a hook-ok, amelyek kellenek az általuk kifejlesztett biztonsági modellhez.

Ez azt jelenti, hogy semmilyen, az Android hardver platformokhoz írt driver nem kerülhet beolvasztásra a mainline kernelbe, mert azoknak olyan függőségeik vannak, amelyek jelenleg csak a Google belső kernelfájában találhatók meg. Ebből következik, hogy ezek a driver-ek nem is fordíthatók le a kernel.org-os kernelfával.

Greg szerint a Google azzal, hogy nem olvasztatja be a kódjait a mainline kernelbe, megakadályozza, hogy egy rakás hardver driver és platformkód beolvasztásra kerülhessen. A fejlesztő hangsúlyozza, hogy a kernel közösség évek óta arra kéri a vállalatokat, hogy olvasztassák be kódjaikat a mainline kernelbe, hiszen ez számos előnnyel jár. A beolvasztott kódokat szükség esetén ellátják biztonsági javításokkal, illetve lekövetik rajtuk automatikusan a gyors API változásokat.

Jelenleg az Android-specifikus eszközmeghajtó-programokat és platform kódokat fejlesztő vállalatok nem tudják a kódjaikat beolvasztatni, és emiatt sokkal nagyobb erőforrásokat kell a karbantartásra és fejlesztésre fordítaniuk.

Mi kellene ahhoz, hogy az Android kódok beolvasztásra kerülhessenek a mainline kernelbe?

Amikor az Android kód beolvasztásra került a "staging" fába, egy rakás kernelfejlesztő elkezdte átnézni és elkezdtek javaslatokat tenni arra, hogy hol kellene kitisztítani, megváltoztatni őket ahhoz, hogy bekerülhessen a mainline kernelbe. A javasolt változtatások közül számos kihatással van a kernel/user space határvonalra, így ha a kernel oldali dolgokat megváltoztatják, akkor a változtatásokat az Android user space logikájában is le kell követni. Szóval a szükséges változtatásokhoz Google alkalmazott kellene.

Hogy mit lehetne tenni?

Greg nem tudja. A Google nem mutatja jelét annak, hogy a kódját betolná az upstream-be. Pedig ezzel megszüntethetné azt az általa okozott óriási akadályt, amely jelenleg nagyszámú beágyazott Linux hardvercég előtt tornyosul. A fejlesztő reméli, hogy a Google változtat és beolvasztatja a kódjait. Ehhez Greg korábban privátban segítséget ajánlott, de most megtette nyilvánosan is.

A részletek itt.

( trey | 2010. 02. 04., cs – 13:41 )

Lazán kapcsolódik:

A Microsoft tavaly Hyper-V driver-eket (khm) adott ki a kernelhez. Ezek is a "staging" fába kerültek. Ezután a Microsoft emberei eltűntek. Majd előkerültek, állítva, hogy "mi dolgozunk a Linux driver-einken". Most úgy fest, hogy ismét eltűntek. Ha nem kerülnek elő, akkor a Hyper-V driver-ek is az Android driver sorsára jutnak. Jelenleg elő vannak jegyezve eltávolításra a 2.6.35-re.

"Microsoft Hyper V drivers. The developers again seem to have disappeared, this is getting old. Slated for removal in 2.6.35"

--
trey @ gépház

Kérdés, hogy a Hyper V driverek is azért nem lettek eddig beolvasztva, mert nem fordulna le a kernellel, vagy mert eddig csak simán nem került rá sor? Előbbi esetben jogos, utóbbi esetben kitolás. Gondolom nem ahhoz szoktak az ms-nél, hogy 3 havonta módosítani kell egy tökéletesen működő drivert. ;)

"egy tökéletesen működő drivert"

A Microsoft által adott driver messze volt a tökéletestől. Ezért került a "staging" könytárba (aminek nem mellesleg a neve "crap tree"). Ez egy, a beolvasztás előtti átmeneti könyvtár. Ide bekerülnek a dolgok, megnézik mit kell ahhoz változtatni, hogy bekerülhessen a mainline-ba.

Itt láthatod, hogy milyen állaptban volt a driver:

http://lwn.net/Articles/342304/

"Hank Janssen for providing the code and working with me to get it into a workable and semi-mergable state."

[...]

"There is still a lot of work to do in getting this into "proper" mergable state, and moving it out of the staging directory, but Hank and I will be undertaking this task."

Innen (semi-mergeable) kellett volna eljutni a mergeable állapotig, de úgy fest ez nem sikerült.

Ha nem jelentkeznek, akkor GKH bejegyzése szerint el lesz távolítva a staging-ből.

--
trey @ gépház

Ahhoz, hogy karban lehessen tartani valamit, be kéne olvasztani a mainline kernelbe. Előbb beolvasztható állapotba kellene hozni. GKH elvállalta, hogy ebben segít a Microsoft-os Hank Janssen-nek, aki úgy fest eltűnt (legalábbis abból, amit GKH ír ez jön le - "The developers again seem to have disappeared,"). Amíg nincs valami beolvasztva, addig mit akarsz rajta karbantartani?

--
trey @ gépház

Most az első Xboxról beszélek. Próbáltunk feltenni kérdéseket az SDK-ről és úgy általában arról, hogy hogyan lehetnénk hivatalos Xbox fejlesztők. A válasz az volt, hogy sajnálják, de ők semmit nem tudnak itthon erről, mert az anyacég nem ad erről felvilágosítást a magyarországi MS-nek. Két hónappal később a los angeles-i irodán keresztül szereztünk két dev. kit-et és egy debug kit-et. Hozzánk és a Clevers Games-hez jött az első szállítmány Xbox dev. kit Mo-on, amikor még az itthoni MS alkalmazottak azt sem tudták hogy néz ki. Az egyik - akkor még MS alkalmazott srác - eljött megnézni a cuccot. :D
Ennyit a magyar MS kompetenciájáról. Persze azóta biztosan sokat változott a helyzet.

Egyfelol, masfelol ti meg mindig csak kulsosok vagytok ebben a tortenetben, nulla MS erdekeltseggel. Mas informaciokat kap az ugyfel, es masokat egy belsos ember - teljesen mindegy, hogy fejleszto, rendszergazda, vagy epp titkarno. Ezt tessek vegre megerteni, hogy aki az MS-nel dolgozik (es nem a 2-MSINFO-nal), annak lehetnek kulfoldi kapcsolatai, akikkel kapcsolatba lephet. Nyilvan egy kis ugyintezo nem fog ilyesmikrol tudni, foleg, hogy akkoriban szerintem meg magasabb szinten is csak ismerkedtek a termekkel, nem volt mit kommunikalni az ugyfelek fele, mert ok is valoszinuleg akkor kaptak epp az oktatast a termekrol.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Hivatalos" álláspontot nem tudok mondani, de feldobtam a kérdést egy belső listán. Felelős ember válaszolt, és azt írta, hogy tisztázták (újból) a dolgot GKH-val. Hank Janssen továbbra is MS alkalmazott és továbbra is az Open Source területtel foglalkozik. A Microsoftnak van fejlesztési terve a Linux IC-vel, zajlik is a munka ezzel kapcsolatban. Kb. az Microsoft Management Summit (április) környékén lesz erről több szó.

Üdv:
Lepenye Tamás

A kerdes nem elsosorban az, hogy mikor akarnak beszelni rola, hanem hogy miert nem halad a fejlesztes. A Linux kernel nem az a kategoria, amit honapokra ott lehet hagyni pangani...
Illetve az esetleges roadmap-et illene megosztani a kozosseggel, hogy ezaltal legyen egy alap, ami alapjan lehet tudni, hogy meddig van a kod karbantartva. Nem hinnem, hogy ha az MS-nel sokkal nagyobb hozzajarulok be tudtak tartani a szabalyokat, pont az MS ne tudna...
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szomorú tény, de a következő 1-2 évben szerintem semmilyen érdeke nem fűződik az MS-nek ahhoz, hogy bekerüljön a mainline-ba a driver, esetleg némi Linux-barát marketingen kívül.
Bevallom, szkeptikus vagyok azzal kapcsolatban, hogy mennyi tesztelést kapnak az in-tree driverek amikor valaki áttúrja a fél kernelt. Mert az, hogy lefordul, még messze van a működőtől. Ezért szerintem az a kernel-fejlesztők felől érkező marketing, hogy az in-tree drivereket a közösség majd jól karbantartja, nem feltétlenül fedi a valóságot. Képzeljük el, ahogy mostantól minden kernelfejlesztő Hyper-V-n is tesztel...:)

Üzleti szempontból az RHEL és az SLES érdekes. Ha jól értem, akkor mindkettő következő verziója 2.6.32-es kernelt fog futtatni. Tehát az a fontos, hogy a 2.6.32-es kernellel jól működjön a Hyper-V. Az Ubuntu felhasználók is örülhetnek, 10.04-en is emiatt feltehetőleg kevés problémával menni fog.

Innentől kezdve azon múlik, hogy az MS (feltehetőleg nem túl nagy létszámú) Linux kernel csapatának mennyi ideje lesz ezzel foglalkozni, a fontosabb dolgok mellett.

Üdv,
Gergely

...tisztázták (újból) a dolgot GKH-val...

Szerintem ez a kulcsszó. Amikor legutóbb GKH-tól láttam levelet az egyik Android listán (talán a -porting-on, 1-2 hónapja lehetett), akkor a következő dolgokat tette:
- teljesen offtopic dologról beszélt
- meggyanúsította a kérdezőt, hogy személy szerint az ő szerzői jogait sértik

Driverfejlesztési kérdés volt egyébként. Hogy ez miért hülyeség:
- Nem volt egyértelmű a threadből, hogy kernel-space vagy user-space driverről van szó. Utóbbinál egyértelműen semmi köze hozzá.
- Pont a beágyazott eszközök világában nagyon könnyen előfordulhat, hogy egy másik OS-ről portolják a drivert, tehát nem lesz a driver (jelentős része) "derived work", ergó nem kell (mindent) kiadniuk GPL alatt -- igen, erről vannak viták, de még nem láttam senkit, hogy az NVIDIA-t beperelte volna copyright sértésért a Linux driver miatt.
- Még ha GPL alatt kellene is kiadniuk a kódot, a fejlesztőt meggyanúsítani nyilvános listán, amikor még kész sincs a termék, és senkinek nem tudta volna terjeszteni a bináris kódot, elég "érdekes" hozzáállás.

Üdv,
Gergely

( Hiena v | 2010. 02. 04., cs – 15:40 )

Ugyan.
Észre kéne venni, hogy
Android != Linux
Android == Google
Az androidos kernel driverek azért lettek felajánlva, hogy a linuxos fejlesztők "érezzék a törődést", amúgy meg semmi érdeke a Googlenek, hogy bármilyen szinten is résztvegyen nyílt, mainline kernelfejlesztésben, vagy a kódjaik beolvasztásra kerüljenek.
Miért?
Mert a Google egy kutya és a Linux fejlesztői is egy kutya. Kérdés az, hogy ha a két kutya összeáll, akkor melyik fogja a farkat játszani.
Ha az Androidos kódok beolvasztásra kerülnek, ez kihatással lenne a Google addigi munkájára és magára az Androidra is, ami ismerve a Linux kernelfejlesztők tevékenységét, nem biztos, hogy a minőség felé mozdítaná el a dolgot. További probléma, hogy ez esetben a kernel fejlesztők úgy szopathatnák a Googlet (lásd. karbantartott, gyors API változások), ahogy nekik tetszik, ez pedig, nem épp hasznos ha egy üzleti termékről van szó.
Ugyanígy más üzletileg, ha az Androidot és az ahhoz tartozó összes kód felett a Google őrködik. A forrás saját kezelésével jól rajta tudja tartani az ujját az esetleges trendeken és fejlesztéseken, ezáltal megkerülhetetlenné válik. Pl. más az, ha egy hw cég neki, vagy a mainline kernelfába commitol.
A saját kezelésű/nem kompatibilis kód előnyös az HW gyártóknak is, mert nehezebbé teheti a vendor lock-ok megkerülését.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Elhiheted, hogy ennek a fele porhintés.
A visszaportolgatások egyik oka valószínüleg a kódoptimalizálás és a robosztussá tétel. A 2.6 igencsak bloatware és feltehetően az általuk "rondának" defíniált 2.4-es részekkel próbálják kiváltani a 2.6 "tákolt részeit". Szintén valószínüsíthető, hogy nagyon sok saját driver komponensük van, amit megírtak annó a 2.4-hez és a 2.6-os API váltással ezek mentek a levesbe.
A GIT-re való átállás egyik oka az lehet, hogy kezdik utolérni az upstream kernel, tehát egyre kevesebb régi komponensük van.
A sírás kifelé, jó nekik, mert ezzel tudják csökkenti a kódjaik iránti érdeklődést. Egy ekkora cégnél, különösebben nem jelent plusz 5 vagy 10 kóder ráállítása a feladatra, tehátnem valószínű, hogy a feladat mértéke komoly akadályt jelentene számukra.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ebben a cikkben a Google-ön belül használt kernel fejlesztéséről van szó. Az Android kernel fejlesztők egyrészt másik csapat, másrészt minden kód nyilvános (már azelőtt nyilvános volt, hogy az Android platfrom open-source lett volna).

Tény, hogy a fejlesztési folyamat zárt, de ezen az sem változtatna, ha a mainline kernelbe bekerülnének a driverek.

Üdv,
Gergely

A Google már most szop, sok munka nekik portolni a patchset -jüket (saját bevallásuk szerint), ennél rosszabbul biztos nem járnának mainline beolvasztással sem. Nem hiszem, hogy a mainline kernelfejlesztők szétbarmolnák a patcheket, én ilyen balhéról még nem hallottam. Üzleti oka lesz ennek, kezükben akarják tartani a gyeplőt, illetve nincs rá okuk, hogy commit -oljanak. Bár portolni sok meló, a mainline beolvasztás is sok meló, ott nem lehet gányolni, ami házon belül néha belefér.

Naja, de ugyanakkor a google meg sir, hogy mennyi munkaja van atterni uj kernel verziora, van vagy 1000 patch-e (igaz ez nem android kapcsan hanem amit ok belsoleg hasznalnak pl szolgaltatasokban - ha jol ertem). Namost en ezt nem ertem. Ok, fork-oljak kvazi a linux kernelt, rendben, de akkor miert sirnak (meg akkor minek kuldenek akar a staging faba is cuccost, ha ugyis tudjak, hogy nem akarnak amugy ennel jobban egyuttmukodni), hogy ooo olyan nehez dolguk van szegenyeknek ... Ha jol remlik, akkor meg google alkalmazott is volt egyszer vmi kernel developer meetingen aki errol sirankozott ...

( bambano | 2010. 02. 04., cs – 19:46 )

szerintem hajítsanak ki minden google meg ms cuccot a kernelből, úgy lesz egyszerűbb az élete mindenkinek.

Egyébként meg, ha a google androidjának bármi köze van a kernelhez, akkor nem kellene közzétenni teljes terjedelmében a patcheket, miután terjesztik a kernelt?