Portál AbcLinuxu, 5. května 2025 01:35
Jaderné noviny - 21. 2. 2007
Články
-
Jaderné noviny - 21. 2. 2007
Aktuální verze jádra: 2.6.21-rc1. Další změny v 2.6.21.
API pro správu zdrojů. Nový ovladač pro bezdrátové adaptéry Intel.
Clockevents a dynamický čas.
Obsah
Aktuální verze jádra: 2.6.21-rc1
link
Aktuální předverze řady 2.6 je 2.6.21-rc1 (k 21. 2. 2007), vydaná 20. února: Jako obvykle je v tomto -rc1 hodně změn, ale zatím to vypadá, že 2.6.20 je dobrý základ a nemáme tu nic *doopravdy* děsivého. Mezi významné změny patří dlouho očekávaný patch s dynamickým časem (vizte níže), lepší podpora časovačů s vysokým rozlišením, virtualizační rozhraní VMI (nyní postavené nad paravirt_ops), vrstva ASoC, spousta nových ovladačů a další. Podrobnosti v krátkém a dlouhém changelogu.
Do hlavního git repozitáře si od vydání -rc1 našlo cestu několik set patchů. Většina se týká subsystému Video4Linux; přidávají podporu dálkového ovládání ASUS P7131, ořezávání u BTTV, velkou aktualizaci ovladače pvrusb2 WinTV, nový ovladač MSI Mega Sky 580 a dost dalších věcí.
Aktuální verze -mm stromu je 2.6.20-mm2. Mezi nedávné změny patří podpora Xen DomU, lguest, podpora architektury Blackfin, další úpravy pracovních front, podpora doplňování POSIX listio pro asynchronní I/O, utrace (nový trasovací mechanismus určený k nahrazení ptrace()) patch s kernel markers [jaderné značkovače].
Aktualizace stabilního jádra: 2.6.20.1, 2.6.19.4 a 2.6.18.7 byly všechny vydány 20. února s jediným patchem: opravou DoS zranitelnosti v NFS ACL. V tuto chvíli se připravují rozsáhlejší aktualizace pro 2.6.18 a 2.6.19 (pravděpodobně poslední -stable pro obě tato jádra).
2.6.16.41 vyšlo 18. února s přibližně deseti opravami.
Další změny v 2.6.21
link
S vydáním 2.6.21-rc1 skončilo období pro začleňování novinek v tomto vývojovém cyklu. Většina změn byla popsána již minulý týden, ale několik významných věcí se do hlavního stromu od té doby přeci jen dostalo:
- Bylo začleněno virtualizační rozhraní VMI. VMI je obecné rozhraní pro hypervizory; je (teď) postavené nad paravirt_ops a poskytuje více funkcí.
- Začleněny patche s clocksource a dynamickým tikem.
- Různá vylepšení podpory pro notebooky Sony.
- Byl odstraněn zavržený [obsolote] ovladač ACPI "hotkey".
- Odstraněna byla také verze 1 souborového systému JFFS.
- Auditový subsystém má režim "lockdown" [uzamčení], ve kterém už nelze provádět další konfigurační změny.
- Byl začleněn jednoduchý ovladač, který umožňuje napájení Blackberry z USB portu linuxového systému.
- Velká aktualizace ARM s podporou oprofile pro procesory ARMv6, podporou kexec() a několika nových variant desek a procesorů.
- Souborovému systému v9fs (Plan 9) se dostalo řady vylepšení, především ve formě lepšího kešování.
- Kód sdílené paměti SYSV byl přepracován, aby bylo interní používání souborů rozumnější. Také bude snazší integrace do pokračující práce na kontejnerech/jmenných prostorech.
- Byl přidán ovladač pro čip Silicon Motion SM501 ("multimediální společník").
Teď začíná stabilizační fáze, přičemž 2.6.21 by mělo vyjít někdy začátkem května.
API pro správu zdrojů
link
patch se správou zdrojů alokovaných pro zařízení byl probírán v lednu. Ten patch byl teď začleněn do jádra 2.6.21. A protože je teď to API dané - stejně pevně jako každé další jaderné API - je vhodný čas se na dané rozhraní podívat více z blízka.
Hlavním důvodem existence rozhraní pro správu zdrojů je fakt, že je těžké nezapomínat na uvolňování alokovaných zdrojů. Vypadá to, že je to těžké hlavně pro autory ovladačů, kteří mají - ať už oprávněně nebo ne - pověst původců slušného podílu chyb v jádře. A i ti nejlepší autoři ovladačů mohou narazit na problémy v případech, kdy zjišťování zařízení selže v polovině; ačkoliv může kód obsahovat způsoby, jak situaci napravit, nebývají příliš dobře testovány. Výsledkem je obstojný počet úniků zdrojů v kódu ovladačů.
Tejun Heo kvůli tomuto problému vytvořil novou sadu funkcí pro alokaci zdrojů, které alokace provedené ovladačem sledují. Sledované alokace jsou přiřazeny ke struktuře device; jakmile se ovladač od zařízení odpojí, alokace jsou zrušeny. Rozhraní pro správu zdrojů je tedy podobné API talloc() (.txt), které využívají vývojáři Samby, ale je přizpůsobené prostředí v jádru a řeší více než jen alokace paměti.
Začněme však s alokacemi paměti:
void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
void devm_kfree(struct device *dev, void *p);
Nové funkce jsou podobné jako kzalloc() a kfree(), až na nová jména a přidání parametru dev. Ten je nutný proto, aby kód správy zdrojů věděl, kdy může být paměť uvolněna. Pokud se na nějaké alokace pořád ještě čeká v době, kdy je příslušné zařízení odstraněno, budou také uvolněny.
Všimněte si však, že neexistuje žádný spravovaný ekvivalent kalloc(); pokud se autorům ovladačů nedá věřit, že paměť uvolní, nedá se jim věřit ani to, že by ji inicalizovali. Stejně tak nejsou spravované verze funkcí na úrovni stránek [page-level] a pro alokaci slabu.
Byly však poskytnuty spravované verze několika funkcí pro DMA alokaci:
void *dmam_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp);
void dmam_free_coherent(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle);
void *dmam_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp);
void dmam_free_noncoherent(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_handle);
int dmam_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
dma_addr_t device_addr, size_t size,
int flags);
void dmam_release_declared_memory(struct device *dev);
struct dma_pool *dmam_pool_create(const char *name, struct device *dev,
size_t size, size_t align,
size_t allocation);
void dmam_pool_destroy(struct dma_pool *pool);
Všechny tyto funkce mají stejné parametry jako jejich dma_* ekvivalenty, ale při ukončení práce se zařízením ty DMA oblasti vyčistí. I tak je třeba doufat, že se ovladač postaral o to, aby na těch oblastech nezůstal nějaký aktivní DMA, nebo by se mohly dít nepříjemné věci.
Spravovaná verze pci_enable_device():
int pcim_enable_device(struct pci_dev *pdev);
Není však žádná pcim_disable_device(); měla by se používat pci_disable_device() jako obvykle. Nová funkce:
void pcim_pin_device(struct pci_dev *pdev);
způsobí, že dané pdev bude ponecháno zapnuté i po té, co se od něj ovladač odpojí.
Alokace I/O paměti pomocí pci_request_region() je patchem automaticky nastavena na spravovaný režim - neexistuje žádná pcim_ verze tohoto rozhraní. Alokace vyšších úrovní a mapovací rozhraní však spravované verze mají:
void __iomem *pcim_iomap(struct pci_dev *pdev, int bar,
unsigned long maxlen);
void pcim_iounmap(struct pci_dev *pdev, void __iomem *addr);
Spravované API pro alokaci přerušení je:
int devm_request_irq(struct device *dev, unsigned int irq,
irq_handler_t handler, unsigned long irqflags,
const char *devname, void *dev_id);
void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
U těchto funkcí bylo nutné přidat parametr struct device.
Byla přidána nová sada funkcí pro mapování I/O portů a paměti:
void __iomem *devm_ioport_map(struct device *dev, unsigned long port,
unsigned int nr);
void devm_ioport_unmap(struct device *dev, void __iomem *addr);
void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
unsigned long size);
void __iomem *devm_ioremap_nocache(struct device *dev,
unsigned long offset,
unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
Spravované formy těchto funkcí opět vyžadovaly přidání parametru struct
device.
A nakonec - pro ty, kteří používají nízkoúrovňové funkce pro alokaci zdrojů - spravované verze vypadají takto:
struct resource *devm_request_region(struct device *dev,
resource_size_t start,
resource_size_t n,
const char *name);
void devm_release_region(resource_size_t start, resource_size_t n);
struct resource *devm_request_mem_region(struct device *dev,
resource_size_t start,
resource_size_t n,
const char *name);
void devm_release_mem_region(resource_size_t start, resource_size_t n);
Vrstva pro spravování zdrojů obsahuje "skupinový" mechanismus, ke kterému se přistupuje prostřednictvím následujících funkcí:
void *devres_open_group(struct device *dev, void *id, gfp_t gfp);
void devres_close_group(struct device *dev, void *id);
void devres_remove_group(struct device *dev, void *id);
int devres_release_group(struct device *dev, void *id);
Skupinu lze brát jako značku v seznamu alokací spojených s daným zařízením. Tvoří se pomocí devres_open_group(), které lze předat hodnotu id pro identifikaci skupiny, nebo NULL, aby bylo ID vygenerováno za běhu; ať tak nebo tak, vráceno bude výsledné ID skupiny. Zavolání devres_close_group() značí konec dané skupiny. Volání devres_remove_group() způsobí, že systém na danou skupinu zapomene, ale se zdroji alokovanými v rámci skupiny nic neudělá. Pro odstranění skupiny a okamžité uvolnění všech zdrojů ve skupině alokovaných by se mělo použít devres_release_group().
Skupinové funkce jsou zřejmě určeny hlavně pro kód střední úrovně - například sběrnicové vrstvy. Když se například kód sběrnice pokusí připojit k zařízení ovladač, může otevřít skupinu; pokud se připojení ovladače nezdaří, může být skupina využita k uvolnění všech zdrojů, které ovladač alokoval.
Toto nové API zatím v jádře moc uživatelů nemá. To by se časem mohlo změnit - až si autoři ovladačů začnou všímat jeho funkcí a také třeba dojde k rozšíření typů spravovaných alokací. Odměnou za přechod na spravované alokace by měl být robustnější a jednodušší kód, protože budou odstraněny současné způsoby řešení problémů.
Nový ovladač pro bezdrátové adaptéry Intel
link
Téměř přesně před rokem Intel oznámil projekt ipw3945 project - svobodný ovladač pro bezdrátové adaptéry 3945ABG. Mnozí to vítali jako osvěžující změnu běžných postupů v oblasti bezdrátových technologií, kde se většinou vyskytovaly čistě binární ovladače. Přesto byl ovladač přijat s připomínkami; šlo především o to, že binární "regulační démon" nebyl zrovna oblíbený - navzdory skutečnosti, že je spouštěn kompletně v uživatelském prostoru. Ovladač ipw3945 nikdy nebyl do hlavního jádra zařazen.
Jen samotná snaha o získání svobodného ovladače od nějaké firmy je mnohdy příliš troufalá. Přemluvit je, aby ho napsali znovu, to už většinou vůbec nepřipadá v úvahu. Přesto je to přesně to, co udělal Intel - 9. února byla oznámena nová verze ovladače, včetně nového nablýskaného webu: intellinuxwireless.org. Nový ovladač by měl být oblíbenější než ten původní.
Už žádný regulační démon v uživatelském prostoru. Technici v Intelu zjevně našli způsob, jak regulační funkce přesunout do firmwaru zařízení, takže hostitelský procesor už se o regulační záležitosti vůbec nemusí starat. Je to pravděpodobně robustnější řešení, i když lze říci, že flexibilita hardwaru tím byla omezena. Většina uživatelů se však pravděpodobně takové změně nebude bránit - lepší dodržování regulací a žádný binární démon. Samozřejmě že ti, kteří považují za porušení svých svobod i binární firmware, nebudou mít pocit, že k nějakému zlepšení došlo.
Další významnou změnou je to, že ovladač teď funguje s 802.11 stackem Devicescape. Devicescape je i nadále míněn jako směr, kterým se má bezdrátové síťování v jádře ubírat, takže by nový ovladač mělo jít snáze integrovat. Tedy až se Devicescape dostane do jádra. Prozatím bude nutné, aby uživatelé, kteří chtějí nový ovladač vyzkoušet, také stáhli modul d80211 (k dispozici na stránce Intelu) a zkompilovali si pro své jádro i ten.
To vede k otázce: kdy už se Devicescape dostane do jádra? Proces přípravy na začlenění tohoto kódu trvá déle, než se čekalo, ale pořád se hýbe kupředu. Podle současného plánu to vypadá, že kód Devicescape bude přepracován podle 2.6.21-rc1 a pak zařazen do -mm. Pokud bude vše v pořádku, mohl by se Devicescape propracovat do jádra 2.6.22. To by byl pro linuxové bezdrátové síťování velký krok vpřed.
Zpět k ovladači od Intelu: jedna věc, které se stále nedostává, je nějaká dokumentace k hardwaru. Kdokoliv by s tím ovladačem chtěl něco dělat a nepracuje v Intelu, bude odkázán na to, co se dozví přímo z kódu. Zeptal jsem se [Jonathan Corbet] proto na dokumentaci k hardwaru přímo v Intelu, kde řekli:
Skutečnost se má tak, že programátorskými informacemi k hardwaru jsou zdrojové kódy ovladače. Postupem času se snažíme vylepšovat komentáře v hlavičkách souborů, aby bylo lépe patrné, co vlastně dělají. Kromě toho dáváme k dispozici shrnutí teorie týkající se funkcí, ale neexistuje žádný ucelený dokument, který by obsahoval vše, co je nutné znát, aby člověk mohl zařízení programovat a provozovat.
Když dostali na výběr mezi psaním dokumentace a kódu, rozhodli se programátoři v Intelu pro kód.
Clockevents a dynamický čas
link
Jednou z posledních věcí, které byly začleněny před ukončením přijímání nových patchů pro 2.6.21, byla práce na clockevents [hodinové události] a dyntick [dynamický tik/čas] z real-time stromu. Tyto patche jsou připravovány už velmi dlouho - původně byly určeny k začlenění do verze 2.6.19. Vývojáři (hlavně Ingo Molnar a Thomas Gleixner) však během práce objevili jeden ze základních zákonů vývoje jádra: pokud kvůli tvým patchům Andrew Mortonovi přestane fungovat notebook, je nepravděpodobné, že by se do hlavního jádra dostaly. Tento malý problém už byl vyřešen, takže 2.6.21 bude obsahovat několik zajímavých změn.
Hodinová zařízení byla tradičně řešena v kódu jednotlivých architektur. Výsledkem je hodně duplicitního kódu (existuje více architektur než běžných časovacích zařízení) a žádné jednotné rozhraní pro "jádro jádra" [core kernel], pomocí kterého by bylo možné tato zařízení využívat. Infrastruktura obecného času dne [generic time of day] od Johna Stultze množství problémů vyřešila - alespoň pro úlohy týkající se udržování času - ale pokud někdo chtěl časovací zařízení programovat obecněji, stejně se nakonec musel zabývat kódem architektur.
Sada patchů "clockevents" práci dokončuje. Základem je vytvoření ovladačového API pro zařízení, která mohou zařídit přerušení v určitý čas v budoucnosti. API sleduje schopnosti každého časovače (rozlišení a například to, jestli umí jednorázová nebo opakovaná přerušení) a poskytuje jednoduché rozhraní pro obsluhu. Toto API je definováno v jádře jádra, přičemž v kódu architektur zůstává jen nízkoúrovňový ovladač. Díky tomu teď jádro může využívat možností časovačů nezávisle na architekturách.
S mechanismem clockevents je možné podporovat časovače se skutečně vysokým rozlišením. Když je takový časovač žádán, stačí vybrat vhodné clockevent zařízení a nastavit ho na určený čas. Tato zařízení mohou přerušení dodávat s velkou mírou přesnosti, takže to samé teď dokáží i jaderné časovače - vlastnost, která přijde vhod hlavně uživatelům real-time.
Společně s clockevent je implementován i periodický tik časovače. Umí všechno, co umělo staré přerušení založené na časovači - aktualizace jiffies, počítání procesorového času atd. - ale běží v rámci nové infrastruktury.
To vše znamená zlepšení, ale pořád zbývá jedna věc, která by mohla být ještě lepší: systém ve skutečnosti periodický tik nepotřebuje. To platí zvláště ve chvíli, kdy procesor nepracuje. Odpočívající procesor může ušetřit dost energie, ale když ho budíte 100× (nebo vícekrát) za vteřinu, dost se to na úsporách projeví. S pružnou infrastrukturou časovače není důvod procesor znovu zapínat, dokud není něco na práci. Takže když (i386) jádro přechází do nečinnosti [idle loop], zkontroluje další čekající událost časovače. Je-li tato událost vzdálenější než další tik, vypne se periodický tik úplně; místo toho je časovač naprogramován, aby sám spustil ve chvíli, kdy má dojít k další události. Do té doby nebude procesor nic otravovat - pokud dříve nepřijde nějaké přerušení. Jakmile se procesor probere z nečinnosti, periodický tik se obnoví.
Takže to, co je v 2.6.21, není plně dynamická implementace času. Zrušení tiku při chvílích nečinnosti je dobrým krokem vpřed, ale i úplné odstranění tiku při běhu systému by stálo za to - především na virtualizovaných systémech, které mohou hostitele sdílet s dalšími klienty. Soubor s dokumentací o dynamickém tiku naznačuje, že vývojáři mají na myslí právě to:
Implementace ponechává prostor pro další vývoj - například plně "beztikové" systémy, na kterých je časový úsek ovládán schedulerem [plánovačem], proměnné profilování frekvence [variable frequency profiling] a kompletní odstranění jiffies v budoucnu.
Je možné, že se dočkáme spousty věci - samotné odstranění jiffies by mělo několik zajímavých dopadů. Vývojáři mají připravenu ještě podporu pro architektury x86_64 a ARM, i když to ještě nebylo začleněno v 2.6.21; na podpoře MIPS a PowerPC se také pracuje.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
15.3.2007 23:42
neldor
Re: Jaderné noviny - 21. 2. 2007
16.3.2007 17:56
Ondřej Čečák | skóre: 33
Re: Jaderné noviny - 21. 2. 2007
24.3.2007 11:42
xx
Re: Jaderné noviny - 21. 2. 2007
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
Vývojáři kernelu zjevně trpí nechutným NIH (Not Invented Here) syndromem, chjo