IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Aktuální stabilní jádro je 2.6.16.13, vydané 2. května. Tato verze obsahuje jediný patch opravující DoS problém v kódu SCTP. Den předtím byla vydána verze 2.6.16.12 s několika desítkami důležitých oprav.
Aktuální předverze je 2.6.17-rc3, vydaná 26. dubna několik milisekund po vydání LWN Weekly Edition. Jak se očekávalo, jde především o opravy, ale obsahuje i verzi 1.2 TPM, podporu více velikostí stránek pro architekturu PA-RISC a systémové volání vmsplice() (viz níže). Detaily najdete v dlouhém changelogu.
Aktuální -mm strom je 2.6.17-rc3-mm1. Mezi nedávné změny patří optimalizace red-black stromů, nová sada patchů pro migraci stránek, vylepšení RAID (MD), profilovací makro likely() (viz níže) a dlouho odkládané odstranění devfs.
Pro uživatele řady 2.4 vyšlo 2.4.33-pre3; Marcelo verzi oznámil 1. května. Obsahuje menší počet oprav, z nichž mnohé se týkají bezpečnosti.
V lednu představil Van Jacobson svůj koncept síťových kanálů na setkání linux.conf.au. Kanály, které koncentrují síťové zpracovávání formami vyhovujícími SMP systémům, vypadají jako slibný způsob pro zvýšení vysokorychlostní síťové výkonnosti. Návrh vyvolal nemalé nadšení. Od té doby to však vypadá, že se pan Jacobson začal věnovat jiným projektům, takže z jeho práce nevzešel žádný kód. Za posledních pár měsíců se tedy v tomto směru příliš nestalo - nebo to tak alespoň vypadalo.
David Miller nedávno prozradil, že pracuje na své vlastní implementaci kanálů. Nepředpokládal však, že by to mohlo v dohledné době fungovat:
Nečekejte v brzké době nějaký výrazný pokrok, ani cokoliv nad rámec jednoduchého zpracování paketu z kanálu na softint při příjmu.
Cesta až k soketu je obtížná a vyžádá si hodně restrukturalizací, aby to bylo správně. Takže to vyjde na měsíce.
Ukázalo se však, že David nebyl jediný, kdo na tomto nápadu pracoval; Kelly Daly a Rusty Russell také dali dohromady základní implementaci kanálů; v reakci na Davidovu poznámku poslali kód k prohlédnutí. Protože jde o pokročilejší verzi, byla středem většiny diskuzí.
Patch od Daly/Russella vytváří strukturu pojmenovanou struct channel_ring. Ta sestává z 256 stránek paměti souvisle namapovaných do adresního prostoru přijímacího procesu - i když v jádře stránky souvislé nebudou. Jak popisoval Van Jacobson, proměnné používané odesílající stranou budou umístěny na počátku kruhu, zatímco proměnné používané příjemcem budou na konci; toto oddělení pomůže zajistit, aby se kešové linky reprezentující tyto proměnné neodrážely mezi procesory. Proměnné obsahují indexy kruhového bufferu, jež značí, který buffer použijí obě strany příště. Součástí jsou i parametry umožňující příjemci vyžádat probuzení při přidání bufferů do kruhu.
Uživatelský prostor nejprve vytvoří soket s novým typem protokolu PF_VJCHAN, pak pomocí mmap() namapuje kruhový buffer. Potom může buffery využívat podle toho, jak budou dostupné (podle potřeby může použít poll() nebo select() a počkat na více dat). Jakmile přestane být buffer potřeba, uvolní se pro nová data navýšením příslušného indexu.
Rozhraní pro ovladače je zatím docela jednoduché. Buffer může být z daného kruhu alokován voláním vj_get_buffer(); jakmile tam budou síťovým rozhraním uložena data, vj_netif_rx() pošle buffer do protokolového kódu. Obtížné je na tom to, jak dostat každý paket do správného bufferu. Kopírování paketů v rámci jádra by zmařilo účel celého snažení; je důležité, aby si síťové rozhraní zvolilo správný buffer před tím, než pošle pomocí DMA paket s daty do paměti. Současné síťové karty mohou být dostatečně chytré na to, aby to rozhodnutí provedly, ale musí být ovladačem správně naprogramovány.
Stále zbývá vyřešit velké množství problémů. David Miller se zaměřil na prealokované buffery, které považuje za nepružné a těžko změnitelné; raději by měl datovou strukturu s ukazateli. Ale je těžké si představit, jak by to mohlo fungovat, aniž by vznikla režie kvůli mapování bufferů do uživatelského prostoru s každým paketem.
Pravděpodobně ještě složitější záležitost je netfilter. Nekopírovací přístup může být docela rychlý, ale přirozeně také likviduje filtrování paketů, které provádí netfilter. U navázaných spojení je to považováno za přijatelnou cenu. Ale Rusty poukázal na to, že lidi filtrování používají i u navázaných spojení - přinejmenším pro počítání paketů. Shrnul to následovně: Nemůžeme 'uvolnit' implementaci firewallu a zároveň si udržet bezpečnost. Takže bude potřeba najít nějaké řešení.
Další otevřená otázka se týká toho, jestli by měl kanál vést až do uživatelského prostoru. Van Jacobsonova prezentace na linux.conf.au obsahovala i diskuzi o implementaci TCP v uživatelském prostoru, čímž dovedla princip konec-konec [end-to-end] do logického vyústění. Argumentace pro toto řešení je založena na tom, že když jsou data zpracovávána aplikací, znamenalo by vložení kódu protokolu na stejné místo nejrychlejší a na keš nejméně náročný způsob provedení. Ale přesunutí kódu protokolu do uživatelského prostoru také představuje duplikování velké části síťového stacku a větší komplikovanost celého systému. Ponechání kódu protokolu v jádře situaci zjednodušuje a má se za to, že jej lze vyladit tak, aby nabídl stejný výkon. Konkrétně zpracování protokolu může být provedeno na tom samém procesoru jako je cílová aplikace (nezanedbatelná část je tak prováděna už teď), a nekopírovací síťování tak stále bude možné.
Vzhledem k tomu, že většina systémových volání zapojených do příjmu síťových dat (například read() nebo recv()) kopírování dat vynucuje, mluvilo se také o tom, že kopírování by mohlo prostě probíhat v rámci jádra. Ale nejdůležitější je na této věci fakt, že má-li být využit pro zvýšení výkonu síťování potenciál kanálů úplně, bude nutné vyvinout novou sadu uživatelských rozhraní. Slavné soketové rozhraní nebylo vůbec navrženo pro prostředí využívající kanály. Není zcela jasné, jak by takové rozhraní mělo vypadat; mohlo by být založeno na stávajícím API pro asynchronní I/O, na kevents nebo na něčem úplně novém.
Ve zkratce: vývojáři zabývající se síťováním pracují na několika zásadních změnách linuxového přístupu k sítím, ale ještě je toho dost, co je potřeba vyjasnit. Hledají se nové nápady. Je tedy nepravděpodobné, že by se stávající implementace kanálů podobala tomu, co bude jednou začleněno do hlavního jádra. Jde spíše o cvičení určené k lepšímu pochopení skutečného jádra problému. Ale přesto jde o slibný začátek něčeho, co vypadá jako zajímavé vývojové úsilí.
U příležitosti vydání jádra 2.6.17-rc2-mm1 si Andrew Morton postěžoval:
Trvalo mi šest hodin, než bylo možné tuto verzi sestavit a slinkovat na nějakých osmi architekturách. Vymyká se to kontrole...
Mohli by si autoři patchů _prosím_ dávat větší pozor na Kconfig, otestovat různé kombinace (ano, lidi budou občas chtít vypnout vaši skvělou novou funkci) a prostě o věcech trochu více přemýšlet? Není to žádná velká věda.
Vypadá to, že se na Adrewa valí příliš mnoho materiálu, který není téměř vůbec testován. Občas se něco prostě nezkompiluje. Častěji však patche způsobují problémy, když jsou zakázány jejich konfigurační volby, případně na architekturách netestovaných původním vývojářem. Andrew pak tyto problémy opravuje a zabírá to značnou část jeho času. Větší průšvih je však něco jiného:
Hlavním důvodem tohoto fňukání je, že počet chyb naznačuje, jak málo pozornosti lidi své práci věnují. Proklouzává-li tolik triviálních chybiček, co nám to řekne o velkých věcech, tj. chybách, které se projeví za běhu?
Trochu se diskutovalo o tom, jak by bylo možné situaci zlepšit. Pomoci by mohl větší počet automatizovaných kompilačních farem, které by vývojářům zpřístupnily širší testování, a seznam kontrolních úkonů, které mají být provedeny před odesláním patchů. Především je však potřeba, aby si vývojáři prostě dávali větší pozor při přípravě svého kódu.
Patche CKRM (správa zdrojů) nebyly vývojářskou komunitou v minulosti přijaty nadšeně. Mnohým CKRM připadá jako velký kus kódu, který má rozesety háčky [hooks] po celém jádře, ale přitom poskytuje funkce zajímavé jen pro relativně málo uživatelů. Takže návrhy na začlenění CKRM se příliš daleko nedostaly a vývojářský tým se poslední dobou neozýval.
Vývojáři totiž mezitím patche přepracovávali, aby byly lépe přijatelné. Výsledek se nazývá Resource Groups a je opět tlačen do hlavního jádra. Kód Resource Group byl zeštíhlen, množství funkcí bylo odstraněno, jiné vyhozeny do uživatelského prostoru. Duplicitní kód zmizel a bylo věnováno velké úsilí tomu, aby se používaly základní knihovní funkce všude, kde to je možné.
Andrew Morton na nově představený kód reagoval velmi kladně: ...celková kvalita kódu je pravděpodobně nejlepší jakou jsem kdy viděl u prvních verzí patchů podobného rozsahu. Větší starosti mu však dělal navrhovaný řadič paměti, který - jak se zdá - duplikuje hodně kódu subsystému pro správu paměti. Ostatní kód CKRM moc nekomentovali.
Jádro nabízí dvě makra nazývaná likely() a unlikely() (pravděpodobné, nepravděpodobné), která mají kompilátoru nabízet nápovědu ohledně toho, jak asi dopadne test v if. Procesor pak může za běhu tuto nápovědu využít k nasměrování předvídání větvení a ke spekulativním optimalizacím spouštění. Tato makra jsou v jádře dost často používána - odráží to, co si vývojář myslí, že se stane.
Je dobře známé, že programátorům se často špatně odhaduje, které části kódu nakonec spotřebují nejvíce výkonu procesoru. Ukazuje se, že se jim mnohdy nedaří ani odhadnout pravděpodobný směr větvení. Daniel Walker dal dohromady patch, kterým na to chtěl upozornit. Kód vytvoří za běhu profil deklarací likely() a unlikely(). Na výsledném výstupu je vidět, které z těchto deklarací jsou nesprávné a zpomalují jádro.
S pomocí tohoto výstupu píše Hua Zhong (a další) patche opravující nejhorší provinilce; některé z oprav už si našly cestu do hlavního jádra. Přinejmenším v jednom případě výsledky vývojářům ukázaly, že věci nefungují tak, jak by měly, a proto se připravují další opravy.
Jeden výskyt unlikely() však zůstává neopraven: kfree(). Předání NULL ukazatele na kfree() je naprosto v pořádku a proběhlo množství údržbářských patchů, které odstraňovaly kontroly testující ukazatele na NULL, než byly uvolněny. kfree() je naprogramováno s nápovědou, že NULL ukazatel je nepravděpodobný, ale vyšlo najevo, že ve skutečnosti předává funkci kfree() více než polovina volání NULL ukazatele. Ne všichni však souhlasí se změnou nápovědy; vypadá to, že přednost dostane opravení (pravděpodobně) malého počtu širokopásmových volání, která za problémem stojí.
Redaktor LWN Jonathan Corbet minulý týden zachytil začlenění systémového volání vmsplice(), které proběhlo na poslední chvíli. Nevšiml si však skutečnosti, že prototyp vmsplice() se od chvíle, kdy se objevil v konferenci, změnil. Současný prototyp vmsplice() vypadá takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
long vmsplice(int fd, const struct iovec *iov,
unsigned long nr_segs, unsigned int flags);
Použití struktury iovec umožňuje, aby bylo vmsplice() použito pro operace scatter/gather [rozhodit/posbírat].
Od té doby přibyl ve vmsplice() nový parametr: SPLICE_F_GIFT. Je-li parametr nastaven, nabízí volající proces jádru stránky jako "dar". Povolují-li to podmínky, může jádro stránku vzít z adresného prostoru procesu a vyplivnout ji například do stránkové keše. S tímto parametrem může aplikace generovat data v paměti a pak je posílat na místo určení bez kopírování v jádře.
Následující obsah je © KernelTrap
27. dub, originál
Autor anticipatory I/O scheduleru [předvídací plánovač] Nick Piggin už několik měsíců spravuje patch s bezzámkovou keší stránek. V březnu poskytl dokument [PDF], který popisuje bezzámkové radix stromy využívané keší stránek. V dokumentu je rozebrán algoritmus Read-Copy Update (RCU) využívaný ke sdílení dynamických datových struktur bez používání zámků. Jens Axboe nedávno zveřejnil výsledky měření výkonu ukazující, že některé druhy zátěže z bezzámkové keše stránek profitují.
Andrew Morton si Jensovy testy prohlédl a komentoval: To nevypadá jako něco, co by nějaká skutečná aplikace mohla dělat ;-) A připojil: I když je ten graf pěkný, nevnímal bych to jako supersilný argument ve prospěch bezzámkové keše. Linus Torvalds poznamenal: To je pravda, ale na druhou stranu to tak trochu "vytahuje" jednu (malou) část něčeho, co skutečné aplikace doopravdy dělají. Otázkou samozřejmě je, jestli je ta zbývající část (vlastní vyhledávání stránek) natolik důležitá, aby to hrálo roli, je-li to už jednou součástí větší posloupnosti ve skutečné aplikaci.
Andrew také zmínil komplexnost bezzámkové keše stránek. Během probírání výsledků výkonnostních testů se Jens zeptal: Existují případy, ve kterých podává bezzámková keš horší výkon než ta současná? A Andrew opáčil: Jo - když se ji obyčejní smrtelníci snaží pochopit a spravovat. Platí obvyklé kompromisy. Nick uznal, že kód bezzámkové keše je komplikovaný, především RCU radix stromy, ale doufám, že to není tak hrozné. Jde v podstatě o dvanáctiřádkovou funkci v srdci jádra, která se používá pro implementaci find_get_page a find_lock_page. Sémantika zůstává stejná.
28. dub, originál
David Woodhouse nabídl sadu patchů zaměřených na pročištění linuxových hlavičkových souborů. Vysvětlil, že pro distribuci Fedora spravuje balíček glibc-kernheaders a proces synchronizace s novými jádry mu připadá příliš zdlouhavý. Linus Torvalds úsilí ocenil, ale zmínil, že by se začleňováním patchů raději počkal až na začátek vývojového cyklu 2.6.18: No jo, lidi by neměli linuxové hlavičky používat, ale kdyby to nedělali, tyhle patche by byly zbytečné. A když to dělají, tak většinou patche podobné těmto odhalí nějakou obskurní aplikaci, která závisí na stávajících hlavičkách. Grrr.
David reagoval: Hmm, ale my všichni víme, že lidi _musí_ používat jaderné hlavičkové soubory. Nemůžeme jen strčit hlavu do písku a říct "nesmějí to dělat". Jaderné hlavičky obsahují všechny ty šťavnaté věci jako definice struktur a ioctl, které pro komunikaci s jádrem potřebuješ. Potíž je, že nemáme žádná pravidla o tom, jak hlavičky vlastně nabízíme. Nikdy se ani neuvažuje o tom, jak užitečné jsou, nebo jak naše činnost ovlivní uživatelský prostor.
Linus rychle odvětil: Je-li tahle práce pokus o úpravu hlaviček, aby byly lépe stravitelné pro uživatelský prostor, tak to nezačlením. Ne teď, ani zítra, prostě NIKDY. Protože s takovým cílem se momentálně neztotožňuji. A vysvětlil: Je-li to naopak snaha o usnadnění práce lidem, kteří se starají o knihovny, aby měli jednodušší rozhodování o tom, jestli aktualizovat své informace o jádře, pak s tím souhlasím. Ale ta část o "cílovém obecenstvu" je skutečně velmi velmi důležitá. Cílovou skupinou by neměly být aplikace využívající jaderné hlavičkové soubory, ale distribuce a správci knihoven.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
