BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Aktuální předverze řady 2.6 je (k 28. 2. 2007) 2.6.21-rc2, vydaná 27. února. Obsahuje velkou aktualizaci Video4Linux a PA-RISC, začátek podpory "SMARTMIPS", ovladač pro USB ethernetové adaptéry Davicom DM9601, ovladač pro "IO Warrior" od Code Mercenaries a podporu využívání subsystému HID v Bluetooth. Několik patchů bylo také staženo kvůli regresím. Linus o této verzi řekl: Takhle by -rc2 vypadat neměla. Opravdu to potřebujeme zklidnit! Vizte podrobnosti v dlouhém changelogu.
Od vydání -rc2 nepřibyly do hlavního repozitáře žádné patche.
Minulý týden nevyšlo žádné -mm jádro.
Jádra z větve -stable 2.6.19.5 a 2.6.18.8 byla obě vydána 23. února. Obsahují slušný počet oprav. Další aktualizace 2.6.18 už nejsou pravděpodobné; asi ještě vyjde jedna verze 2.6.19.
2.6.16.42 vyšlo 26. února a obsahuje několik oprav, z nichž některé se týkají bezpečnosti.
Protože jestli nechápeš, proč si stěžuju, nemohu od tebe stahovat [pull]. Můžeš mi posílat patche, ale abych si od tebe stáhl git patch, to bych si musel být jistý, že víš, co děláš. Potřebuji mít v ty věci důvěru, *aniž* bych musel každou jednotlivou změnu kontrolovat.
Ve světě virtualizace to občas vypadá, že se věci moc rychle nehýbají. O Xenu už se v souvislosti s paravirualizací mluví roky - první "stabilní" vydání bylo oznámeno v roce 2003 - ale kód se pořád do hlavního jádra nedostal. Poslední dobou se projekt moc neozýval - i když programátoři Xenu na kódu pořád pracují.
Naproti tomu KVM se zdá být pěkně rozjeté. Projekt se objevil v říjnu 2006 a o pár měsíců později si našel cestu do jádra 2.6.20. 25. února byla oznámena verze KVM 15; ta má zajímavou funkci: živou migraci. Rychlost, s jakou se vývojářům KVM daří přidávat poměrně pokročilé funkce, je úctyhodná; stejně úctyhodné je i to, jak jednoduchý je kód, který živou migraci implementuje.
KVM má oproti ostatním virtualizačním projektům velkou výhodu: spoléhá na podporu v hardwaru, která je k dispozici jen u nových procesorů. Proto také nebude KVM fungovat na většině v současnosti nasazených systémů. Na druhou stranu - navrhování pro budoucí hardware je často výhodné. Budoucnost na sebe ve světě technologií nenechává dlouho čekat. Zaměření na hardwarem podporovanou virtualizaci znamená, že KVM se může věnovat vyvíjení zajímavých funkcí, které budou dostupné na teď nakupovaných systémech.
Migrační kód je zabudován do emulátoru QEMU; Příslušný soubor se zdrojovým kódem má méně než 800 řádků. Živá migrace funguje takto:
Dokonce je možné bez problémů přesouvat hostované systémy z procesorů Intel na AMD a nazpátek. Není však možné přesunout 64bitového hosta na 32bitového hostitele; nevypadá to, že by se vývojáři KVM v dohledné době měli k řešení tohoto konkrétního omezení. O trochu více informací lze nalézt na stránce o KVM migraci.
Další věc, která stojí za zmínku, je plánované zmrazení rozhraní KVM pro 2.6.21. Rozhraní se rychle vyvíjelo, přestože se jedná o API pro uživatelský prostor; takovou pružnost umožňovala skutečnost, že jde o nový, experimentální kód, který zatím nikdo v reálu nepoužívá. Zmrazení API naznačuje, že vývojáři KVM považují kód za dostatečně stabilní, aby mohl být brzy nasazen na produkční systémy. Možná to také znamená, že se brzy dozvíme, jak hodlá společnost Qumranet, která práci na KVM platí, vydělávat peníze.
Vzpomínáte na fibrily? Ta vzpomínka asi nebude moc čerstvá, vzhledem k tomu, že se tu o nich psalo v lednu, ale práce inspirovaná konceptem fibril pokračuje. Poslední syslet patch od Ingo Molnara byl zveřejněn 24. února; přináší zajímavé změny v tomto přístupu k provádění asynchronních systémových volání.
Koncept "atomů", který byl součástí prvního syslet patche, zůstává; atom je jednotka práce prováděné v jádře. Atomy mohou být zřetězovány pomocí jednoduchých operací, takže celá sekvence může být provedena bez opuštění jádra. Sekvence atomů bude - pokud možno - provedena synchronně; pokud se však atom zablokuje, bude pro navrácení do uživatelského prostoru vytvořeno nové vlákno. Díky tomu může být asynchronní kód spouštěn paralelně, ale režie způsobená vytvářením vláken se projeví, jen když je to nutné.
API sysletů se však změnilo v reakci na obavy týkající se toho, jak budou řešeny události signalizující dokončení [completion events]. Uživatelský prostor teď musí vytvořit strukturu, která bude doprovázet sekvenci atomů:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
struct async_head_user {
unsigned long kernel_ring_idx;
unsigned long user_ring_idx;
struct syslet_uatom __user **completion_ring;
unsigned long ring_size_bytes;
/* tady jsou ještě další věci */
};
Struktura definuje kruh dokončení [completion ring] - kruhový buffer, který jádro naplní ukazateli na již dokončené atomy. Není už nutné tento buffer v jádře registrovat, protože struktura je předána v okamžiku předání atomů, které mají být provedeny:
struct syslet_uatom *async_exec (struct syslet_uatom *atom,
struct async_head_user *ahu);
Z nového rozhraní vyplývá, že každá série atomů může mít - pokud o to stojí - svůj vlastní kruh dokončení. Tyto kruhy už nejsou drženy v paměti, takže jich může být libovolné množství. Návratová hodnota z async_exec() bude ukazatel na poslední atom, který má být proveden, běží-li série bez blokování, nebo NULL, je-li série blokována a uživatelský prostor běží v novém vlákně.
Jens Axboe, Suparna Bhattacharya a další prováděli s aktuálním kódem sysletů výkonnostní testy. Mnohé z testů (i když ne všechny) ukazují, že syslety poskytují lepší výkon než stávající implementace asynchronního I/O. Příčiny rozdílných výsledků jsou stále zkoumány, ale ukázalo se, že se syslety nefunguje správně CFQ I/O plánovač [scheduler]. Plánování CFQ je orientované na procesy, takže není tak docela překvapivé, že změny procesního modelu způsobují zmatky. Ingo si je i tak jistý, že syslety přinesou lepší výkon:
Podle mých vlastních měření (založených na FIO) jsou syslety rychlejší než nativní KAIO rozhraní - jak s keší (== hodně vláken), tak bez keše. Ten druhý výsledek jsem vůbec nečekal, protože kód sysletů zatím není vůbec optimalizovaný pro provoz bez keše. Předpokládal jsem tedy (mnohem) větší režii procesoru než u KAIO.
To znamená, že KAIO je na tom hůř, než jsem si myslel - je toho prostě moc, co musí KAIO udělat, aby bylo možné provést paralelní IO. Protože optimalizace KAIO probíhají již několik let, je pravděpodobně na hranici svých výkonnostních možností.
Asi největší změnou v nové verzi patche je však vytvoření konceptu pojmenovaného "threadlets" [vlákénka]. Threadlety do uživatelského prostoru přinášejí vytváření vláken na požádání. Threadlety jsou obyčejný kód, který bude, je-li to možné, spuštěn synchronně; pokud se však zablokuje, bude vytvořeno nové vlákno, které uživatelskému prostoru umožní pokračovat, zatímco threadlet čeká.
Ingovo API vyžaduje, aby aplikace definovala, že má funkce běžet jako threadlet:
long threadlet_fn(void *data)
{
/* Almost anything can go here */
return complete_threadlet_fn(event, ahu);
}
Jediný rozdíl je, že je nutné volat complete_threadlet_fn():
long complete_threadlet_fn(void *event, struct async_head_user *ahu);
Parametr event je uložen v kruhu dokončení - protože tu však není žádná struktura atomu, musí uživatelský prostor poskytnout hodnotu označující dokončený threadlet. Struktura async_head_user opět popisuje kruh dokončení.
Aplikace může threadlet spustit pomocí:
long threadlet_exec(long threadlet_fn(void *),
unsigned long stack,
struct async_user_head *ahu);
Kromě výše popisovaného threadlet_fn() ještě toto volání vyžaduje, aby aplikace pro nový threadlet poskytla prostor ve stacku. Parametr stack je tedy ukazatel (navzdory svému typu unsigned long) na několik stránek běžné uživatelské paměti vyhrazených pro tento účel. Struktura async_user_head umožňuje hlášení o dokončení threadletu. Pokud threadlet_fn() doběhne do konce bez bloku, návratová hodnota threadlet_exec() bude 1; jinak je vrácena nula.
threadlet_exec() je ale jen wrapper pro uživatelský prostor, který maskuje komplikovanost skutečného rozhraní. Funkce se okamžitě přepne na daný stack a zavolá threadlet_on(), což je to skutečné systémové volání, přičemž mu předá původní adresu stacku jako parametr. Volání uloží adresu stacku, ujistí se, že bude k dispozici vlákno pro případ selhání keše [cache miss thread], a označí proces jako asynchronní. Pak se vrátí do uživatelského prostoru, který spustí uživatelovu threadlet_fn(). Pokud se tato funkce zablokuje, vezme si jádro nové vlákno, nastaví ho na původní stack a pošle zpět do uživatelského prostoru. Threadletová funkce pak bude pokračovat v původním vlákně, jakmile se vyřeší to, co ji blokovalo.
Není tedy překvapení, že complete_threadlet_fn() je také wrapper. Volá threadlet_off(), aby dal najevo, že je provádění threadletu dokončeno. Pokud threadlet_off() vrátí 1, znamená to, že threadlet běžel synchronně, a všechno už je hotovo. Jinak se zavolá:
long async_thread(void *event, struct async_head_user *ahu);
Toto systémové volání uloží event v kruhu dokončení. Protože vlákno běží asynchronně, není možné se vrátit uživatelského prostoru - ten si šel svou cestou ve chvíli, kdy došlo k prvnímu bloku. Takže async_thread() dá aktuální vlákno na seznam vláken, která budou k dispozici, až bude zase příště nějaké potřeba pro asynchronní spuštění.
Uvedený popis vynechal několik detailů, především ohledně správy stacků v uživatelském prostoru. Stojí za povšimnutí, že na konci threadletového stacku patrně není žádná guard page [ochrana proti přetečení], takže je-li stack příliš malý, mohl by uživatelský prostor snadno způsobit přetečení. Výsledkem by pravděpodobně byly opravdu záhadné chyby, které by se těžko hledaly. Další změny API asi ještě přijdou, protože Ingo plánuje převést threadlet_on() a threadlet_off() na vsyscall, které by mohly být prováděny bez jakéhokoliv vstupu do jádra. To by samozřejmě výkonnost threadletů ještě zvýšilo.
Přestože syslet API nabídlo zajímavé funkce, bylo hned jasné, že se s ním bude těžko pracovat. Nové threadlet API bylo navrženo tak, aby tyto problémy obešlo opuštěním celého konceptu "atomů" a umožněním co nejjednoduššího asynchronního spouštění uživatelského kódu. Mechanismus sysletů asi nezmizí, protože jde pořád o nejrychlejší způsob, ale pravděpodobně nebude používán jinde než ve speciálních jednoúčelových knihovnách, které zamaskují jeho složitost. Na všechno ostatní by se mohly hodit threadlety.
Pokračující diskuze o threadletech (nebo fibrilech nebo jak se budou jmenovat příští týden) přinesla také úvahy o přidání velkého nového API do jádra. Ta diskuze však vytrvale ignorovala důležitou otázku: a co patch kevent, který do jisté míry řeší stejné problémy? Motivací pro první patch s fibrily bylo poskytnutí ucelené podpory asynchronního I/O - a to byl i jeden z důvodů pro kevent. Takže je zvláštní, že si diskuze kevent nevšímala.
Nakonec se však o kevent přeci jen začalo mluvit, což vyústilo v zajímavou výměnu názorů mezi vývojářem kevent Jevgenijem Poljakovem, vývojářem threadletů (a všeho možného) Ingo Molnarem a několika dalšími lidmi. Vzduchem létaly výsledky benchmarků ukazující výkonnostní charakteristiky obou přístupů, ale hlavní otázka zní takto: která metoda je nejlepší k tomu, aby mohly uživatelské aplikace škálovatelným způsobem pracovat s několika operacemi najednou?
Jevgenij svoji argumentaci zakládá na tom, že přístup založený na událostech je přirozeně snadněji škálovatelný než použití vláken. Říká k tomu:
Pokud něco znatelně snižuje výkon, je to špatné, ale je to také záležitost vkusu. Kevents jsou však každopádně malé, kdežto vlákna jsou velmi velká - a v obou případech je to záměr. Vlákna slouží ke zpracovávání jakéhokoliv kódu, kevents se používají k čekání na události - a IO je taková událost. Ke zpracování není potřeba velká infrastruktura - jen jednoduché kousky, takže to lze optimalizovat, aby bylo vše extrémně rychlé. S velikou infrastrukturou za každým IO (jako v případě samostatných vláken) to nejde udělat efektivně.
Jinými slovy, používání vláken pro správu událostí je prostě příliš pomalé. David Miller také argumentoval tím, že vlákna nejsou vhodná pro síťové úlohy. Jednou z velkých výhod threadletů je to, že jsou velmi rychlé, když nedojde k blokování. Pří síťování se však blokování normálně očekává. Vícevláknová síťová aplikace by tak mohla v krátké době vytvořit obrovské množství vláken. Síťování je prostě činnost založená na událostech.
Ingo nesouhlasí s tím, že by používání vláken a plánovače bylo pomalejší než udržování seznamů úkolů, které se promění na události:
Podle mě je situace následující: fronta úloh plánovače [scheduler runqueue] je z koncepčního hlediska nahromaděná práce (pak jsou také registry, ale ty už jsou hardwarově optimalizované až na kost). Takže ať už je při plánování jakákoli režie, jde o čistě softwarovou záležitost...
A teď si představte kevent jako model pro řazení do fronty. Nedává to do fronty 'úlohy', ale v podstatě nechává uživatelský prostor, aby do fronty zařazoval své požadavky v různém stavu. Ale koncepčně je to stále to samé: paměťový buffer s přiřazeným stavem. Pravda, není to ničím zatíženo, nemá to žádné priority ani připojené koncepty pro zařazování do fronty... zatím. Pokud by však rozhraní kevent začalo být používáno, vznikl by nátlak na začlenění 'pokročilejšího' řazení událostí do fronty a plánování událostí. Byla by potřeba podpora priorit atd.
Jde o to, že plánovač byl během let brutálně optimalizován. Vlastní režie přepínání kontextu je docela malá - možná i menší než režie systémového volání pro správu událostí. Jediným opravdovým rozdílem je to, že paměťová režie při udržování vláken je o dost vyšší než režie kevents. Ale Ingo tvrdí, že by to neměl být neřešitelný problém.
Hlavní věc je však náročnost programování - jak na straně jádra, tak v uživatelském prostoru. V uživatelském prostoru potřebuje klasická, na událostech založená aplikace centrální smyčku, která se zablokuje pouze při čekání na události. Veškerá opravdová práce v rámci smyčky musí proběhnout bez blokování; kdyby se smyčka zablokovala, nahromadily by se události, ale aplikace by při tom nic nedělala. Blokování na špatném místě může poslat výkon do kytek. Ale předcházení blokování za každou cenu je přinejmenším obtížné a někdy úplně nemožné. Threadlety vývojáři aplikace umožní, aby se o blokování přestal starat; pokud se operace zablokuje, aplikace prostě pokračuje v nově vytvořeném vláknu.
Obecněji řečeno, programy psané jako stavové stroje - styl vynucený modely založenými na událostech - bývají pro mnoho lidí těžko srozumitelné. A existuje několik jaderných operací (například otevírání souboru), které se mohou zablokovat na mnoha místech, a které prostě nelze naprogramovat ve stylu stavových strojů. Vícevláknové programy mají pro programátory, kteří nejsou připraveni uvažovat o otázkách souběžnosti, také připraveny různé nástrahy, ale přesto bývají snáze pochopitelné. Threadlety by mělo být relativně snadné programovat, protože umožňují implementaci jakékoliv sekvence volání ve vláknovém modelu. Taková je alespoň argumentace.
A týká se to i jádra. Snaha o přidání asynchronního I/O založeného na událostech zaměstnávala množství velmi schopných vývojářů celé roky - a pořád je daleko k cíli. Vyžaduje to přidání zcela nové infrastruktury a aplikaci technik stavových strojů na zjevně sekvenční série událostí. Komplexnost patchů s asynchronním bufferovaným souborovým I/O to dokládá: na tomto kódu se pracovalo roky (chvíli ano, chvíli ne) a pořád není v hlavním stromě. A navíc u některých operací stále závisí na worker threads [pomocná vlákna]. Naproti tomu o threadletech jejich proponenti tvrdí, že umožňují spuštění jakéhokoliv systémového volání asynchronně, ačkoliv nepřidávají žádné složitosti ani režii.
Diskuze nakonec dospěla do bodu, kdy zasáhl Linus. Podle něj nejde o volbu mezi mechanismem založeným na událostech nebo vláknech, protože existuje místo pro oba:
Pro události používejte select/poll/epoll/kevent/cojávím. Ale PŘESTAŇTE TVRDIT, že byste pro to používali threadlety/syslety/AIO... Mechanismy zaměřené na události jsou pro události *lepší*. Ale zároveň jsou k *ničemu*, když se nejedná o události, ale o spouštění kódu, který se může na různých místech zablokovat.
Z tohoto pohledu nejde o vybrání jednoho nebo druhého, ale o poskytnutí obojího, aby mohl být pro každou práci zvolen nejvhodnější nástroj. Vypadá to, že tento názor sdílí mnoho lidí, což znamená, že asynchronní mechanismus se v nějaké formě zanedlouho do jádra dostane. Rozhraní založená na událostech budou i nadále podporovaná; velká otázka však je, jestli jsou stávající rozhraní (především epoll) dostatečná, nebo by bylo dobré začlenit i kevents.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
[Bluetooth] Add support for using the HID subsystemale v LWN to bylo interpretováno jako:
HID support in the Bluetooth subsystem------- Opraveno.
22.3.2007 08:57