Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Současné vývojové jádro je 2.6.31-rc5 vydané 31. července. Kromě různých oprav regresí ukazuje diffstat pár nových ovladačů (at_hdmac, uc2322, gspca/sn9c20x, ovladače baterie ds2782) a nějaké velké změny v KMS v radeonu… Také byla začleněna infrastruktura „flexibilního pole“ [flexible arrays] (vizte níže). V kompletním changelogu najdete všechny detaily.
Současné stabilní jádro je 2.6.30.4 vydané (společně s 2.6.27.29) 30. července. Obě aktualizace obsahují další dlouhý seznam důležitých oprav.
-- Valerie Aurora jim ukázala, kdo je tu šéf.
-- Alan Cox mluví o tom, jak recyklovat kód.
Greg Kroah-Hartman připustil, že se nemůže nabažit výprasků, a převzal správu TTY vrstvy – práci, kterou nedávno opustil Alan Cox. Do hlavní řady začaly proudit patche, přičemž Linus se tentokrát výrazněji než obvykle staral o to, aby je dal do pořádku. Osud Alanových dlouhodobých plánů na pročištění zůstává nejasný, ale alespoň základní údržba a opravování chyb je zajištěna.
Rafael Wysocki zaslal seznam známých regresí v 2.6.31-rc5. V tomto vývojovém cyklu bylo nahlášeno celkem 76 regresí; 28 z nich zůstává neopraveno. V tomto stádiu vývoje je to přibližně normální, možná trochu o něco lepší než průměr. Méně povzbudivý je však fakt, že seznam regresí 2.6.30 stále obsahuje 39 nevyřešených problémů.
Bylo nebylo, překlad jádra obrazovku zaplnil obrovským množstvím výpisů, které obsahovaly kompletní příkazovou řádku pro každý příkaz kompilace. Není třeba říkat, že z tak velkého šumu bylo těžké dostat nějaké informace; od jisté doby ale překladový systém jádra vypisuje stručnější informace o tom, co dělá. Někdy je nicméně potřeba vidět, co se skutečně děje; v takových případech spuštění make V=1 způsobí, že překladový systém vypíše všechno.
Až na to, jak zjistil Dave Airlie, že nevypíše; některé příkazy jsou stále skryty, i když je specifikováno V=1. Správce překladového systému Sam Ravnborg to objasnil: Problém je v tom, že V=1 je již příliš ukecaný, takže lidé občas svoje záležitosti schovávají – jako v tomto případě. Navrhl, aby se implementovalo několik úrovní podrobnosti, takže pro zobrazení opravdu kompletního proudu příkazů by se použilo V=2. Malý problém je v tom, že V=2 se již používá, aby
Greg Kroah-Hartman, který se evidentně necítí být vytížen TTY vrstvou, znovu zaslal patch devtmpfs s tím, že je připraven pro začlenění do hlavní řady. Greg říká:
Je nicméně potřeba říci, že komunita vývojářů se ještě neshodla na tom, jestli je začlenění tohoto patche žádoucí; v blízké budoucnosti očekávejme zajímavou diskuzi.
Budoucnost filtrování paketů v Linuxu mohou být nftables, ale Jan Engelhardt na ně nečeká. Místo toho sestavil obrovskou sadu patchů, která významně přepracovává existující mechanismus iptables. Interní datové struktury jsou vytrženy a reimplementovány jako flexibilnější spojový seznam, což připravuje scénu pro budoucí zjednodušení jednořádkových změn. Největší přínos je nicméně sjednocení verzí enginu pro filtrování paketů pro IPv4, IPv6 a ARP; to, říká Jan, umožňuje vyhodit přibližně 50 % kódu.
První odpovědi naznačují, že potenciální revidovatelé byli ochromeni velikostí změny. Jan zaslal detailnější vysvětlení toho, co jednotlivé skupiny patche dělají, což pomohlo. Eventuální začlenění kódu nicméně pravděpodobně bude vyžadovat rozdělení sekvence do několika kroků.
Poznámky zaslal Len Brown; poskytují dobré (i když stručné) shrnutí aktuálního vývoje v dané oblasti a o tom, na čem se nyní pracuje.
I když pro mnoho uživatelů a datových center byla virtualizace spásou, mívá tendence mít problémy s výkonnosti, obzvláště s výkonností I/O. Řešení tohoto problému je cílem nově oznámeného projektu AlacrityVM, který vytváří hypervizor založený na KVM. Zkrácením I/O cesty pro hosty se AlacrityVM snaží poskytnout I/O výkonnost téměř se blížící "holému železu".
Projekt je podle webových stánek v pre-alfa stádiu, ale již se síťovým ovladačem, který slouží jako prověření principu [proof of concept], dosahuje poměrně ohromujících výsledků. Jak propustnost, tak latence je u AlacrityVM lepší než u hostů s hostiteli 2.6.28 a 2.6.29-rc8. Také zjevně předčí virtio ovladače v KVM hostu.
Hlavní změna, která AlacrityVM umožňuje dosáhnout tohoto nárůstu, pochází z jaderného schématu pro virtuální I/O známého jako virtuální sběrnice (nebo vbus). KVM hosty v současnosti používají pro obsluhu I/O požadavků emulovaná zařízení – která v uživatelském prostoru implementuje QEMU. To vede k několika přechodům mezi jádrem a uživatelským prostorem pro každou I/O operaci. Nápad, který stojí za vbus, je umožnit hostům přímo přistupovat k jadernému ovladači hostitele, čímž se omezuje režie pro I/O.
Použitím vbus může správce hostitele definovat virtuální sběrnici, která obsahuje virtuální zařízení – velmi podobné linuxovému modelu zařízení – a která umožňuje přístup k jadernému ovladači. Host přistupuje ke sběrnici pomocí ovladačů vbus hosta a může využít jenom ta zařízení, která správce na dané virtuální sběrnici vytvoří. Rozhraní vbus podporuje jenom dvě „slovesa“: call() pro synchronní požadavky a shm() pro asynchronní komunikaci s použitím sdílené paměti.
Dokument [PDF] od vývojáře AlacrityVM Gregoryho Haskinse popisuje, jak virtuální sběrnici nakonfigurovat a používat. Virtuální sběrnice poskytuje rozhraní sysfs, které může správce využít k vytvoření objektů podobných kontejnerům, které omezí hosty tak, aby mohly přistupovat pouze k zařízením, jež jim byla specificky přidělena. To pomáhá řešit jeden z potenciálních problémů s hosty, které přistupují k jaderným ovladačům více méně přímo: bezpečnost.
Webová stránka o virtuální sběrnici se zabývá bezpečnostními záležitostmi a tím, jak jsou řešeny. Nejdůležitější záležitostí je, aby hosty nemohly použít mechanismus virtuální sběrnice k útěku z izolace od ostatních hostů a procesů, stejně jako to, aby nemohly způsobit odepření služby na hostiteli. Sběrnici lze vytvořit a osadit zařízeními pouze na straně hostitele a každá žije v izolovaném jmenném prostoru, což omezuje nebo odstraňuje riziko průniku mezi sběrnicemi a narušení izolace. Krom toho lze každou úlohu spojit jenom s jednou virtuální sběrnicí – což je vynuceno vložením odkazu na vbus do struktury úlohy [task struct] – aby mohl host vidět pouze ID zařízení specifikovaná na dané sběrnici.
Pečlivě bylo postaráno o to, aby byl za špatné chování potrestán host, a ne hostitel. Dvě oblasti zmíněné u hostů jsou, když se záměrně nebo omylem poškodí datové struktury ve sdílené paměti, nebo když host neobslouží svůj kruhový buffer. Naivní implementace by za těchto situací umožnila odepření služby zablokováním vláken operačního systému hostitele nebo vytvořením situace, která by normálně mohla být řešena pomocí BUG_ON(). Virtuální sběrnice podniká kroky k tomu, aby byla cesta mezi hostitelem a hostem odolná proti zdržování a zároveň zařídí ukončení hosta, který do struktur v kruhovém bufferu zapisuje nesmysly.
Gregory zaslal sérii patchů, která přidává infrastrukturu vbus společně s ovladačem pro akcelerovaný ethernet. Zatím byly patche přijaty poměrně dobře, i když ještě není mnoho komentářů. Webová stránka jasně říká, že cílem projektu je pracovat směrem k přijetí projektu upstreamem v časovém období, které bude vyhovovat komunitě. Flexibilita předvedená u tohoto cíle by mohla projektu při přijímání do hlavní řady dobře sloužit.
Projekt na své webové stránce shrnuje i svůj stav a plány do budoucna: Máme funkční návrh, který zahrnuje základní hypervizor, podporu linuxového hosta a akcelerované síťování. To rozšíříme a zahrneme další důležité oblasti jako akcelerované I/O na disky, IPC, rozšíření pro reálný čas a akcelerovanou podporu hostů MS Windows. Jak lze uhádnout, webová stránka má také e-mailovou konferenci pro uživatele a vývojáře stejně jako gitové stromy pro jádro i uživatelský prostor pro ty, kdo mají zájem.
Jak AlacrityVM, tak vbus vypadají jako zajímavé projekty, které pravděpodobně bude mít někdy v budoucnu cenu zkoumat jako potenciální virtualizační řešení. Výkonnostní zisky, které plynou z vbus, budou pravděpodobně užitečné i pro další projekty.
V táboře preempce v reálném čase [realtime preemption] bylo v uplynulých měsících relativně ticho. To ale neznamená, že vývojáři nic nedělali; naopak, připravují se na koncovku: Začlenění většiny zbývajících patchů do hlavní řady jádra. Strom 2.6.31-rc4-rt1 nedávno oznámený Thomasem Gleixnerem ukazuje výsledky většiny zmíněné práce. Tento článek se dívá na některé z nedávných změn v -rt.
Cílem projektu preempce v reálném čase je umožnit obecnému linuxovému jádru poskytnout deterministickou dobu odezvy pro procesy o vysoké prioritě. „V reálném čase“ nutně nemusí znamenat „rychle“; znamená to s jistotou vědět, že systém bude schopen reagovat na důležité události do specifické doby. Často bylo možné slyšet, že to nelze, že složitost kompletního operačního systému zabrání všem pokusům garantovat omezenou dobu odezvy. Jenže samozřejmě bylo také možné slyšet, že vývojáři svobodného softwaru nikdy nevytvoří kompletní operační systém. Vývojáři stromu reálného času věří, že obě tato tvrzení jsou stejně nepravdivá, a pracovali na tom, aby to dokázali.
Jednou z dlouhodobých vlastností stromu reálného času jsou obsluhy přerušení ve vláknech. „Tvrdá“ obsluha přerušení si může obsadit CPU po tak dlouhou dobu, po jakou běží; to může ostatním uživatelům způsobit zpoždění. Přesunutí obsluhy přerušení do vlastního vlákna umožní obsluhu plánovat stejně jako všechny ostatní procesy v systému. Tak se obsluha přerušení nemůže plést do cesty procesu o vyšší prioritě.
Většina z kódu pro obsluhu přerušení ve vláknech se do jádra dostala ve verzi 2.6.30, ale v poněkud jiné podobě; zatímco obsluha přerušení ve vláknech je v jádře pro práci v reálném čase téměř všudypřítomná, v hlavní řadě je to volitelná (a tím pádem téměř nevyužívaná) vlastnost, takže se API musela trochu změnit. Zpracování přerušení v jádře pro práci v reálném čase byla tedy přepracována podle mechanismu přerušení ve vláknech z hlavní řady, stále ale mají své zvláštnosti.
Konkrétně lze stále jádro zkonfigurovat tak, aby se veškerý kód pro obsluhu přerušení přesunul do vláken. Pokud daný ovladač explicitně požádá o obsluhu ve vláknech, chování je podobné jako u běžného jádra; „tvrdá“ obsluha přerušení běží jako obvykle v kontextu IRQ. Ovladače, které obsluhu ve vláknech nevyžadují, ji přesto dostanou se speciální tvrdou obsluhou, která maskuje danou přerušovací linku, dokud obsluha běží. Nyní má každé zařízení svoje vlákno pro obsluhu přerušení (dříve ho měla jenom každá linka). Ve shrnutí – objem kódu, který je specifický pro strom reálného času, je nyní relativně malý; většina ho je v hlavní řadě.
Obsluha softwarových přerušení je ve stromě pro reálný čas trochu odlišná. Jádra hlavní řady obvykle softwarové přerušení obslouží ve chvíli, kdy se jim to hodí – obvykle při přepínání kontextu nebo když se vrací ze systémového volání. Pokud ale zátěž softwarovými přerušeními naroste, obsluhu přebírá vlákno „ksoftirqd“, které běží pro každé CPU jedno. V realtime stromě (nastavitelné konfigurační volbou) přechází veškerá obsluha softwarových přerušení do ksoftirqd – nyní ale je samostatné vlákno pro každou přerušovací linku. Každé CPU tedy dostane několik vláken ksoftirqd pro zpracování síťové komunikace, jedno pro blokový subsystém, jedno pro RCU, jedno pro tasklety a tak dál. Softwarová přerušení lze také přerušit preempcí, i když to se asi nebude dít příliš často – běží s prioritou v reálném čase.
První, čím se ve stromě preempce v reálném čase začalo, bylo nahrazení rotujících zámků [spinlock] spícími mutexy. Technika spinlocků může těžko zajistit deterministické latence; každý procesor, na kterém ve smyčce běží zámek, bude čekat neomezeně dlouho podle toho, co dělá kód na jiném CPU. Kód držící spinlock také nelze přerušit preempcí; to by přinejlepším způsobilo vážné latence nebo deadlock. Splnění cíle zajištění omezené doby odezvy tedy vyžadovalo odstranění spinlocků v co největším možné rozsahu.
Nahrazení spinlocků v jádře mutexy pro reálný čas většinu tohoto problému řeší. Vlákno čekající na mutex se uspí, čímž procesor uvolňuje jiné úloze. Vlákna držící mutexy lze preempcí přerušit, pokud se objeví proces o vyšší prioritě. Pokud tedy byly priority nastaveny správně, nemělo by nic stát v cestě tomu, aby byl proces o nejvyšší prioritě schopen kdykoliv reagovat na události. To je základní myšlenkou konceptu preempce v reálném čase.
Jak se ale stává, ne všechny spinlocky lze nahradit mutexem. Na nejnižší úrovni systému je stále potřeba skutečné (nebo „čisté“) spinlocky; jeden zjevný příklad jsou například zámky, které se používají k implementaci mutexů. Během let bylo hodně snahy věnováno tomu, aby se zjistilo, které spinlocky opravdu musí být „čisté“. Na úrovni kódu se tento rozdíl realizoval použitím poněkud ošklivých triků s primitivy spinlocků – bez ohledu na to, jestli se používá skutečný spinlock nebo spící zámek, kód by k získání zámku vždy volal spin_lock(); jediný rozdíl byl v tom, kde byl zámek deklarován.
Tento přístup byl pravděpodobně užitečný v počátečních fázích vývoje, kdy bylo často nutné změnit typ specifických zámků. Ošklivé triky s překladačem, které slouží k zakrytí toho, který zámek se používá ve specifickém kontextu, nicméně těžko projdou při začleňování do hlavní řady. Vývojáři realtime stromu tedy zatnuli zuby a tyto dva typy zámku úplně oddělili. Nahrazení „spinlocků“ mutexy je ale provedeno stejně jako předtím jednoduše proto, že změna každého jednotlivého spinlocku by byla masivní a rušivou změnou v celé základně jaderného kódu. Typ „čistého“ spinlocku, který se používá méně často, je pro tuto změnu vhodnější.
Výsledkem je nové primitivum pro vzájemné vyloučení nazvané atomic_spinlock_t, které vypadá hodně podobně jako tradiční spinlock:
#include <linux/spinlock.h> DEFINE_ATOMIC_SPINLOCK(name) atomic_spin_lock_init(atomic_spinlock_t *lock); void atomic_spin_lock(atomic_spinlock_t *lock); void atomic_spin_lock_irqsave(atomic_spinlock_t *lock, long flags); void atomic_spin_lock_irq(atomic_spinlock_t *lock); void atomic_spin_lock_bh(atomic_spinlock_t *lock); int atomic_spin_trylock(atomic_spinlock_t *lock); void atomic_spin_unlock(atomic_spinlock_t *lock); void atomic_spin_unlock_irqrestore(atomic_spinlock_t *lock, long flags); void atomic_spin_unlock_irq(atomic_spinlock_t *lock); void atomic_spin_unlock_bh(atomic_spinlock_t *lock);
Tyto nové „atomické spinlocky“ se používají v plánovači, nízkoúrovňovém kódu pro obsluhu přerušení, práci s hodinami, správě PCI sběrnice, ACPI subsystému a mnoha dalších místech. Změna je stále velká a rušivá – ale mnohem méně, než kdyby se měnil běžný „spinlock“.
Dalo by se namítnout, že vložení spinlocků zpět do jádra znovu zavede stejné problémy s latencí, kterým se vývojáři chtěli vyhnout. Je tu rozhodně riziko, že se tak stane, nicméně opatrným přístupem ho lze minimalizovat. Kontrola každé cesty kódu v jádře, která používá spinlocky, zjevně není zvládnutelná, ale je zvládnutelné podívat se zblízka na (mnohem menší) počet kódových cest, které používají atomické spinlocky. Lze tedy mít rozumnou úroveň jistoty, že zbývající atomické spinlocky nezpůsobí, že by jádro nedosáhlo svých cílů, co se latence týče.
(Jen tak mimochodem – Thomas Gleixner pro typ atomic_spinlock_t hledá lepší jméno. Navrhněte vítězné jméno a odměnou vám může být pivo zdarma na příští konferenci.)
Podobné změny byly provedeny u mnoha dalších jaderných mechanismů pro vzájemné vyloučení. Je zde nová varianta sekvenčních zámků [seqlock] atomic_seqlock_t pro případy, kdy není možná preempce zapisovatele sekvenčního zámku. Typ anon_semaphore z největší části, zdá se, přejmenovává semafory a s nimi spojené funkce; to je součástí pokračující snahy odstranit semafory z míst, kde by měl být použit mutex nebo dokončovací zámek [completion]. Jako náhrada rw_semaphore je zde rw_anon_semaphore.
V -rt stromě zůstává několik změn specifických pro práci v reálném čase. Kód pro reálný čas není kompatibilní se SLUBem, takže je povolen pouze slab. Také je zde zajímavý problém s kmap_atomic(); tato funkce vytváří dočasné mapování adresy v jaderném adresovém prostoru specifické pro CPU pro danou stránku v paměti. Preempce není možná, dokud je atomický kmap aktivní – mohlo by se stát, že jiný kód mapování změní předtím, než se ho kód, který byl přerušen preempcí, pokusí použít. Při práci v reálném čase jsou výkonnostní zisky plynoucí z použití atomického kmap převáženy dodatečnou latencí, kterou mohou způsobit. Z praktických důvodů tedy kmap_atomic() v jádře pro práci v reálném čase neexistuje; volání kmap_atomic() jsou mapována na běžné volání kmap(). A tak dále.
Co se týče práce, která ještě není ani v realtime stromě, první priorita je jasná:
V tuto chvíli zbývající práce na odstranění velkého jaderného zámku znamená zkontrolovat jednotlivé souborové systémy a ovladače; z vnitřní části jádra byl z většiny odstraněn.
Kromě toho je zde malý úkol začlenit co nejvíce kódu do hlavní řady jádra. Za tímto účelem je připravován gitový strom se sekvencemi patchů, které lze testovat půlením [bisect], i když tato práce ještě hotová není. Také se chystá shromáždění vývojářů reálného času pro Linux – Eleventh Real-Time Linux Workshop konaný v září v Drážďanech; začlenění práce na reálném čase do hlavní řady zde bude vážně diskutováno. Jak je obvyklé, autor článku má v úmyslu u toho být; koncem září se sem podívejte pro aktualizaci.
Jaderní vývojáři musí mít na paměti omezení, která jsou pro jejich programovací prostředí unikátní; jedním z nich je to, že čím více paměti se alokuje, tím méně spolehlivá alokace je. Alokace jediné stránky z praktického hlediska uspěje vždy. Požadavek na dvě fyzicky spojité stránky má vysokou pravděpodobnost úspěchu, ale každé zdvojnásobení snižuje šanci na úspěch alokace. Fragmentace paměti, která nastává za běhu systému, čím dál více ztěžuje nalezení skupin fyzicky spojitých stránek. Od velkých alokací jsou tedy vývojáři značně odrazováni.
Na tento problém je občas reagováno alokováním stránek pomocí vmalloc(). Paměť alokovaná tímto způsobem je virtuálně spojitá, ale fyzicky ne – dokud tedy nejsou zapotřebí fyzicky spojité stránky, vmalloc() se zdá být dobrým řešením. Toto řešení nicméně není ideální. Na 32bitových systémech musí být paměť alokovaná pomocí vmalloc() mapována do relativně malého adresového prostoru; je snadné ji vypotřebovat. Na SMP systémech mohou změny v tabulce stránek, které alokace pomocí vmalloc() vynucují, vyžadovat drahé meziprocesorové přerušení na všech CPU. A na všech systémech používání prostoru v rozsahu vmalloc() zvyšuje tlak na TLB [translation lookaside buffer], což snižuje výkon systému.
Bylo by tedy hezké mít mechanismus, který by byl schopen zvládnout alokaci velkých polí způsobem, který by byl (1) spolehlivý a (2) nepoužíval vmalloc(). Dosud byly všechny takové mechanismy sestavovány vývojáři, kteří řešili specifický problém; nebylo vytvořeno nic pro obecné použití. To se změnilo se začleněním mechanismu „flexibilních polí“ [flexible array], který napsal Dave Hansen pro 2.6.31-rc5.
Flexibilní pole obsahuje libovolný (v rámci limitů) počet objektů pevné velikosti, ke kterým se přistupuje pomocí celočíselného indexu. Řídká [sparse] pole jsou řešena rozumným způsobem. Používají se pouze jednostránkové alokace, takže k selhání alokace paměti by mělo docházet relativně zřídka. Nevýhodou je, že pole nelze indexovat přímo, velikost jednoho objektu nesmí překročit velikost stránky v systému a vkládání dat do flexibilního pole vyžaduje operaci kopírování. Také stojí za to poznamenat, že flexibilní pole nepoužívají žádné interní zamykání; pokud je možný souběžný přístup do pole, volající musí zamykání vyřešit sám.
Flexibilní pole se vytvoří voláním:
#include <linux/flex_array.h> struct flex_array *flex_array_alloc(int element_size, int total, gfp_t flags);
Velikost objektu je udána element_size, total je maximální počet objektů, který lze do pole vložit. Argument flags je předáván přímo interním voláním při alokaci paměti. V současném kódu pravděpodobně povede použití flags k tomu, aby se alokovalo z horní paměti, k výrazně nepříjemným vedlejším efektům.
Data se do pole vloží voláním:
int flex_array_put(struct flex_array *array, int element_nr, void *src, gfp_t flags);
Toto volání zkopíruje data ze src do array na pozici zvolenou pomocí element_nr (které musí být nižší než maximum udané, když bylo pole vytvořeno). Pokud přitom musí být alokována paměť, použijí se flags. Při úspěchu je návratová hodnota nula, v opačném případě záporný chybový kód.
Pravděpodobně může být zapotřebí ukládat data do flexibilního pole při běhu v nějakém atomickém kontextu; v takové situaci by spaní v alokátoru paměti bylo špatné. Tomu se lze vyhnout použitím GFP_ATOMIC v hodnotě flags, ale často je lepší způsob. Trik spočívá v tom, že se všechny potřebné alokace paměti provedou před vstupem do atomického kontextu použitím:
int flex_array_prealloc(struct flex_array *array, int start, int end, gfp_t flags);
Tato funkce zajistí alokaci paměti pro prvky s indexem v rozsahu od start po end. Pro volání flex_array_put() s prvkem v tomto rozsahu je garantováno, že nebude blokovat.
Data se z pole získají zpět voláním:
void *flex_array_get(struct flex_array *fa, int element_nr);
Návratová hodnota je ukazatel na prvek nebo NULL, pokud daný prvek nikdy nebyl alokován.
Všimněte si, že je možné získat platný ukazatel na prvek, který do pole nikdy nebyl vložen. Paměť pro prvky je alokována po jednotlivých stránkách; jediná alokace může poskytnout paměť pro několik sousedících prvků. Kód flexibilních polí neví, jestli byl specifický prvek zapsán; pouze ví, jestli je k dispozici s ním spojená paměť. flex_array_get() volaná pro prvek, který nebyl uložen, může potenciálně vrátit ukazatel na náhodná data. Pokud volající nemá samostatné prostředky pro zjištění, které prvky byly opravdu vloženy, může být moudré přidat do parametru flags hodnotu GFP_ZERO, aby se zajistilo, že budou všechny prvky vynulované.
Není možné vyjmout z pole jediný prvek. Je však možné odstranit všechny prvky voláním:
void flex_array_free_parts(struct flex_array *array);
Toto volání uvolní všechny prvky, ale pole samotné nechá na místě. Uvolnění celého pole se zajistí funkcí:
void flex_array_free(struct flex_array *array);
V době psaní tohoto článku flexibilní pole v hlavní řadě nikdo nepoužívá. Funkce popsané zde také nejsou exportovány modulům; to pravděpodobně bude opraveno, když je bude někdo potřebovat.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
ochomeni, nebo ohromeni? :-o
To ma tesi, ze nebudem sam z byvaleho Ceskoslovenska v Drazdanoch (mam tam prijate 3 prispevky) aj ked na ine temy.. Ale s Ingom a thomas som sa chcel stretnut pori prof. McGuire-ovi a Paolovi Motegazaa-ovi...
Ak bude zaujem tak sa pridam do tymu rt patchov, ved dnes my YAST vyhodil finaly 2.6.31-6.1 cize finmal verzia...
nie rc-cko...
Ja viem,ze Sklizen sa robi s oneskorenim (op[ozdenim), ale aj tak zaujimava doplnuja informacia, hlavne ako normalna 2.6.31 nie je este vydana...
http://www.kernel.org/
3.9.2009 11:52
michich | skóre: 51
| blog: ohrivane_parky
Skoda, ale aj tak dufam, ze tam niekto z Ciech, Moravy alebo Sliezska bude... Pripadne mozem naspiat report, ak budem stihat
3.9.2009 16:35
belisarivs | skóre: 22
| blog: Psychobláboly
Tak ho napis pozdeji. Nejlepe formou clanku. Rad si (urcite nejenom ja) poctu.
Taky bych konecne rad podekoval Jirkovi (trekker.dk?) za preklady Jadernych novinek. Super prace.
Dekuji.
3.9.2009 16:36
belisarivs | skóre: 22
| blog: Psychobláboly
Jo. Je to on.
Muzu se zeptat proc ten nick?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
