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í verze jádra je i nadále 2.6.24-rc5; v minulém týdnu nevyšly žádné nové předverze. Do hlavního repozitáře však i nadále proudí opravy.
Aktuální verze -mm stromu je 2.6.24-rc5-mm1. Mezi nedávné změny patří výrazné změny modelu zařízení; kvůli konfliktům patchů bylo z této verze vynecháno dost stromů subsystémů.
Aktuální stabilní jádro řady 2.6 je 2.6.23.10 2.6.23.11 2.6.23.12. Velký patch 2.6.23.10, který vyšel 14. prosince, obsahoval několik desítek oprav. 2.6.23.11 (14. prosince) a 2.6.23.12 (18. prosince) obsahují malé opravy problémů způsobených verzí 2.6.23.10.
Starší jádra: 2.6.22.15 vyšlo 14. prosince se slušnou řádkou oprav.
2.4.36-rc1 bylo vydáno 17. prosince s několika bezpečnostními opravami. 2.4.35.5 obsahuje stejné opravy.
Pro představu... mám:
Což všechno znamená, že je trochu nevhodné uvažovat o nových funkcích, které vypadají, že budou mít velký dopad.
Takže mi to celé pošlete aplikovatelné na rc5-mm1 a já to tam vrazím - uvidíme, co přestane fungovat.
OK, a vzhledem k časovému posunu a ročnímu období si večer sednu a budu sledovat, jak padá sníh, a spokojeně snít o koťátkách s uzi samopaly s municí s nukleárními hroty, které loví super-elitní vývojáře bezdrátového síťování, aby do nich vtloukli trochu lidskosti a pochopení, OK?
-- Ingo Molnár
Významnou součástí práce vývojáře je stanovování priorit [triage]. Tak velký a používaný projekt jako jádro bude mít pořád více hlášení o chybách, než kolika by bylo reálně možné se v dostupném čase věnovat. Vývojáři tedy musí zjistit, které problémy stojí za to, aby jim věnovali svou pozornost. Někdy to rozhodování usnadní přítomnost naštvaného zákazníka. Jindy je však třeba uhádnout, které chyby se dotýkají největšího počtu uživatelů. A to se často pozná podle toho, kolik různých hlášení o daném problému přišlo.
Počítání hlášení však není nic jednoduchého - zvláště pokud nejsou na stejném místě. Ve snaze celý proces zjednodušit, Arjan van de Ven oznámil nové stránky kerneloops.org. Arjan dal dohromady software, který na určitých stránkách a konferencích vyhledává poslané výstupy jaderných oops; každý nalezený pád je nacpán do databáze. Pak se program pokusí propojit hlášení pomocí verze jádra a obsahu výpisu [call trace]; z toho lze pak vytvořit seznam nejoblíbenějších způsobů, jak shodit systém. V tuto chvíli to vypadá, že nejvíce v kurzu mezi oopsy vývojových jader je ieee80211_tx(). Kromě toho se ukládají i některé další informace; konkrétně je možné zjistit, která nejstarší verze jádra ještě daným oopsem trpí.
Je to nepochybně užitečný zdroj informací, ale je tu ještě pár problémů, které situaci komplikují. Jedním z nich je skutečnost, že konec výpisu nebývá nijak jednoznačně označen, takže skripty nevědí, kde přestat kopírovat text. Druhá potíž je v tom, že vícenásobná hlášení o stejném oopsu mohou uměle navýšit zaznamenávaný počet u daného pádu. Řešením obou problémů je umístění značky na konec výpisu, která by obsahovala náhodné UUID generované při bootu. Patche, které by to zařídily, jsou již v oběhu, i když se ukazuje, že dostat do výpisů to náhodné číslo je trochu obtížnější, než by se dalo čekat. U 2.6.24 může být "náhodné" číslo složeno ze samých nul, takže vyřešeno to nakonec bude asi až v 2.6.25.
Když se někdo aspoň chvilku šťourá v kódu jádra, tak si všimne mnoha proměnných deklarovaných následujcím způsobem:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
static int __read_mostly ignore_loglevel;
Atribut __read_mostly [většinou čteno] říká, že přístupy k dané proměnné jsou většinou (ale ne vždy) operace typu čtení. Nedávno se objevily dotazy o tom, proč se toto označování provádí. Odpověď je, že jde o důležitou optimalizaci, i když ne vždy má takový účinek, v jaký vývojáři doufali.
Jak je popsáno v What every programmer should know about memory, správné používání paměťové keše je pro optimální výkon klíčové. __read_mostly seskupuje proměnné, které jsou měněny jen výjimečně, aby mohly sdílet řádky keše [cache lines], které by nemusely na víceprocesorových systémech lítat mezi jednotlivými procesory. Dokud proměnnou označenou jako __read_mostly někdo nezmění, může klidně sedět ve sdíleném řádku keše s ostatními takovými proměnnými a být po ruce v keši na všech procesorech systému.
Atribut read-mostly obvykle funguje dobře a poskytuje měřitelné zlepšení výkonu. Existují však obavy, že by tato funkce mohla být využívána až příliš. Andrew Morton to vyjádřil takto:
Takže... až přeměníme všechny většinou čtené proměnné na __read_mostly, co nám zbude v bss? Všechny často zapisované proměnné. Všechny hezky namačkané pohromadě, aby se maximalizovalo sdílení řádků keše.
Kombinování často zapisovaných proměnných do sdílených řádků keše je dobrý způsob, jak maximalizovat přehazování těchto řádků mezi procesory - což by mělo na výkon špatný vliv. Příliš agresívní segregace read-mostly proměnných, aby se minimalizovalo přehazování řádků keše, může mít úplně opačný účinek: výkon jaderné keše by mohl poklesnout.
Podle Andrewa by bylo lepší vytvořit atribut "read often" [často čteno], který by se přiřazoval proměnným často využívaným v režimu pouze pro čtení. To by umožnilo, aby početné málo čtené proměnné vyplnily místo mezi často zapisovanými proměnnými. Zatím však tuto myšlenku nikdo nepřevedl do patche.
Mezi funkcemi, které jádro poskytuje pro přístup k I/O portům, jsou už verze, jež vkládají prodlevy. Ovladač by za normálních okolností přečetl bajt z portu pomocí inb(), ale pokud by po operaci bylo potřeba vložit krátkou prodlevu, může se použít inb_p(). Pohled na ovladače ve stromu jádra prozradí, že tyto přístupy s prodlevou jsou využívány docela často, i když k tomu v mnoha případech není důvod.
Prodleva je (na architekturách x86) implementována pomocí zápisu na I/O port 80. Na tomto portu většinou žádný hardware nenaslouchá, takže zápis pouze způsobí zdržení procesoru, zatímco se sběrnice marně snaží operaci provést. Tato operace má rozumně definovanou sémantiku a funguje už v Linuxu hodně let.
Až na to, že to teď vypadá, jako by tato technika na malé části x86_64 systémů nefungovala. Zápis na port 80 občas způsobí úplné zatuhnutí systému, což má za následek poněkud delší prodlevu, než bylo v plánu. Šlo by si představit komplikovaný mechanismus pro restartování I/O operací po té, co uživatel restartuje systém, ale vývojáři jádra se raději pustili do hledání jiných způsobů, jak implementovat I/O prodlevy.
Skoro ve všech ostatních případech poslouží jako alternativní způsob docílení prodlevy volání udelay(). Největší potíž je však v tom, že udelay() funguje jako smyčka; nemůže vědět, kolikrát se má smyčkou projít, dokud není kalibrována rychlost procesoru. K této kalibraci dochází poměrně záhy v rámci procesu bootování, ale předtím je ještě potřeba provést několik věcí - včetně operací s I/O porty. Problém je zatím obcházen odstraňováním operací s prodlevou z kódu, který je spouštěn příliš brzy, ale někteří vývojáři mají obavy, že se nikdy nepodaří je přesunout všechny. Padl návrh, že až do chvíle, kdy proběhne kalibrace, by jádro mohlo prostě předpokládat, že běží na nejrychlejším možném procesu. Ale kromě toho, že to není moc elegantní, tak by to mohlo výrazně snížit rychlost bootu na pomalejších strojích - které všechny se stávajícím kódem fungují dobře.
Skutečným řešením by bylo se prostě zbavit skoro všech těch operací s prodlevou. Jen velmi málo z nich bude pravděpodobně potřeba pro použití s hardwarem, který se ještě používá. V některých případech je navíc skutečným účelem prodlev kamuflování chyb v ovladačích. Pouhé odstranění prodlev by asi způsobilo nestabilitu na neočekávaných místech, čemuž by se vývojáři raději vyhnuli. Bude se to tedy muset provést opatrně a pomalu. V 2.6.24. zůstane využívání portu 80 asi beze změny.
Naposledy jsme se na patch revoke(), který napsal Pekka Enberg, dívali v červenci 2006. Účelem tohoto volání je kompletně odpojit všechny procesy od určitého souboru, což umožní nějakému novému procesu exkluzivní přístup. Taková funkčnost má mnoho možných uplatnění, například zajištění, že nově přihlášený uživatel bude mít jako jediný přístup ke zdrojům spojeným s konzolí - třeba ke zvukovému zařízení. Jsou také vývojáři jádra, kteří si čas od času výhružně bručí pod vousy o neopravitelných bezpečnostních problémech způsobených absencí možnosti zrušit otevřené popisovače souborů - i když nikdo neví, proč se nechtějí podělit o podrobnosti ohledně těchto chyb. Také jakákoliv opravdová aplikace pro hledání malwaru bude potřebovat mít možnost zrušit přístup k souborům, o kterých zjistí, že obsahují Zlé Věci.
Pekka nedávno poslal novou verzi patche, takže si ji prohlédneme. První věc, které si všimnete, je to, že systémové volání revoke() je pryč; místo toho vypadá nové volání takto:
int revokeat(int dir_fd, const char *filename);
Toto volání je tedy modelováno podle mnoha dalších, poměrně nových systémových volání typu *at(). V tomto případě je filename název souboru, k němuž má být zrušen přístup; pokud jde o absolutní cestu, pak je dir_fd ignorován. Jinak je dir_fd otevřený popisovač souboru ukazující na adresář, který se má použít jako počáteční bod při hledání filename. Hodnota AT_FDCWD určuje aktuální pracovní adresář volajícího procesu. Pokud je volání revokeat() úspěšně dokončeno, budou pro filename platné jen popisovače souborů, které byly vytvořeny až po volání.
Patch také přidává nového člena do file_operations:
int (*revoke)(struct file *filp);
Funkce má na starosti zajistit, aby byly dokončeny všechny zbývající I/O operace s daným souborem - je-li to potřeba, tak i s chybovým stavem. Zatím jediná implementace je obecná verze pro souborové systémy; celá vypadá takto:
int generic_file_revoke(struct file *file)
{
return do_fsync(file, 1);
}
Aby bylo volání revokeat() v budoucnu užitečné, bude potřebovat podporu alespoň v nějakých ovladačích.
Odpojení přístupu k obyčejným popisovačům souborů je poměrně jednoduché; systémové volání prostě prochází seznamem otevřených souborů na příslušném zařízení a nahrazuje strukturu file_operations novou sadou, která vrací EBADF za každý pokus o operaci (OK, skoro každý pokus - čtení ze soketů a souborů zařízení vrací místo toho nulu). Nepříjemné je pouze to, že seznamem souborů se musí projít vícekrát, než budou všechny otevřené soubory odstraněny; jinak by mohly nastat souběhy [race conditions] s jinými systémovými voláními, která vytvářejí nové popisovače souborů ve stejný okamžik, kdy jsou ty staré rušeny.
Složitější je to s mapovanou pamětí. Ve většině případů jde o nalezení všech oblastí virtuální paměti (VMA), které jsou se souborem spojeny. Pak se nastaví příznak VM_REVOKED a zavolá zap_page_range(), aby se pročistily příslušné záznamy v tabulce stránek. Příznak VM_REVOKED zajistí, že jakýkoliv pokus o vrácení stránek [fault pages back] vyústí v signál SIGBUS - to může být nepříjemné překvapení pro jakýkoliv proces, který by se pokoušel k té oblasti přistupovat.
Ještě horší je to v případě privátních copy-on-write (COW) [kopírování při zápisu] mapování, která mohou vzniknout, když se proces rozdělí [fork]. Obyčejné pročištění těchto mapování by mohlo být účinné, ale mohlo by to také způsobit konec procesů, které není potřeba zabíjet. Je však důležité si ohlídat, aby COW mapování nepředstavovalo způsob, jak ztrácet data zapsaná do souboru po volání revokeat(). COW mapování jsou tedy od sebe oddělena jednoduchým (ale nákladným) voláním get_user_pages(), které vytvoří privátní kopie všech relevantních stránek.
O patchi se zatím moc nediskutovalo - možná, že příslušní vývojáři už odjeli na vánoční dovolené a linux-kernel přestali sledovat. Jde však o důležitý patch s mnoha náročnými nízkoúrovňovými operacemi; to je částečně důvod, proč jeho příprava trvala tak dlouho. Než se bude uvažovat o začlenění do hlavního jádra, bude potřeba jej pečlivě zkontrolovat. Vzhledem k povaze problému by nebylo překvapivé, kdyby byly potřeba ještě jedna nebo dvě další verze.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
