Portál AbcLinuxu, 6. června 2024 06:33
Stav vydání jádra. Citáty týdne: Kees Cook, Nicolas Pitre a Linus Torvalds. Status Eudyptula Challenge Jaderný podcast. Rozhraní pro správu cache síťových souborových systémů.
Současné vývojové jádro je 4.11-rc4, vydané 26. března. Linus k tomu řekl: „Celkově to vypadá dobře. Změny jsou všude a většinou v obvyklých proporcích. Nějaký kód z ústřední části jádra se v diffstatu objevuje častěji než obvykle – museli jsme opravit audit a hashovací tabulku bpf, ale celkově vypadá vše normálně.“
Stabilní aktualizace: 4.10.6, 4.9.18 a 4.4.57 byly vydány 27. března.
Miluju správce, kteří dovedou cestovat v čase! Jsou velmi tolerantní k lidem, kteří jako první dvakrát nezkontrolují -next.
Většina cílových IOT zařízení je tak malá, že pro ně lidé přepisují operační systémy od píky. To je spousta fragmentace. Bavíme se o systémech, které mají méně než jeden megabajt RAM, občas i mnohem méně. I přesto jsou připojeny k internetu. A přesně tohle bude absolutní bezpečnostní noční můra.
Přál bych si, aby bylo možné využít linuxový ekosystém v co největší části oblasti IOT, aby se zabránilo nejhorším z těch nočních můr.
Kód by měl dávat smysl, jinak nebude možné ho udržovat. Jména jsou důležitá. Pokud kód neodpovídá jménu funkce, jedná se o chybu bez ohledu na to, zda daný kód má sémantický efekt nebo ne, protože nakonec se najde někdo, kdo bude na _očekávané_ sémantice záviset.
Eudyptula Challenge představuje sérii programovacích cvičení pro linuxový jádro. Začíná od základního jaderného modulu „Hello world“ a roste v náročnosti až k přijetí patchů do hlavního jádra. Soutěž se uzavře za několik měsíců, až se přihlásí 20 tisíc účastníků. LWN se Eudyptula Challenge věnovalo v roce 2014, když šlo o poměrně novou záležitost. Tentokrát se přihlásilo přes 19 000 účastníků a pouze 149 jich výzvu naplnilo.
Byl vydán jaderný podcast z 28. března. „V tomto vydání: Linus Torvalds oznamuje 4.11-rc4, časné ladění s USB3 earlycon, nadcházející podpora USB-C ve vydání 4.12 a probíhající vývoj, včetně různých prací na zrychlení zavádění systému, logování, futexech a IOMMU.“
David Howells na prvním sezení věnovaném souborovým systémům na letošním linuxovém summitu o úložištích, souborových systémech a správě paměti vedl diskuzi o rozhraní pro správu cache síťových souborových systémů. V případě CIFS, AFS, NFS, Plan9 a dalších vyvstává potřeba uživatelského prostoru moct explicitně zapsat obsah cache, připnout něco do cache a nastavit různé parametry cache. Howells by byl rád, kdyby pro tyto účely do jádra přibyl nějaký obecný mechanismus.
Tímto obecným mechanismem by mohly být příkazy ioctl() nebo něco jiného, řekl. Mělo by to fungovat i s cíli, které nebudeme moct otevřít, a s přípojnými body, aniž by došlo k automatickému připojení. Měly by existovat nějaké dotazovací operace, jež by určily, zda je soubor v cache, jak velká je tato cache a zda v ní došlo k nějakým změnám (tj. zda je dirty). Některé z nich budou použity k podpoře operací na odpojených síťových souborových systémech.
Některé parametry cache by byly také nastavovány skrze toto rozhraní. Například zda je objekt možné kešovat, rezervace prostoru, limity cache nebo která cache by měla být použita – to všechno jsou atributy, které by mohlo být potřeba nastavit. Není jasné, zda by tato nastavení měla platit pouze pro jednotlivé soubory, svazky nebo podstromy, řekl.
Operace bez připojení souborového systému vyžaduje schopnost připnout podstromy do cache a sdělit souborovému systému, aby je neodstraňoval. Pokud v souboru na serveru dojde ke změně, zatímco je v odpojeném režimu, je k dispozici několik nástrojů sloužících ke sloučení souborů. Ale změny ve struktuře adresáře apod. by mohly vést k souborům, které se nedají otevřít obvyklým způsobem. Souborový systém by musel vrátit hodnotu ECONFLICT nebo něco na ten způsob, aby naznačil, že jde o tento druh problému.
Howells navrhl nové systémové volání, které by vypadalo takto:
fcachectl(int dirfd, const char *pathname, unsigned flags,
const char *cmd, char *result, size_t *result_len);
Trochu to rozvedl ve svém příspěvku o navrhovaném rozhraní v e-mailové konferenci linux-fsdevel.
Objevily se námitky týkající se používání parametrů drifd a pathname, Jan Kára navrhl předávání deskriptoru souboru. Howells se obává, že by jádro kvůli konfliktům nemuselo zvládnout rozluštit cestu k souboru nebo by nemuselo zvládnout otevřít soubor na konci cesty kvůli konfliktním adresářům. Al Viro řekl, že tyto by mělo být možné otevřít pomocí O_PATH.
Trond Myklebust se zeptal, co by toto rozhraní používalo. Howellsova odpověď zněla: nástroje pro správu „v širším slova smyslu“. Většina aplikací by rozhraní nepoužívala, ale existuje skupina nástrojů AFS, které spravují cache skrze rozhraní ioctl() (pioctl()) založené na cestách (které není mezi linuxovými vývojáři oblíbené). Jeffa Laytona zajímalo, zda je to hlavně kvůli operacím v odpojeném stavu, ale Howells řekl, že jsou i jiná využití, „která se cache týkají.“ Řekl, že se jedná o případ, kdy by rád „zabil co nejvíc much jednou ranou.“
Rozhraní příkazových řetězců (cmd) je dalším zdrojem starostí. Josef Bacik uvažoval, že by použití rozhraní netlinku dávalo větší smysl než vytvoření nového systémového volání, které by parsovalo příkazový řetězec. Howells nechtěl mít více systémových volání, takže řetězec příkazů je zamýšlen tak, že by se tomu měl vyhnout. Bacik řekl, že i když vypadá netlink otravně, ve skutečnosti se používá opravdu dobře. Howells pak řekl, že se tedy na netlink podívá.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.