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.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Současné vývojové jádro je 2.6.39-rc5 vydané 26. dubna. Linus říká:
Všechny detaily vizte v kompletním changelogu.
Stabilní aktualizace: 21. dubna vyšla aktualizace 2.6.38.4; 2.6.32.39 a 2.6.33.12 následovaly o den později; všechny obsahují další dlouhý seznam důležitých oprav.
Aktualizace 2.6.27.59 a 2.6.35.13 se revidují v době psaní tohoto článku; lze je očekávat 28. dubna nebo později.
-- Vítaný návrat Ala Viro
napsal Jonathan Corbet, 27. dubna 2011
Sada patchů pro škálovatelnost dentry cache byla začleněna do jádra 2.6.38; funguje tak, že se pokusí vyhledat cestu bez držení jakýchkoliv zámků. To, že struktury dentry budou existovat po celou dobu vyhledávání cesty, zajišťuje mechanismus čtení-kopírování-aktualizace [read-copy-update, RCU]. Tato sada patchů odstranila významný problém škálovatelnosti jádra a významně zlepšila dobu vyhledávání. Až na to, že, jak se ukázalo, vždycky to takhle nefunguje. Do 2.6.39-rc5 byla začleněna sada patchů – ve vývojovém cyklu o dost později, než by jeden očekával – která tento problém pomáhá řešit.
Fakt, že rychlá cesta vyhledávání cesty běží pod RCU, znamená, že žádná operace nesmí blokovat. Jakmile se ukáže, že vyhledávání nelze provést bez blokování (například pokud se záznam o adresáři musí načíst z disku), vyhledávání rychlou cestou se zruší a celý proces začne znovu v pomalém režimu. V kódu v jádře 2.6.38 pouhá přítomnost bezpečnostních modulů stačila k tomu, aby se jádro vždy muselo vrátit k pomalé cestě, a to i když žádný modul není aktivní. Tak to bylo, protože si nikdo nenašel čas ověřit, jestli jsou kontroly inode_permission() v bezpečnostních modulech bezpečné s RCU, nebo ne. Když jsou tedy zapnuty bezpečnostní moduly, výsledkem je nejenom to, že výhody týkající se škálovatelnosti v 2.6.38 nejsou k dispozici; ve skutečnosti kód běží pomaleji než v 2.6.37.
Podnikové distribuce mají tendenci povolit bezpečnostní moduly, takže problémy s výkonností jsou realitou. V reakci na to se Andi Kleen podíval do kódu a zjistil, že zlepšení situace není tak těžké; jeho patche byly počátkem toho, co nakonec bylo začleněno do 2.6.39. Andi začal tím, že bezpečnostním modulům umožnil rozhodnout se, jestli dokážou bezpečně provést kontrolu práv v režimu RCU nebo ne; výchozí je návrat k pomalému režimu. Vzhledem k tomu, že výchozí kontrola inode_permission() nedělá nic, šlo snadno zajistit, aby ji bylo možné bezpečně použít v RCU režimu; jenom tato změna stačí k tomu, aby systémy, na kterých jsou povoleny bezpečnostní moduly, ale kde není žádný modul aktivní, mohly používat rychlou cestu.
Když se díval dál, zjistil Andi, že jak SELinux, tak SMACK již při kontrole oprávnění používají RCU. Vzhledem k tomu, že tento kód již je bezpečně použitelný s RCU, jeho rozšíření tak, aby bylo z hlediska RCU bezpečné i ověřování oprávnění, bylo relativně přímočaré. Jediný zbývající háček se objevuje v situaci, kdy je povolen audit [auditing]; ten není bezpečný, takže na takových systémech se věci zpomalí. V ostatních případech by nicméně výhody plynoucí z práce na škálovatelnosti dcache měly být rozšířeny i na systémy, kde jsou přítomny bezpečnostní moduly – tedy za předpokladu, že patche v takto pozdní fázi vývojového cyklu nezpůsobí regrese, kvůli kterým by je bylo potřeba odstranit.
napsal Jonathan Corbet, 26. dubna 2011
Roku 2007 se čtenáři Jaderných novin dozvěděli o volbách SEEK_HOLE a SEEK_DATA pro systémové volání lseek(). Tyto volby umožňují aplikaci zmapovat „díry“ v řídkém souboru; původně byly implementovány v Solarisu pro souborový systém ZFS. V té době bylo toto rozšíření pro Linux odmítnuto; vývojáři souborových systémů měli za to, že mají lepší způsob, jak problém vyřešit. Nakonec se ale může ukázat, že lepší způsob měli lidé od Solarisu.
Souborové systémy v POSIXových operačních systémech nemusí alokovat bloky pro soubory, pokud by tyto bloky obsahovaly pouze nuly. Rozsah v souboru, pro který nejsou alokovány žádné bloky, se nazývá „díra“. Aplikace, která se z díry pokusí číst, dostane jenom nuly; ve většině případů přitom ani neví, že ve skutečnosti nebylo nic alokováno. Soubory s dírami jsou relativně vzácné, ale některé aplikace „řídké“ soubory vytváří, když je tím efektivnější jejich ukládání.
Ve většině případů se aplikace nemusí dírami zabývat, ale jsou tu výjimky. Zálohovací nástroje mohou ušetřit místo na úložišti, pokud si všimnou děr v souborech a zachovají je. Jednoduché nástroje, jako je cp, mohou také, pokud o dírách ví, zajistit, aby se díry nekopírovaly a nevyplňovaly nulami, když se pořizuje kopie souboru. Dává tedy smysl, aby operační systém poskytoval aplikacím způsob, jak zjistit, kde jsou v souborech díry – pokud tam nějaké jsou.
Rozhraní, které vzniklo v Sunu, používalo systémové volání lseek(), které se normálně používá pro změnu pozice v souboru, odkud se čte a kam se zapisuje. Pokud se lseek() předá SEEK_HOLE, pozice v souboru se přesune na začátek první díry, která začíná za specifikovanou pozicí. SEEK_DATA naopak přesune na začátek první oblasti, která začíná za danou pozicí a která není dírou. „Díra“ je v tomto případě definována jako rozsah nul, který nicméně nemusí odpovídat blokům, které byly ze souboru opravdu vynechány; v praxi nicméně téměř vždy bude. Souborové systémy nemusí vědět o dírách a ani je nemusí hlásit; SEEK_HOLE je optimalizace, ne prostředek pro vygenerování 100% přesné mapy každého místa, kde soubor obsahuje nuly.
Když Josef Bačík roku 2007 zaslal patch pro SEEK_HOLE, obdržel komentáře jako je tento:
Patch tedy nebyl začleněn. Místo něj jsme získali novou ioctl() operaci nazvanou FIEMAP. Není pochyb o tom, že FIEMAP je mocnější operace; umožňuje precizní mapování rozsahů v souboru včetně informací o tom, které rozsahy byly alokovány, ale ještě nebyly zapsány, a které rozsahy byly již zapsány, ale ještě nemají přiřazeno přesné číslo bloku. Jedním systémovým voláním lze získat informace pro všechny rozsahy. S takovýmto rozhraním se mělo za to, že SEEK_HOLE není potřeba.
Nedávno nicméně Josef zaslal nový patch SEEK_HOLE s komentářem:
Rychlým hledáním na netu lze najít dlouhý seznam hlášení chyb týkajících se FIEMAP. Některá z nich jsou jednoduše chyby v implementacích specifických souborových systémů, příkladem budiž problém spojený se zpožděnou alokací, který byl objeven v únoru. Jiné souvisí s poměrně komplikovanou sémantikou některých možností FIEMAP a například s tím, jestli musí být soubor již uložen na disku předtím, než je možné tuto operaci použít. A jiné se zjevně týkají složitosti samotného systémového volání. Výsledkem je dlouhý seznam hlášení o poškozených souborech – to rozhodně není něco, co vývojáři souborových systémů ve svých schránkách chtějí.
Zdá se, že FIEMAP je mocný nástroj s ostrými hranami, který dostávají do rukou aplikace, které chtěly nůž na máslo. Když dojde na jednoduché hledání toho, které části souborů není potřeba kopírovat, jednoduché rozhraní jako SEEK_HOLE vypadá vhodněji. Dá se předpokládat, že tentokrát se tedy toto rozhraní do jádra dostane.
Zdá se nicméně, že bude nejdříve potřeba pár úprav. API zaslané Josefem nedělá přesně to, co dělá Solaris; přidávat API, které není kompatibilní s existující implementací, nedává smysl. Také je zde otázka, co se má stát, pokud souborový systém neimplementuje volby SEEK_HOLE a SEEK_DATA; současný patch v této situaci vrátí EINVAL. Byla navržena alternativa, která by přidávala implementaci na úrovni VFS, ve které by se předpokládalo, že v souboru žádné díry nejsou. API by tak bylo zdánlivě podporováno na všech souborových systémech a odstranilo by to jednu chybu, kterou by aplikace musely ošetřovat.
Až se tyto detaily vyřeší – a napíší se odpovídající manuálové stránky – mohly by patche SEEK_HOLE tentokrát být začleněny. FIEMAP bude pro aplikace, které potřebují více detailů o rozložení souborů na disku, existovat i nadále; příkladem takové aplikace jsou nástroje, které se snaží optimalizovat dopředné čtení při bootu. Pro všechno ostatní by tu nicméně měla – konečně – být jednodušší možnost.
napsal Jonathan Corbet, 27. dubna 2011
Snaha přidat do architektury ARM správné abstrakce a odstranit duplikace kódu pokračuje. Jednou z oblasti, kde se jasně vyskytují problémy, je správa DMA paměti. Architektura ARM přináší do této oblasti unikátní problémy, ne všechny jsou ale specifické pro ARM. Také vidíme zajímavý náhled na budoucnost, kde bude složitější hardware vyžadovat nové mechanismy v jádře, aby fungovalo správně.
Jedním z pokroků, které vidíme u ARM, je poněkud opožděné přidání jednotek pro správu I/O paměti [I/O memory management unit, IOMMU]. IOMMU sedí mezi zařízením a hlavní pamětí a překládá adresy mezi nimi. Nejzjevnější účel IOMMU je, že fyzicky rozdrobená paměť se pro zařízení může zdát jako spojitá, což zjednodušuje velké DMA přenosy. IOMMU může také omezit DMA přístup jenom do specifikovaného rozsahu paměti, čímž do systému přibývá jedna ochranná vrstva – i když pomineme obavy o bezpečnost, zařízení, které čmárá na náhodné místo v paměti, může způsobit nekončící řadu těžko laditelných problémů.
S tím, jak se tato vymoženost dostala na ARM systémy, vytvořili vývojáři přesně v duchu práce s ARM speciální rozhraní pro správu IOMMU. Problém je v tom, že jádro již takové rozhraní má – je to API DMA. Ovladače, které toto API používají, by měly fungovat téměř na jakékoliv architektuře; všechny s tím spojené problémy včetně koherence cache, programování IOMMU a přeskakující zásobníky [bounce buffer] jsou krásně skryty. Zdá se tedy jasné, že ovladače pro ARM by toto API měly používat také; správce ARM Russel King to nedávno řekl bez jakýchkoliv pochybností.
Na architektuře ARM nicméně používání DMA API má několik zajímavých háčků. Většina problémů pochází z toho, že architektura jako taková není schopna vypořádat se s vícenásobnými mapováními stránek, pokud tato mapování nesdílí stejné atributy. To je problém, který se objevil již dříve; více informací vizte v tomto článku. V kontextu DMA je poměrně snadné vytvořit mapování s konfliktními atributy a záležitosti spojené s výkonností pravděpodobně způsobí, že těchto konfliktů bude ještě více.
Dlouho existující DMA buffery se typicky alokují dma_alloc_coherent(); z jména lze odvodit, že tato mapování jsou koherentní z hlediska cache. Dlouho známý problém (nejenom u ARM) je v tom, že některé ovladače potřebují velké a fyzicky spojité DMA oblasti, které může být těžké sehnat, když systém již delší dobu běží. Zkoušelo se mnoho řešení tohoto problému; většina z nich, jako je CMA alokátor, vyžaduje si během bootu dát nějakou paměť stranou. Používání této paměti na ARM může být nebezpečné, protože může být mapována jako paměť zařízení, což vede na problém s konfliktními atributy.
V nedávné době se objevil další problém: v některých případech chtějí vývojáři tuto DMA paměť nastavit jako necachovanou. Vzhledem k tomu, že hlavní paměť je již do adresového prostoru jádra mapována jako cachovaná, není možné ji namapovat jako necachovanou v jiném kontextu a neporušit přitom pravidla. Vzhledem k tomuto konfliktu bychom se mohli ptát (a někteří vývojáři to udělali), k čemu jsou necachovaná DMA mapování dobrá. Důvod vysvětlila Rebecca Schultz Zavin – souvisí s grafikou. Je běžné, že aplikace naplní paměť obrázky a texturami a následně je předá GPU, aniž by na ně dál sahala. V takové situaci není důvod mít tuto paměť v cache CPU; ve skutečnosti to dokonce může zhoršit výkonnost. Vypnutí cachování (ale se zachováním kombinovaného zápisu [write combining]) výkonnost značně vylepšuje.
Vyšší rychlost ale nikdo neocení, když se CPU bude chovat podivně poté, co narazí na vícenásobná mapování s různými atributy. Rebeca vyjmenovala několik možných řešení tohoto problému; některá byla zkoušena již dříve a žádné není považováno za ideální. Jedním je odložit si paměť při bootu – což se občas dělá kvůli velkým bufferům – a nikdy ji nemapovat do adresového prostoru jádra. Další přístup je použít pro tyto buffery horní paměť – ta se do adresového prostoru jádra normálně nemapuje. Systémy založené na ARM typicky horní paměť nepotřebují, ale až se budou dodávat zařízení s 1GB (či více) paměti, horní paměť se začne používat. Poslední alternativa je poladit atributy jaderného mapování dané paměti. To by bylo trochu záludné; tato paměť se mapuje s velkými stránkami, které by se musely dělit na kousky.
Tyto problémy – a další – shrnul v „to do“ seznamu Arnd Bergmann. Narovnat toto rozhraní bude zjevně znamenat spoustu práce a to i přes problémy, které z toho plynou. Na horizontu se nicméně objevil další mrak, protože čím dál více je potřeba tyto buffery mezi zařízeními sdílet. Jeden příklad lze nalézt v tomto patchi, který se pokouší vytvářet grafické overlaye jako regulérní objekty v prostředí jaderného nastavování režimu grafiky [kernel mode setting]. Overlaye nabízí způsob, jak zobrazit (většinou) rychle se měnící grafiku nad tím, co dělá správce oken; tradičně se používají pro přehrávání videa. Často chceme vzít obraz přímo z kamery a zobrazit jej na obrazovce, pokud možno bez účasti uživatelského prostoru. Tyto nové overlaye, pokud se správně propojí s konceptem overlayí ve Video4Linux, by to měly umožnit.
Hardware je čím dál tím sofistikovanější a důsledkem toho je, že jsou čím dál složitější i jeho ovladače. Periferní zařízení jsou v dnešní době často sama o sobě relativně schopné počítače; lze je naprogramovat a pak je delší dobu nechat pracovat samostatně. Je jenom přirozené, když chceme, aby tyto periférie byly schopny samostatně spolupracovat. Paměť je prostředkem, pomocí kterého mohou komunikovat, takže potřebujeme mechanismus pro alokaci a správu paměti, který bude v takovém prostředí fungovat. Objevily se návrhy, že by správce paměti GEM – v současnosti používaný pro GPU – šlo zobecnit tak, aby mohl v takovém režimu pracovat.
Zatím nikdo skutečně nepopsal, jak by tohle všechno mohlo fungovat, a tím pádem ani nikdo nezaslal patche. Vyřešit všechny záležitosti s tím spojené zjevně zabere nějaký čas. Vypadá to jako zábavná výzva pro ty, kdo by chtěli pomoci nastavit směr, kterým se jádro bude ubírat v budoucnosti.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Viro jako Ďuričko.Tak o tomhle vzorovém slově slyším poprvé...
9.5.2011 15:50
Xgamer | skóre: 4
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz