Portál AbcLinuxu, 22. května 2024 11:28
Aktuální verze jádra: 2.6.20. Citáty týdne: Al Viro, Andrew Morton. Co nové bylo začleněno do jádra. Alternativy fibril.
Aktuální verze řady 2.6 zůstává 2.6.20; (ke 14. 2. 2007) nevyšly žádné předverze 2.6.21. Přesto však do hlavního git repozitáře proudí patche - vizte níže.
Starší jádra: 2.6.16.40 vyšlo 10. února a obsahuje poměrně malé množství patchů.
K dispozici je první předverze 2.4.35; obsahuje několik patchů a port síťového ovladače "sky2" z řady 2.6.
Promiňte, ale nemohli byste si prosím vás přestat jádro plést se soutěží ve vogonské poezii?
-- Al Viro
Ve složce konceptů mám email, ve kterém říkám, že už nebudu přijímat žádné nové funkce, které nebyly veřejně zkontrolovány a někým třetím otestovány. Smyslem by bylo přinutit lidi, aby si navzájem věci více kontrolovali a testovali a méně se zabývali psaním nových věcí. Až budu mít jednou opravdu špatnou náladu, tak ho možná i pošlu.
V tuto chvíli (14. 2. 2007) probíhá začleňování nových věcí. Bylo již zařazeno přes 2300 sad patchů, které provedly změny ve všech částech stromu. Následuje shrnutí toho, co se zatím dostalo do 2.6.21.
Uživatelské změny:
Změny viditelné pro vývojáře jádra:
Některé patche pořád ještě na začlenění čekají, ne o všem už bylo rozhodnuto.
Od vydání minulého článku o fibrilách (Jádro fibriluje) se o té sadě patchů příliš nediskutovalo. Neznamená to však, že by o tuto oblast poklesl zájem; bylo však navrženo pár jiných přřřístupů.
Linus Torvalds se nechal inspirovat k vytvoření vlastního patche s asynchronním systémovým voláním. Nejlépe jej vystihuje slovo jednoduchost: do jádra nepřidává více než 200 řádků kódu (Dokonce jsem přidal komentáře, takže některé z těch řádků ani nejsou kód!"). Funguje takto:
Největší výhodou tohoto patche - kromě jednoduchosti - je prý to, že nepřidává téměř žádnou režii, je-li možné asynchronní volání dokončit bez blokování. Fibrilový patch vždy spouští asynchronní volání v samostatných fibrilách. Linus tvrdí, že všechna asynchronní volání mohou být ve skutečnosti dokončena synchronně bez blokování, takže by byl raději, kdyby to nic nestálo.
Linusův patch má několik nedostatků. Pokud se například asynchronní volání zablokuje, návrat do uživatelského prostoru proběhne v jiném procesu - změna, která by uživatelský prostor asi dost zmátla. V jeden okamžik se může čekat jen na jednu asynchronní operaci. Také neexistuje žádný způsob, jak vyčkat na ukončení asynchronní operace - kromě zjišťťování stavového kódu. Tento patch však nebyl zamýšlen jako kompletní řešení; jako ukázka konceptu je to zajímavé.
Propracovanější přístup nabízí sada patchů syslet od Ingo Molnara. Pomocí sysletů může uživatelský program spouštět systémová volání asynchronně. Kromě toho je však možné natáhnout malé programy do jádra a nechat je běžet samostatně.
Aby mohla aplikace syslety využívat, vyplní jednu z těchto struktur:
struct syslet_uatom {
unsigned long flags;
unsigned long nr;
long *ret_ptr;
struct syslet_uatom *next;
unsigned long *arg_ptr[6];
void *private;
};
nr je číslo systémového volání, které má být spuštěno, arg_ptr uchovává ukazatele na parametry a ret_ptr jádru říká, kam dát finální stavový kód volání. Pole private není jádrem vůbec využíváno. K ostatním polím se dostaneme za chvilku.
Jakmile je připravena struktura syslet_uatom, může aplikace akci spustit pomocí:
long async_exec(struct syslet_uatom *atom);
Toto volání okamžitě spustí požadované systémové volání. Pokud se ani jednou nezablokuje, poběží synchronně a adresu atom vrátí async_exec(). Jinak si jádro vezme jedno z vláken a použije ho k návratu do uživatelského prostoru, přičemž systémové volání bude pokračovat v původním vlákně. Aplikace to pak může pustit a (zatímco se bude dokončovat systémové volání), jít dělat něco jiného - včetně spouštění dalších sysletů.
Co se však doopravdy stane po dokončení systémového volání, to je trochu složitější a zajímavější. Pokud to uživatelský prostor nechce jinak, jádro syslet neukončí po proběhnutí prvního systémového volání; místo toho se podívá na pole next struktury syslet_uatom. Není-li to pole NULL, bude považováno za uživatelskou adresu dalšího sysletu, který má jádro spustit. Jinými slovy, aplikace není omezena na spouštění jednotlivých asynchronních volání; může jich zřetězit celou řadu, která pak poběží, aniž by se opouštělo jádro. Režie při odchycení nového syslet atomu je daleko menší než při přechodu do uživatelského prostoru a zpět, takže pouhým zřetězením dvou systémových volání lze dosáhnout výrazného zlepšení výkonu.
Poslední pole v struct syslet_uatom je flags, které řídí způsob spouštění sysletů. Čtyři z nich (SYSLET_STOP_ON_NONZERO, SYSLET_STOP_ON_ZERO, SYSLET_STOP_ON_NEGATIVE a SYSLET_STOP_ON_NON_POSITIVE) otestují výsledek systémového volání aktuálního atomu a (případně) ukončí provádění sysletu. Tak může být například předčasně ukončena série systémových volání, pokud jedno z nich selže. Je také možné vytvořit v jádře smyčku, která čte soubor, dokud už nezbývají žádná data.
SYSLET_SKIP_TO_NEXT_ON_STOP předchozí příznaky upravuje tak, že místo ukončení sysletu jádro přeskočí na atom, který je v adresním prostoru procesu hned za tím aktuálním. Tento příznak sysletu umožňuje přerušit smyčku a přejít v rámci sysletu dál. Pokud aplikace ví, že se syslet zablokuje, může pomocí SYSLET_ASYNC vyžadovat asynchronní provedení už od začátku. Existuje také příznak SYSLET_SYNC, který způsobí, že vše poběží synchronně.
Syslety nemají žádné vlastní proměnné. Aby pomohl s psaním použitelných programů, přidal Ingo nové systémové volání:
long umem_add(unsigned long *pointer, unsigned long increment);
Toto volání prostě přidá daný increment k *pointer a vrátí výslednou hodnotu.
Aplikace si může zaregistrovat kruhový buffer pomocí systémového volání async_register(). Kdykoliv je atom dokončen, uloží se jeho adresa do další položky kruhového bufferu; aplikace pak může adresu využít, aby vyhledala stav systémového volání. Jádro ale nepřepíše neNULLové položky kruhového bufferu, takže je aplikace musí po zpracování resetovat. Pokud aplikace potřebuje počkat na dokončení sysletu, může zavolat:
long async_wait(unsigned long min_events);
Toto volání proces zablokuje, dokud nebude do kruhového bufferu uloženo alespoň min_events.
I tato sada patchů má několik otazníků. Zpracovávání signálů bylo opět odloženo. Existuje hromada bezpečnostních otázek, které je třeba promyslet; nakonec bude asi asynchronní spouštění několika systémových volání zakázáno. Pořád se ještě nediskutovalo o tom, jak by takové rozhraní spolupracovalo s kevent - o kevents se teď zjevně nikdo nechce bavit. Také 64/32bitová kompatibilita by mohla přinést problémy. A tak dále.
Počáteční reakce se však zdá být celkem pozitivní (i když Linus je velmi proti); syslety by nakonec mohly ukazovat, jak bude vypadat druh fibril, který se dostane do hlavního jádra.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.