Portál AbcLinuxu, 16. května 2024 20:28
Aktuální verze jádra: 2.6.19-rc1. Citát týdne: David Woodhouse. Odstranění populate(), nopfn() a nopage(). Video4Linux2 API: úvod. Budoucnost vývoje ReiserFS.
Aktuální předverze je 2.6.19-rc1, vydaná 4. října. Shrnutí změn najdete v článcích Začíná vývojový cyklus 2.6.19 a Další věci pro 2.6.19 z posledních dvou týdnů. To hlavní: ovladače pro paralelní ATA, labeled networking [značené síťování] pro IPsec a CIPSO a několik nových architektur, množství nových ovladačů, clusterový souborový systém GFS2, eCryptfs a spousta interních změn.
Dlouhý changelog obsahuje podrobnosti - ale protože se jedná o téměř 5000 patchů od více než 600 lidí, je lepší mít na to hodně volného času. Krátký changelog je trochu stručnější, ale přesto dost dlouhý.
V tuto chvíli by už měly být do hlavního repozitáře začleňovány pouze opravy. Hodně patchů opravy jsou, ale Linus přidal i několik významných změn. Podle očekávání tak byla začleněna změna prototypu zpracovávače přerušení, což ovlivnilo celý strom. Konečně byl odstraněn zasloužilý, leč dlouho nepoužívaný soubor <linux/config.h>.
Přidán byl také vývojový souborový systém ext4, který obsahuje mnohá vylepšení, včetně podpory rozsahů a 48bitových čísel bloků. Vizte soubor s dokumentací ext4, pokud si s ext4 chcete hrát (a máte dobré zálohy).
Aktuální verze -mm stromu je 2.6.19-rc1-mm1. Mezi nedávné změny patří přidání ext4 (který se hned přesunul do hlavního jádra), pokračující práce na mechanismu "swap token", obecná implementace log2() a patch s dynamickým "tikem" (vizte také API pro určení limitu latence).
Spravování ovladačů mimo hlavní jádro je i během těch světlejších chvilek bezostyšné sebemrskačství. Ale opravdu je nám to jedno -- kdybychom jim neztěžovali život takhle, akorát by si začali píchat špendlíky pod nehty, aby si ten nedostatek bolesti vynahradili. Když se nad tím trochu zamyslíte, tak jim vlastně pomáháme -- takhle si aspoň neublíží.
VMA operace nopfn() byla přidána do 2.6.19-rc1; vizte článek z minulého měsíce: nopage() a nopfn(). Ukazuje se však, že nopfn() bude možná z těch rozšíření API, které v jádře vydrží jen rekordně krátkou dobu; Nick Piggin poslal sadu patchů, které přinášejí výrazné změny v zacházení s výpadky stránek na nejnižších úrovních.
Struktura vm_operations_struct v 2.6.19-rc1 definuje tři metody, které se o nízkoúrovňové stránkování starají:
struct page *(*nopage)(struct vm_area_struct *area,
unsigned long address, int *type);
unsigned long (*nopfn)(struct vm_area_struct *area,
unsigned long address);
int (*populate)(struct vm_area_struct *area, unsigned long address,
unsigned long len, pgprot_t prot,
unsigned long pgoff, int nonblock);
Obyčejně jsou výpadky stránek řešeny pomocí nopfn() (existuje-li) nebo nopage(). Tyto funkce by měly vzít danou address a přiřadit ji ke stránce ve fyzické paměti. U oblastí virtuální paměti (VMA), které mají zálohu v souborech, reaguje vrstva souborového systému na volání nopage() alokováním stránky paměti a načtením příslušného obsahu ze zálohy. Stránka je pak předána zpět jádru, aby byla začleněna do tabulky stránek. Ovladače zařízení, které nopage() implementují, obvykle pouze přeloží address do příslušného ukazatele bufferu v paměti, který je mapován do uživatelského prostředí.
nopfn() i nopage() předpokládají, že je mapování mezi adresami virtuální paměti a offsetem v rámci VMA lineární - proto je jako parametr poskytována pouze adresa. Jádro však podporuje také nelineární mapování; v takovém případě může aplikace změnit VMA na komplexní okno do jiných částí zálohového souboru. nopfn() a nopage() tato mapování nezvládají, protože nemají potřebné informace. Místo toho musí každá záloha, která podporuje nelineární mapování, poskytnout metodu populate(), která má parametry jak pro address virtuální paměti, tak přiřazený offset (pgoff) do zálohového zařízení.
Na scénu vstupuje Nick, který pracoval na záludném problému v jedné z tradičně nejzáludnějších částí jádra: kódu, který se stará o zkracování souborů. V některých případech mohla být stránka, která byla odstraňována na základě volání truncate(), zároveň zpracována pomocí nopage(), což vedlo ke zmatkům ve správě paměti. Když Nick přemýšlel nad zamykacími pravidly pro tyto operace, uvědomil si, že musí existovat lepší způsob. Výsledkem je nová VMA operace nazývaná fault():
struct fault_data {
struct vm_area_struct *vma;
unsigned long address;
pgoff_t pgoff;
unsigned int flags;
int type;
};
struct page *(*fault)(struct vm_area_struct *vma,
struct fault_data *fdata);
Tato metoda má nahradit nopfn(), nopage() a populate(). Dojde-li k výpadku stránky, naplní jádro strukturu fault_data potřebnými informacemi: address přiřazená k výpadku v uživatelském prostoru, odpovídající offset pgoff a dva příznaky, které značí, jestli k výpadku došlo při zápisu, nebo jde o nelineární mapování.
Funkce fault() by měla najít stránku, která může uspokojit požadavek na offset pgoff; obyčejně nebude address vůbec potřebovat. Funkce může buď vrátit přiřazenou struct page, nebo nastavit záznam v tabulce stránek přímo (pomocí něčeho jako vm_insert_page()) a vrátit NULL. Ať tak nebo tak, pole type by mělo být nastaveno podle druhu výpadku (major nebo minor). Pokud výpadek není možné zpracovat, měl by být do type vložen příslušný chybový kód.
Nickův patch se hned zbavuje metod nopfn() a populate(). V současné době se nopfn() používá na jediném místě a starší API populate() nebylo nikdy mimo hlavní jádro příliš rozšířeno. Funkce install_page() je také určena k brzkému odstranění. Metoda nopage() je však často používána v ovladačích zařízení - uvnitř i vně jádra. Proto byla označena jako zastaralá a její odstranění je naplánováno na říjen příštího roku. Objevily se návrhy na dřívější odstranění nopage() (dejme tomu za půl roku), ale žádné definitivní rozhodnutí nepadlo.
Až na tyto drobnosti to vypadá, že má tato změna všeobecnou podporu. Pro 2.6.19 jsou patche přeci jen trochu moc čerstvé, takže se v hlavním jádře pravděpodobně objeví nejdříve v 2.6.20. Ale v tu chvíli budou muset správci a autoři ovladačů provést aktualizaci svého kódu.
Jonathan Corbet: nedávno jsem psal ovladač pro kameru - konkrétně tu, která bude dodávána v systému One Laptop Per Child. Ovladač používá jaderné API, které je pro podobné účely určené: Video4Linux2 API. Při psaní tohoto ovladače jsem zjistil něco vskutku šokujícího - toto API není zrovna dobře dokumentováno. I když uživatelská strana má dokumentaci docela dobrou. Ve snaze o nápravu této situace bude v následujících měsících LWN vydávat sérii článků, které popisují, jak pro rozhraní V4L2 psát ovladače.
V4L2 má dlouhou historii - první jiskřička se v očích Bill Dirkse rozsvítila v srpnu roku 1998. Vývoj pokračoval dlouhé roky, až bylo V4L2 API konečně zařazeno do hlavního jádra v listopadu 2002 při vydání 2.5.46. Dodnes však novější API mnohé ovladače nepodporují; konverze pořád probíhá. Mezitím se V4L2 vyvíjí, přičemž do 2.6.18 šly docela zásadní změny. Aplikací, které by fungovaly s V4L2, moc není.
V4L2 je navrženo pro podporu nejrůznějších zařízení, z nichž jen některé jsou skutečně "video":
Jsou možné i jiné druhy zařízení. V4L2 API má náznaky zařízení "codec" a "effect", která obě provádějí transformace proudů video dat. Tyto oblasti však ještě nebyly kompletně specifikovány - a o to méně implementovány. Ve starším V4L1 API také existují rozhraní "teletext" a "radio data system"; nebyly však přesunuty do V4L2 a nevypadá to, že by se to někdy v dohledné době chystalo.
Video zařízení se od mnohých jiných liší tím, jak hodně je lze konfigurovat. V důsledku toho implementuje většina ovladače V4L2 kód, který aplikacím umožní objevit možnosti daného zařízení a nakonfigurovat jej tak, aby fungovalo podle představ. V4L2 API definuje několik desítek zpětných volání pro konfigurační parametry jako frekvence tuneru, okna a ořezávání, počet snímků, video komprimace, video formáty atd. Značná část tohoto seriálu se bude věnovat právě konfiguračnímu procesu.
Pak je tu ještě ten drobný zádrhel, že je nutno provádět efektivní I/O v dané kvalitě videa. V4L2 API definuje tři různé způsoby přenosu video dat mezi uživatelským rozhraním a zařízením, z nichž některé jsou dosti komplexní. O video I/O a vrstvě video-buf, která je připravena pro provádění běžných úkolů, budou samostatné články.
Následující obsah je © KernelTrap
Protože byl Hans Reiser, zakladatel firmy Namesys, nedávno zatčen jako hlavní podezřelý v případu zmizení své manželky, zabývala se krátká diskuze na LKML budoucností ReiserFS. Alan Cox poukázal na to, že reiserfs je psán týmem lidí v Namesys a v případě reiserfs3 také lidmi ze SuSE i odjinud.
Alexander Lyamin, který je na stránkách Namesys uveden jako "hostmaster a sysadmin", připojil, že tým je v tuto chvíli dost otřesen a nervózní. Potvrdil, že ReiserFS 3.6 je v udržovacím režimu, a pak pokračoval o Reiser4: Díky Andrew Mortonovi pořád provádíme revize. Vydáváme patche, opravujeme problémy a vůbec se snažíme vše pročistit. Takový je plán na dalšího alespoň půl roku. Ohledně budoucnosti poznamenal, že závisí na výsledku soudu: Pokud to dopadne tak, jak doufáme, bude to v pořádku. Pokud to dopadne špatně, pak to bude složité. Pokusili bychom se jmenovat prostředníka, který by spravoval obchody Namesys.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.