Portál AbcLinuxu, 9. května 2024 01:54
Aktuální verze jádra: 3.1-rc2. Citáty týdne: Ingo Molnar, Brian Swetland. Možné změny v dlouhodobé údržbě jader. Sdílení bufferů mezi zařízeními.
Aktuální verze jádra je 3.1-rc2, vydaná 14. srpna. No, pěkně klidný první týden po začleňovacím okně. Dobrá práce. Nebo jsou lidé prostě líní a každý je na dovolené. To je fuk. Nic mi neříkejte. Mám docela radost a byl bych rád, kdyby to tak zůstalo. Podrobnosti můžete najít v kompletním seznamu změn. Kódové označení tohoto jádra bylo jen tak mimochodem změněno na „mokrý tuleň“.
Stabilní aktualizace: verze 2.6.32.45, 2.6.33.18 a 3.0.2 byly vydány 15. srpna. Obsahují obvyklou hromadu oprav. Všechny tři aktualizace také zahrnují změnu generování sekvenčních čísel v TCP; (poměrně) málo bezpečný 24bitový algoritmus MD4 byl nahrazen 32bitovým MD5. Verze 3.0.3 byla vydána 17. srpna s další sadou užitečných oprav.
Pravdou, kterou si musíme uvědomit, je to, že jsme se opravdu zdokonalili v ničení naší uživatelské základny, a to přibližně jednou ročně.
-- Ingo Molnar
Co se jader s dlouhou údržbou týče, z pohledu Androidu dáváme přednost brát si při vydání každé platformy/zařízení tu nejčerstvější verzi. Dávám přednost tomu mít co nejaktuálnější dávku oprav a nových funkcí z hlavní řady a minimalizovat tak balík patchů na naší straně, co to jen jde.
Greg Kroah-Hartman zaslal návrh na změny v tom, jak budou jádra stabilní a (především) ta s dlouhou údržbou spravována. Změny jsou spíše na popud uživatelů než komerčních distributorů. Teď, když má jádro 2.6.32 věk přes rok a půl a komerční distribuce se věnují svým několikaletým aktualizačním cyklům, není ze strany distribucí žádný tlak na nové jádro s dlouhodobou údržbou. Ale ukazuje se, že distribuce nejsou jediní uživatelé jádra, během uplynulého roku mě oslovila řada dalších skupin a společností a ptali se, jak by mohli zvolit další jádro s dlouhodobou údržbou nebo jaký je vlastně proces tohoto výběru. Smyslem je zvolit nové jádro s dlouhodobou údržbou jednou za rok; toto jádro by následně bylo udržováno po dva roky. Nějaká ta diskuze kolem toho probíhá na Google+; kolem 15. srpna se to pak mělo přesunout na mailing list.
CPU se v posledních letech možná neuvěřitelně zrychlila, ale zlepšila se i v jiných směrech; typické zařízení typu system-on-chip (SoC) má řadu periferních zařízení, která by se mohla kvalifikovat jako výkonná CPU sama o sobě. Výkonnější zařízení s přímým přístupem na paměťový řadič mohou převzít náročnější úkoly. Například snímek z kamery může být mnohdy přenesen přímo do grafického procesoru pro zobrazení, aniž by muselo probíhat zpracovávání v uživatelském prostoru, jak tomu bývalo. Čím dál tím více vypadá práce CPU jako práce předáka v obchodě, jehož hlavním úkolem je, aby ostatní procesory byly zaneprázdněné.
Práce předáka bude snazší, pokud budou růzonorodá zařízení moci mezi sebou snadno komunikovat sama o sobě. Užitečným vylepšením v této oblasti by mohla být sada změn pro sdílení bufferů, kterou nedávno zaslal Marek Szyprowski. Myšlenkou je umožnit, aby pod řízením uživatelského prostoru mohlo více subsystémů jádra sdílet buffery. S takovou funkcí by aplikace mohly spájet subsystémy jádra dohromady způsobem specifickým pro daný problém a následně jít z cesty a nechat zúčastněná zařízení zpracovávat data.
Je zde (alespoň) několik výzev, kterým je nutno čelit, aby bylo bezpečné aplikacím vystavovat takovou funkčnost. První je to, že by aplikace neměla být schopna „vytvořit“ buffery na adrese v jádře dle své volby. Adresy z jaderného prostoru by samosebou neměly být vůbec uživatelskému prostoru viditelné, takže jádro musí nabídnout nějaký jiný způsob, jak se budou aplikace moci odkazovat na konkrétní buffer. Druhou je pak to, že sdílené buffery nesmí být zrušeny, dokud s nimi někdo pracuje. Buffer může být vytvořen ovladačem specifickým pro nějaké zařízení, ale musí být zachován, i když je zařízení uzavřeno, dokud je zde někdo, kdo jeho existenci předpokládá.
Mechanismus přidávaný touto sadou změn (tato konkrétní část je dílem Tomasze Stanislawského) je vcelku prostý – ačkoliv se v budoucnu pravděpodobně zesložití. Jaderný kód, který chce zpřístupnit buffer jiným částem jádra přes uživatelský prostor, vyplní jednu takovouto strukturu:
struct shrbuf {
void (*get)(struct shrbuf *);
void (*put)(struct shrbuf *);
unsigned long dma_addr;
unsigned long size;
};
Člověka hned napadne řada stížností na podobu této struktury: adresa by měla být dma_addr_t, není důvod, proč tam nedat virtuální jadernou adresu, jsou povoleny pouze fyzicky souvislé buffery apod. Také se zdá, že by tam mohla být hodnota označující stav bufferu (kupříkladu zaplněný, nebo prázdný) a také by možná mohla dát jinému vláknu vědět, jakmile se stav změní. Ale je nutné mít na paměti, že toto čistě slouží jako podložení myšlenky [proof-of-concept] a mnoho věcí se změní. Zejména je v plánu předávat seznam různě rozmístěných adres namísto jediné fyzické adresy.
Funkce get() a put() jsou důležité: spravují počet referencí [odkazů] na buffer, který musí existovat, dokud se tento počet nedostane na nulu. Jakýkoliv subsystém, který závisí na pokračující existenci bufferu, by měl držet na takový buffer referenci. Funkce put() by měla uvolnit buffer, jakmile je poslední reference zrušena.
V moment, kdy tato struktura existuje, je možné ji předat funkci:
int shrbuf_export(struct shrbuf *sb);
Pokud vše dobře dopadne, návratovou hodnotou bude číslo popisovače, které lze předat do uživatelského prostoru. Popisovač zosobňuje referenci na buffer, která nebude zrušena, dokud nebude uzavřen popisovač. Vyjma uzavření není moc dalších věcí, které může aplikace s popisovačem dělat, leda tak jej předat jinému subsystému v jádře; kupříkladu snahy o čtení nebo zápis na tomto popisovači selžou.
Když subsystém jádra obdrží popisovač, který má představovat jaderný buffer, může takový popisovač předat následující funkci:
struct shrbuf *shrbuf_import(int fd);
Návratovou hodnotou bude ta samá struktura shrbuf (nebo ERR_PTR(), pokud je popisovač nesprávného typu). Struktuře je před vrácením přidána reference, takže příjemce by měl nekdy v budoucnu pro uvolnění zavolat put().
Sada změn obsahuje nový příkaz ioctl() (VIDIOC_EXPBUF) pro Video4Linux2, který umožňuje export bufferů jako popisovače; pár ovladačů záchytných zařízení bylo vylepšeno, aby podporovaly tuto funkčnost. Zatím ještě nebyly zaslány příklady z druhé strany (která přijímá buffer).
K této sadě změn ještě nepřišlo mnoho komentářů, možná je to tím, že byla zaslána na řadu poněkud nezvyklých mailing listů. Nicméně má podobu něčeho, co by mohlo být užitečné více než jen jednomu či dvěma subsystémům. Asi by bylo smysluplné, aby se další iterace, která snad bude mít ještě více z očekávané funkčnosti, těšila širšímu posouzení díky rozeslání na více míst.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.