Názory k článku
Nové systémové volání readfile pro malinké soubory

Úprimne sa čudujem že takéto volanie tam nieje už dávno. Je to vec ktorú potreboval asi každý programátor a napísal si na to svoju funkciu.

Hádám, že brzdou bylo omezení na malé soubory - ortodoxnímu programátorovi se nemusí líbit, že to prostě načte nějaký kousek ze začátku souboru a zbytek to ignoruje. Možná by to mělo vyhodit chybu, pokud je soubor větší než vyhrazený buffer, ale mám dojem, že ta kontrola tam není.

Podle https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=readfile&id=566a6e8de20726a9fc54b72b814e273f99360680 to skutečně vypadá, že skutečně chybí signalizace příliš velkého souboru, což je IMHO error-prone. Je to docela low-level funkce, okolo které asi vznikne nějaký wrapper, který to bude řešit, Ale kdybych měl psát efektivní wrapper, moc by mě nepotěšilo, kdybych potřeboval alokovat 1B navíc na konci bufferu. Pokud dostanu již alokovanou paměť, moc s tím neudělám, leda bych mohl alokovat další buffer, jehož obsah bych překopíroval. Pokud mám paměť alokovat sám, možnost tu je (realloc), ale přijde mi to takové přes ruku.

Tak ten wrapper bude muset volat systém (a tím jde celá optimalizace do kopru), nebo to bude rovnák na vohejbák. A přitom by stačilo tak málo.

Tak kernel to určitě volat muset bude, ale stačí jednou. A o tom je ta optimalizace.

Kernelové funkce jsou low-level, a I takové fopen je wrapper nad nimi. IMHO není hlavním cílem kernelových funkcí nabízet co nejpřívětivější rozhraní. Spíš bych po nich chtěl, aby nabízely stabilní API s dobrou zpětnou kompatibilitou (mít dvě verze glibc je oproti dvěma verzím glibc vlastně pohoda), co nejmenší riziko chyb (i pád nebo zmatené chování aplikace je izolovanější problém než u kernelu), a to i bezpečnostních.

no, já si myslím, že hlavní problém je, že ani samotný kód neví, jestli přečetl celý soubor nebo jen jeho část, musel by soubor číst ve smičce a zkusit přečíst další data. To nám má asi signalizovat do slovo "jednoduchý".

Co o to, nastavit buffer dostatečně velký a přidat error/fallback v případě naplnění bufferu po okraj.

Jsou tu dvě věci: pohodlí programátora a efektivita.

Pro pohodlí programátora tato funkce vlastně vůbec není potřeba, něco podobného (ale i pro větší soubory) je implementováno již dávno pro spoustu jazyků. A pokud by šlo jen o pohodlí programátora, taková funkce by IMHO do kernelu ani nepatřila. API jádra je celkem konzervativní, IMHO z dobrých důvodů.

Pro efektivitu to má význam. Nevím, proč to tu přibylo až teď – jestli se zvýšila potřeba efektivně číst malé soubory, nebo jestli to vyšlo třeba z nějaké analýzy, nebo ještě něco jiného.

Ano, tohle není pro programátory, ti to neocení a stejně open/read/close není nikterak velká složitost a ve vyšších jazycích to je schované.

Hlavní důvod je za mě zamezení propadu výkonu při nových záplatách kolem heartbleed a navazujících, kdy každý cntx switch znamená značnou režiji a kvůli malému souboru switchovat 3x je prostě moc. Tenhle patch má podle mě řešit přesně tohle.

Ale nějak nerozumím tomu proč není use case lépe popsaný, proč nejsou testy, proč není zdůvodnění, ten man page dokonce i chybně popisuje jak se to chová. Je to bordel. Tohle nepatří do základního abi, je to pseudorozhraní nad jinými voláními a přitom se nijak nezdůvodňuje, neobhajuje, prostě se to přidá.

Chápu, že pro Grega to je malé svičení, možná k tomuhle má sakra dobrý důvod, ale někam mu vypadlo se o něj podělit a lépe to uvést. V tomhle stavu by se to nemělo příjmout, ale to bych asi chtěl hodně.

kdyby radeji zavedli vektorove fstat()... protoze to volat na 20M souboru v 1M adresarich taky promarni slusnou davku kontext switchu