Portál AbcLinuxu, 25. dubna 2024 16:33
Aktuální verze jádra: 3.16-rc2. Citáty týdne: Tony Luck, Alexandre Courbot, James Bottomley, Paul McKenney. Zpochybnění EXPORT_SYMBOL_GPL(): Sdílené buffery DMA; Skokem přes plot; Je EXPORT_SYMBOL_GPL() nefunkční?
Aktuální vývojová verze jádra je 3.16-rc2 vydaná 21. června. Linus k ní řekl: Vychází o den dřív, ale zítra se mi to nehodí, jelikož budu po většinu dne na cestách, tak to tu tedy máte. V dnešní době mi většina žádostí o přetažení a patchů chodí přes týden, takže si nemyslím, že by vydání v neděli bylo nějak zvlášť odlišné. A rozhodně ani netrpím nedostatek změn pro rc2.
Stabilní aktualizace: minulý týden žádné nevyšly. Verze 3.15.2, 3.14.9, 3.10.45 a 3.4.95 se aktuálně revidují; vydání můžeme čekat 26. června nebo později.
Je těžké vyvolat nadšení pro rozchození NFC ovladače na ia64. Neumím si moc představit, že by někdo vytáhl stokilový 4U server z racku a napochodoval s ním do metra, aby si mohl koupit lístek tak, že se serverem majzne o automat na lístky.
-- Tony Luck
Cachování na ARM je jako kvantový svět, kde nepřetržitě platí Murphyho zákony: věci, které nečekáte, že by fungovaly, někdy fungují, ale nikdy nefunguje to, co byste čekali.
Když cvičíte psa, tak se musíte chovat konsistentně. V exportech symbolů jsme fantasticky nekonzistentní.
-- James Bottomley; není divu, že psi mají s EXPORT_SYMBOL() problémy
Proto ti, kdo chtějí spolehlivou funkčnost velkých systémů, by měli tuto volbu v Kconfig zapnout, uživatelé se zátěží vyžadující nízkou latenci, která hodně vytěžuje jádro, to mohou nechat vypnuté. Ti, kteří nastavují výchozí hodnoty pro linuxové distribuce, by měli vybírat moudře.
Snad od okamžiku, kdy jádro získalo podporu načítání modulů, probíhají vášnivé debaty o legalitě binárních (proprietárních) modulů. Jedním z klíčových faktorů v tomto rozkolu je direktiva EXPORT_SYMBOL_GPL(), která znemožňuje používání určitých symbolů jinými než GPL moduly. Nedávná diskuze ohledně začlenění navrženého nového jaderného subsystému znovu oživila některé otázky ohledně významu a přínosu EXPORT_SYMBOL_GPL() – a jestli má vůbec smysl se tím zatěžovat.
Moduly nemají přístup ke každé funkci nebo proměnné v jádře; mohou používat jen symboly, které byly explicitně „exportovány“ pomocí EXPORT_SYMBOL() nebo některé z dalších variant. Pokud je použito EXPORT_SYMBOL(), pak se k symbolu může dostat jakýkoliv načtený modul. Pokud ale vývojář použije EXPORT_SYMBOL_GPL(), pak bude symbol přístupný jen těm modulům, jež jsou šířeny pod licencí kompatibilní s GPL. EXPORT_SYMBOL_GPL() má označovat rozhraní, která jsou natolik nízkoúrovňová a specifická pro jádro, že jakýkoliv software, který je používá, musí logicky být odvozeným dílem jádra. GPL vyžaduje, že odvozené produkty jsou při šíření zpřístupněny pod stejnou licencí; EXPORT_SYMBOL_GPL() je tedy prohlášením, že daný symbol by měl být užíván jen kódem kompatibilním s GPL.
Stojí za zmínku, že nikdo netvrdí, že symboly exportované pomocí obyčejného EXPORT_SYMBOL() mohou být volně používány proprietárními moduly; řada vývojářů tvrdí, že všechny (nebo téměř všechny) moduly jsou odvozeným dílem jádra, ať už symboly označené jako jen pro GPL používají, nebo nikoliv. Obecně se dá říci, že komunita dlouho udržuje vágní a děsivou nejednoznačnost okolo právní situace proprietárních modulů, i když je nechce narovinu zakázat.
V posledních letech se hodně pracovalo na tom, aby ovladače zařízení mohly sdílet buffery DMA mezi sebou a s uživatelským prostorem. Běžným případem užití je přenos dat videa z kamery přímo do grafického řadiče, což umožní zobrazení těchto dat bez účasti uživatelského prostoru. Subsystém sdílení bufferů DMA, často nazývaný „dma-buf“, je klíčovou součástí této funkčnosti. Když byl v roce 2012 tento kód začleněn, tak proběhla dlouhá debata o tom, zda by tento subsystém měl být zpřístupněn jen modulům pod GPL, nebo všem.
V kódu se původně používalo EXPORT_SYMBOL_GPL. Zástupce NVIDIA požádal o to, aby byla provedena změna na EXPORT_SYMBOL(). Pokud by dma-buf bylo jen pro GPL moduly, pak by, jak řekl, nebylo výsledkem to, že by NVIDIA uvolnila svůj ovladač jako open source. Místo toho:
Pokud se v budoucnu neshodneme na používání EXPORT_SYMBOL, pak například kdyby v budoucnu někdo uvedl laptop s Terga GPU (které používá open source linuxové ovladače) a GeForce GPU (které je, jak je uvedeno výše, podporováno stávajícím binárním ovladačem), tak by nám nezbývalo než implementovat jiný open source mechanismus pro alokaci bufferů pro Tegru, který by mohl být používán mezi oběma ovladači, nebo nadále používat stávající kód nvhost. Toto, stejně jako verze pro každý jiný SoC, je právě tím, co měl projekt dma-buf nahradit.
Tehdy téma probrala řada vývojářů na Konferenci o Embedded Linuxu a výsledkem bylo, že EXPORT_SYMBOL() je v tomto případě správnou volbou. Ostatní vývojáři ale proti změně namítali. Nikdy nebylo zveřejněno žádné rozhodnutí, ale výsledek je jasný: symboly dma-buf jsou v současných jádrech stále jen pro moduly pod GPL.
V nedávné době se objevilo významné vylepšení funkčnosti dma-buf v podobě synchronizačního subsystému fence. „fence“ je primitivní objekt indikující, zda byla operace nad dma-buf dokončena, nebo ne. Ve výše popsaném případě by ovladač kamery mohl například signalizovat grafickému ovladači, kdy buffer obsahuje nový snímek videa.
Smyslem subsystému fence bylo nahradit kód specifický pro Android (nazvaný „Sync“), který má podobnou funkčnost. Jestli se to povede, není jisté; vypadá to, že vývojáři Androidu ještě neřekli, jestli fence budou moci použít, navíc zjevně nemá všechnu potřebnou funkčnost. Je tu ale ještě i další možná překážka: exporty jen pod GPL.
Současný kód fence EXPORT_SYMBOL_GPL() nepoužívá; chová se v tomto ohledu stejně jako ovladač Sync (který je ve staging). Při revidování kódu Greg Kroah-Hartman požádal o to, aby exporty byly změněny na GPL, protože zbytek ovladače to tak má. To se nelíbilo Robu Clarkovi, který na to řekl:
Tohle už jsme jednou řešili u dma-buf. Takhle postoj zlého výrobce ohledně ne-GPL modulů nezměníme. Jediným výsledkem bude neohrabané složité řešení (neboli používání syncpt EXPORT_SYMBOL() nad EXPORT_SYMBOL_GPL() ve fence) jako obezlička, ze které nebude mít radost nikdo.
(„syncpt“ je obdoba fence od NVIDIA.)
Greg ale trval na svém a tvrdil, že exporty jen pod GPL hrály klíčovou roli v přesvědčování firem v minulosti. Správce grafického subsystému Dave Airlie, který před pár lety hodně nadával na proprietární grafické moduly, tentokrát ale nesouhlasil, protože podle něj to mělo za výsledek jen to, že firmy tlačí jedna na druhou. V tomto případě je pro to nechat to na autorovi.
Dave dále psal na téma situace okolo exportů jen pod GPL obecně:
Osobně si myslím, že _GPL je z principu špatně a že původní Linusův plán byl natolik zkreslen všelijakými skupinami lobbistů, co u každého symbolu žádají, aby byl _GPL, že to už ztratilo smysl. Navíc se mi nelíbí to, že se tito lobbisté prostě nejdou soudit.
Tato poslední věta je možná ta nejdůležitější. Po celé roky jaderná komunita vyhrožuje kvůli proprietárním jaderným modulům, ale nesnaží se situaci moc změnit. Proto výrobci nadále dodávají moduly, aniž by se báli odvety. Je evidentní, že komunita tyto moduly toleruje, bez ohledu na (mnohdy hlasitá) prohlášení o možných právních rizicích, která se s nimi pojí.
Dokonce i obcházení omezení EXPORT_SYMBOL_GPL() je zdá se tolerováno; vývojáři si (někdy) hlasitě postěžují, ale to je tak všechno. Proto není překvapením, že firmám dochází, že si ze svých binárních modulů nemusejí dělat hlavu.
Proto není moc jasné, jestli EXPORT_SYMBOL_GPL() něčemu pomáhá. Vypadá to spíš jako takový příčný práh, který komplikuje život firmám, jež dodávají binární moduly. Export jen pod GPL umožňuje vývojářům vyjádřit své pocity a někdy může někoho zpomalit, ale nezdá se, že by se situace kvůli tomu někam posouvala. Patche pro fences jsou určené hlavně pro embedded systémy, kde jsou proprietární grafické ovladače bohužel stále normální záležitostí. I kdyby rozhraní bylo jen pro GPL moduly, moc by se asi nezměnilo.
Možná by se dalo říci, že EXPORT_SYMBOL_GPL() je typickou ukázkou pokusu o technické řešení společenského problému. Pokud proprietární moduly opravdu porušují práva jaderných vývojářů, pak se dříve či později budou tito vývojáři muset za svá práva postavit. Jedinou jinou alternativou je pak svět, kde se proprietární moduly distribuují za tichého souhlasu jaderné komunity, bez ohledu na počet symbolů pod EXPORT_SYMBOL_GPL().
Stejně jako v případě dma-buf se nedošlo k žádnému rozhodnutí ohledně toho, jak by se měly symboly ze subsystému fence exportovat. Greg ale řekl, že v této otázce nehodlá ustupovat a jako správce, který by obvykle tento patch přijímal, má dost silné postavení na to, aby svůj postoj obhájil. Na to, abychom se dozvěděli, jak to bude, si asi budeme muset počkat na začlenění zmiňovaného kódu. I tak ale vývojáři čím dál více přemýšlejí nad tím, jestli na tom vlastně záleží.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.