Portál AbcLinuxu, 27. května 2024 10:36
Aktuální verze jádra: 2.6.21. Citáty týdne: Linus Torvalds, Andrew Morton. Nabídka práce: manažer chyb jádra. Začleněno (a chystá se) do 2.6.22. UIO: ovladače v uživatelském prostoru. Podpora velkých bloků.
V tuto chvíli (2. 5. 2007) není připravena žádná předverze. Strom je otevřen pro začleňování patchů do 2.6.22 a zatím jich bylo více než 2000 (vizte níže).
Aktuální verze -mm stromu je 2.6.21-rc7-mm2. V poslední době nepřibývalo moc nových funkcí; pozornost je věnována opravování chyb.
Aktuální stabilní jádro je 2.6.21, vydané 25. dubna. Pokud jste dění příliš nesledovali, tak vězte, že 2.6.21 obsahuje clockevents a dynamický čas, virtualizační rozhraní VMI, několik vylepšení KVM, vrstvu ALSA system on chip a mnoho dalších věcí. Velké množství podrobností najdete také ve shrnutí na stránce KernelNewbies 2.6.21.
Aktualizace 2.6.21.1 přidala pár oprav bezpečnostních problémů v síťovacím kódu.
Starší jádra: aktuální revize 2.6.20 je 2.6.20.11, vydaná 1. května. Obsahuje několik desítek důležitých oprav, předcházející aktualizace opravovaly bezpečnostní problémy v síťovacím kódu.
2.6.16.50-rc1 vyšlo také 1. května a je v něm několik oprav, z nich dvě mají CVE číslo.
Strom -mm je tedy i nadále velmi užitečný právě proto, že jej *Andrew* testuje a objevuje v něm spousty problémů. Ale mám podezření, že většinu toho dělá Andrew sám, což je trochu škoda - měli bychom se naučit tu práci více rozdělit. Andrew je navíc až příliš mírný, když se něco pokazí.
Celková stabilita nedávných -mm nebyla dost vysoká a už nemáme čas všechny chyby objevit. Minulý týden jsem neměl všechny ty patche začleňovat - byla v nich hromada zmetků. To znamená, že se do hlavního jádra pravděpodobně dostane více chyb než obyčejně, a budeme je muset opravit až tam.
Během debaty o řešení chyb v jádře Andrew Morton zmínil, že je už nabízena pozice manažera chyb jádra, kterou bude financovat Google. Zjevně je dost těžké na ni někoho najít: Shánění kandidátů je bohužel trochu komplikované - není to běžná práce; jde o mix úředničiny, politiky, sociálního inženýrství a programování. Lidé, kteří by měli znalosti ve všech těchto oblastech, se těžko hledají. Pokud odpovídáte popisu, mohla by to být skvělá příležitost k získání zkušeností s jádrem, přičemž byste pracovali přímo s Andrewem - a zároveň pomáhali vývoji jádra.
Období pro začleňování patchů do 2.6.22 začalo a doposud se do jádra dostalo více než 2000 změn. Teď se tempo trochu zpomalilo, což mohlo být způsobeno tak vysokým provozem na LKML (i podle měřítek této konference), že už nikdo neměl čas se patchům věnovat. Ať je to jak chce, mezi prozatím zařazené změny, které uvidí i uživatelé, patří:
Nové ovladače pro USB webkamery založené na čipsetech zr364xx, dataflash zařízení AT26Fxxx, NAND flash paměti založené na CM-X270, řadiče Freescale SOC USB a adaptéry Marvell Libertas 802.11 (používané v OLPC).
Stojí také za zmínku, že byl konečně začleněn IVTV video ovladač, který byl dlouhou dobu udržován mimo hlavní jádro. Aby bylo možné to nakonec začlenit do jádra, potřebovali jsme tři vývojáře jádra, více než čtyři roky práce, osm nových i2c modulů, jedenáct nových V4L2 ioctl, tři nové DVB video ioctl, sliced VBI API, nové API pro MPEG encoder, vylepšení API pro DVB video MPEG dekódování, velké přispění v oblasti YUV/OSD od Iana a Johna, podporu webu/wiki/svn/trac od Axela Thimma, (hardwarovou) podporu od Hauppauge, podporu a pomoc od vývojářů v4l-dvb a mnoha a mnoha uživatelů ivtv.
Změny, kterých si všimnou vývojáři jádra:
Pokud jste zvědaví, co ještě by se mohlo do 2.6.22 dostat, podívejte se na Andrewovy plány. Zajímavé je, že Lguest, práce na signalfd a SLUBalokátor byly původně určeny k začlenění, ale už to není tak jisté:
Je ještě pár zajímavých věcí, které na Andrewově seznamu nejsou. Souborový systém reiser4 s největší pravděpodobností prosedí ještě (alespoň) jeden vývojový cyklus, i když je teď zase zvýšený zájem o úpravu do podoby vhodné k začlenění. O Xenu se také nemluví, ačkoliv to vypadá, že se na něm v zákulisí pracuje. Mohl by se tedy objevit ještě před koncem období pro začleňování. V 2.6.22 nebude žádná velká změna plánovače; na všechny ty patche je ještě příliš brzy. Antifragmentační patche si asi také ještě budou muset počkat; Andrew se obává, že ještě, navzdory mnoha verzím za několik let, nebyly dostatečně zkontrolovány a otestovány. Patche pro správu integrity jsou také považovány za nedostatečně připravené a začleněny nebudou.
Kromě toho však určitě příští týden dojde na nějaké překvapení.
O konceptu podpory ovladačů pro uživatelský prostor se už mluvilo vícekrát. Teď je to tu zase; tentokrát je nová verze patche (nyní nazýván "UIO") navrhována k začlenění do 2.6.22. Rozhraní se trochu změnilo, takže stojí zato se na něj podívat.
Podobně jako předchozí verze, ani UIO neodstraňuje jaderný kód úplně. Pro přípravu zařízení je potřeba malý modul, který například poskytne rozhraní k PCI sběrnici a zaregistruje obsluhu přerušení [interrupt handler]. Ta poslední věc (obsluha přerušení) je zvláště důležitá; v uživatelském prostředí toho lze udělat dost, ale v jádře musí být obsluha přerušení, která ví, jak zařízení říct, že se má přestat dožadovat pozornosti.
Jaderný modul includuje <linux/uio_driver.h>. Jedná-li se o PCI zařízení, měl by se zaregistrovat coby PCI ovladač jako obvykle. Když přijde čas na připojení zařízení (třeba v PCI funkci probe()), vyplní ovladač strukturu uio_info:
struct uio_info {
char *name;
char *version;
struct uio_mem mem[MAX_UIO_MAPS];
long irq;
unsigned long irq_flags;
void *priv;
irqreturn_t (*handler)(int irq, struct uio_info *dev_info);
int (*mmap)(struct uio_info *info, struct vm_area_struct *vma);
int (*open)(struct uio_info *info, struct inode *inode);
int (*release)(struct uio_info *info, struct inode *inode);
/* Interní věci vynechány */
};
name je název zařízení a version je verze ovladače (která se ukáže v sysfs). Číslo přerušení, které zařízení používá (je-li nějaké) jde do irq, přičemž irq_flags jsou příznaky, které budou předány funkci request_irq(). Funkce, která přerušení obsluhuje, je handler(). Tato obsluha by měla dát najevo, že o přerušení ví; nic jiného obvykle dělat nemusí. Funkce mmap(), open() a release() jsou volány z ekvivalentních členů file_operations.
Pole mem popisuje všechny paměťové oblasti, které mohou být namapovány do uživatelského prostoru. Struktura uio_mem vypadá takto:
struct uio_mem {
unsigned long addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
/* ... */
};
addr je příslušná adresa pro každou mapovatelnou oblast a size je její velikost. Pokud jde o I/O paměťovou oblast, vrací ioremap() adresu internal_addr. Pole memtype popisuje, co je ta oblast vlastně zač:
Jakmile je struktura vyplněna, miniovladač [driver stub] ji předá:
int uio_register_device(struct device *parent, struct uio_info *info);
Ukazatel parent jádru říká, které "opravdové" zařízení, je s UIO zařízením spojeno; je-li ovladač pro PCI zařízení, parent bude pci_dev->dev.
Jaderné API UIO už toho moc dalšího neobsahuje. Když zařízení zmizí, měl by ovladač zavolat:
void uio_unregister_device(struct uio_info *info);
Poslední funkce, která stojí za zmínku, je:
void uio_event_notify(struct uio_info *info);
Jejím účelem je dát UIO jádru vědět, že se stala nějaká událost (obyčejně přerušení). Miniovladač nemusí při skutečných přerušeních uio_event_notify() volat, ale je možné to použít pro simulaci přerušení v jiných situacích.
Na straně uživatelského prostoru se první zařízení ovládané přes UIO objeví jako /dev/uio0 (za předpokladu normálního nastavení udev). Uživatelský ovladač zařízení otevře. Čtení vrací hodnotu int, což je počet událostí (přerušení), které zařízení vidí; pokud od posledního čtení nedojde k žádnému přerušení, zablokuje se operace až do chvíle, kdy se nějaké přerušení stane (běžným způsobem je však podporován i provoz bez blokování). Popisovač souboru může být předán funkci poll().
Paměťové oblasti popisované jaderným ovladačem mohou být do uživatelského prostoru mapovány voláním mmap(). To rozhraní je však trošku podivné: hodnota offset předaná mmap() by měla být Nkrát velikost stránky Nté paměťové oblasti. Takže na systému se stránkami o 4096 bajtech se bude první paměťové oblast nacházet na offsetu nula, druhá na 4096, třetí na 8192 atd. Jakmile na tohle přijdete, už je všechno jednoduché.
Má to samozřejmě určitá omezení. UIO ovladače jsou znakové ovladače; v tuto chvíli neexistuje způsob, jak vytvořit v uživatelském prostoru blokové nebo síťové ovladače. Z uživatelského prostoru není možné vyvolat DMA operace. Ale pro ovladače, které lze implementovat s I/O přístupem do paměti a jednoduchými obsluhami přerušení, je potřebná podpora hotova. Sada patchů obsahuje ukázkový ovladač, který má předvést, jak to všechno funguje. Thomas Gleixner říká, že původní, jaderná verze ovladače musela implementovat 60 různých ioctl() příkazů a byla větší než 5000 řádků. Doprovodný kód v uživatelském prostoru měl přes 3000 řádků. Nový ovladač to vše dává pryč: jaderného kódu je celkem 156 řádků a v uživatelském prostoru jich je těsně pod 3000.
Andrew Morton vyjádřil vůči patchům jistou zdrženlivost:
Abych pravdu řekl, tak si celým tím UIO nápadem nejsem moc jistý. Mám matné tušení, že bychom raději měli lidi přesvědčovat k přesunu věcí do GPL jádra, než je abych je povzbuzovali k psaní uzavřených implementací pro uživatelský prostor, které budou nakonec pravděpodobně pomalejší, méně spolehlivé a nedostupné na různých architekturách, distrech atd.
Autoři reagovali s tím, že nejde o vytváření proprietárních vladačů, i když některé by určitě byly. Je dost lidí, obzvláště z embedded oblasti, kteří by ovladače v uživatelském prostoru chtěli - když už pro nic jiného, tak alespoň k prototypování. Systém UIO jim poskytuje relativné bezpečný a standardní způsob, jak takové ovladače psát, což je považováno za lepší cestu než vytváření vlastních jaderných háčků [hooks] pro každý z nich. Patch zatím začleněn nebyl, ale pokud se neobjeví vážnější připomínky, má dobrou šanci se do 2.6.22 dostat.
Na první pohled to nevypadá, že by měl být patch přidávající podporu velkých bloků od Christopha Lametera tak kontroverzní. Patch zařídí, že stránková keš dokáže držet větší bloky než je systémová velikost stránek, protože je ukládá ve složených [compound] stránkách vyššího řádu [high-order]. A to umožňuje práci s většími bloky souborovým systémům. Patch by měl zefektivnit operace s velkými soubory a vylepšit jadernou podporu některých druhů hardwaru. Přestože možná nakonec dojde k začlenění, ještě je třeba toho hodně prodiskutovat.
Potíž je v tom, že patch přináší určité problémy. Komplikuje jádro subsystému virtuální paměti kvůli implementaci vlastnosti, která je vlastně totožná s něčím, co už bylo dříve zamítnuto: větší stránky. Navíc se vyhýbá nejsložitější části problému - zpracovávání výpadků větších stránek, což je potřeba kvůli zprovoznění mmap() - takže lze do budoucna očekávat ještě složitější kód. Větší bloky ve stránkové keši znamenají větší poptávku po stránkách vyššího řádu, kterých je už takhle na některých systémech nedostatek; a to bude znamenat, že by téměř jistě byly potřeba i antifragmentační patche. Využívání větších stránek ve stránkové keši může navíc vést k interní fragmentaci a méně efektivnímu využívání paměti.
Andrew Morton tedy vyjádřil určité pochyby:
A aby bylo jasno: ta druhá nevýhoda je obrovská. Protože pokud ten hack (sorry, ale _je_ to hack) s PAGE_CACHE_SIZE provedeme, budeme ho tam mít *napořád*. Správa a vylepšování MM a VFS bude obtížnější a náročnější a pomalejší a bugovitější už *navždy*. Lidem bude trvat déle, než správě paměti porozumějí. Okruh vývojářů se zúží a ubyde talentu.
Andrew ten patch přímo nezavrhuje, ale nerad by, aby byl začleněn, dokud nebyl pečlivě porovnán s alternativami. Doporučuje neměnit velikost položek ve stránkové keši a přitom se pokusit alokovat položky ve skupinách vyššího řádu. Výsledkem by bylo souvislé ukládání větších bloků bez změn v paměťovém subsystému. Souborové systémy by mohly využívat větší bloky a hardware by se k nim mohl chovat jako k samostatným jednotkám v scatter/gather [rozhodit/posbírat] seznamech pro DMA, což by vedlo k efektivnějšímu provozu.
Další navrhovanou možností je zvýšení maximální velikosti hardwarových scatter/gather seznamů nebo umožnění jejich zřetězení. Ovladače by pak mohly provádět větší I/O operace, takže by se zlepšila efektivita bez jakýchkoliv dalších změn.
Přesto má Christophův patch podporu. Umožnil by nižším vrstvám relativně jednoduchou podporu větších bloků a třeba dopomohl k odstranění několika skutečných hacků v některých ovladačích a souborových systémech. Také by šlo mountovat ext3 s většími bloky - někdy vytvářené na ia64 systémech, které používají větší stránky - na dalších architekturách. Christophu Hellwigovi se líbí, že by stránková keš vyššího řádu mohla vynutit řešení dlouhotrvajícího problému s fragmentací fyzické paměti. Mnoha lidem to připadá jako přímočaré a nezbytné řešení.
Takže větší bloky patrně jen tak nezmizí. Může však chvilku trvat, než jejich proponenti provedou dostatek výkonnostních testů, které by plně odpověděly na vyjádřené obavy. Zásadním změnám často trvá cesta do jádra nejdéle, takže na tom není nic překvapivého. Jen se neptejte, jak to nakonec dopadne.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.