Jaderné noviny – 13. 2. 2014: (diskuse)

[Gilhad]

důvod, proč je potřeba definovat nové volání, je jednoduchý: renameat2() postrádá způsob, jak by jádro mohlo podporovat (a uživatel mohl požadovat) změny v jeho chování. Jinými slovy, schází mu argument typu flags,

Nema jit o renameat() ?

[Michal Kubeček]

Proč "podezírám Davema", ale "opravám od PeterZ"?

[nikdo]

Dokázal by někdo vysvětlit, proč není na otázku „Máme nějaký důvod nepřidat argument flags?“ odpověď vždy ne? Neboli proč se návrhový vzor argumentu flags nepoužívá mechanicky u všech nových systémových volání? Je to jen porušení konceptu "minimalismu" nebo je za tím něco víc? Nevedla se o tom někde diskuze? Co na to říká Linus?

[random]

Znepřehledňuje to kód. Pokud chceš příklad, podívej se na ioctl(). Funkce by měla mít jen jeden účel, přesně definovaný a verifikovatelný. Přidáním flags vlastně dochází k multiplexování více různých funkcí pod jeden název.

[nikdo]

To se mi ale zdá spíš jako námitka proti konkrétnímu použití flags než obecně proti jejich plošnému 'preventivnímu' použití.

Asi je rozdíl, jestli flags použiji např pro parametrizaci funkce uvař_kafe(S_MLEKEM|BEZ_CUKRU) kde je to očividně lepší, než mít 4 varianty uvař_kafe_scukrem_smlekem(), uvař_kafe_scukrem_bezmleka() apod., nebo ve funkci uvař(KAFE|PIVO|MOTOR), kde ta funkce pak dělá očividně různé věci.

Ví někdo ještě o nějakém dalším důvodu, proč se to nepoužívá automaticky u všecho nových systémových vlání?

----

Mimo téma: v ioctl(int d, int request, ...) žádné flags nejsou, ale pochopil jsem smysl námitky.

[Miloslav Ponkrác]

Protože můžete mít také funkci (záměrně jsem obrátil definice v opačné, pořadí než by byly ve zdrojáku):

uvař_kafe(struct coffee_t *);

struct coffee_t { int with_milk; int with_sugar; enum coffee_kind_t coffee_kind; int max_temperature; int coffeine_content; ... };

A v tomto případě je flags zcela zbytečným řešením a i méně přehledným a méně flexibilním.

Hint: Syscall volání jsou plné různých struktur.

Miloslav Ponkrác

[Stanislav Brabec]

A vidíte, zrovna toto je špatný návrh.

Až budete chtít přidat do struct coffee_t další položku, změní se velikost struktury. A programy zkompilované před změnou velikosti náhle budou vařit kafe s mlékem a citronem, protože se kvůli citronu podívají na pseudonáhodné hodnoty přesahující původní velikost pole. Anebo, pokud budou zkompilovány s runtime kontrolou velikosti struktur a polí, tak rovnou spadnou.

Lepší návrh by bylo pole značka+hodnota předem neznámé velikosti, ukončené nulovým záznamem.

uvař_kafe(NULL) by uvařilo nějaké obyčejné standardní kafe, a přidáním položek do pole by se daly upravovat hodnoty.

No a časem by se ukázalo, že je problém implementovat přípravu kakaa. A tak by buď vznikl tag KAFE_BEZ_KAFE, nebo nové volání uvař_kakao()

Zrovna nedávno jsem na podobný problém v kernelu narazil: V poli pro hardwarové hodiny chybí položka pro časovou zónu, kterou mají nové BIOSy. A bude asi nutné vytvořit novou strukturu, a nová volání, protože tomu starému to není jako předat, nepočítáme-li odporné obezličky.

[nikdo]

No vida, to je další obecný problém - změna velikosti datové struktury. Na to se nějakým rozumným způsobem dopředu připravit dá? (Aniž by to přinášelo problémy jako v návrhu JS1?) Občas vídávám v některých protokolech "reserved for future use". To ale asi nebude zrovna přístup, který by se v jádře používal. Nebo se mýlím?

[Miloslav Ponkrác]

Kromě toho Vás nenapadá jednoduchá varianta?

uvař_kafe(int with_milk, int with_sugar);

[nikdo]

Samozřejmě že napadá. A je taky zřejmé, že z hlediska dalšího možného vývoje je to varianta vedoucí do nesnází.

Protože za měsíc od zavedení funkce uvař_kafe si někdo vzpomene, že by chtěl třeba uvařit lungo nebo americano a najednou bude muset buď volání změnit na uvař_kafe(int with_milk, int with_sugar, int more_water); nebo zavést funkci uvař_kafe2 nebo uvař_kafe3 či dělat různé obskurnosti jako nacpat argument množství vody do horních bitů with_milk;

Proto se pídím po tom, proč právě pří vývoji jádra, kde jde o maximální udržitelnost po dlouhý čas bez rozbití stávajícího API se nějaký návrhový vzor při přidávání nové funkcionality neustálil jako standard. Ze čtení jaderných novin mám dojem, že problém "jak něco opravit / upravit / změnit a nerozbít stávající API" je poměrně častý.

[JS1]

Nepovazuji se za odbornika v C ani v jadre, ale asi bych to delal tak, ze pridam extra int argument pro flagy a extra pointer argument na strukturu, ktera bude verzovana (prvni bajt/short bude cislo verze). A tak struktura se bude pouzivat pro predavani slozitejsich a mene castych parametru, normalne muze zustal NULL.

[Stanislav Brabec]

Ne, že by to nefungovalo, ale komplikovalo by to kód v jádře, který by se vždy musel větvit podle toho, jaká verze parametrů byla použita.

Navíc, napsat funkci, která si od takové struktury udělá privátní kopii, bude docela netriviální, ba dokonce nemožné bez aktuální verze příslušné knihovny v uživatelském prostoru.

Oproti tomu nový syscall přidává pouze wrapper pro staré volání. Nové volání je již bez zbytečné režie.

[pavlix]

na strukturu, ktera bude verzovana

To už mi přijde daleko jednodušší současný systém, který verzuje celé volání. Případně se to dá do budoucna schovat za nějakou abstrakci v libc, kde nejsou takové extrémní nároky na kompatibilitu, nebo se to zabalí do abstrakce o krok dál.

[JS1]

Asi mas pravdu, ale vychazel jsem z toho, ze verzovat cele volani lidem vadilo.. Aspon je videt, ze to je asi skutecne lepsi.

Jinak si myslim, ze pro obskurni argumenty by se to i tak vyplatilo.

[petr_p]

Pán je milovník netlinku :)

[pavlix]

Tak je fakt, že na komplikovanější věci dává nějaký takový protokol smysl.

[Michal Kubeček]

Koneckonců netlink vznikl právě proto, že další rozšiřování rozhraní ioctl() bylo příliš šílené a ne dost flexibilní.

[Petr Tomášek]

Spíše je otázkou, proč linux nemá systémová volání s proměnlivým počtem parametrů...

[Miloslav Ponkrác]

Protože je to prasečina.

Chcete-li variabilní volání na úrovni systému, je lepší předat pointer na nějakou strukturu, kde si můžete řádit jak chcete, případně mít nějaký systémem udržovaný deskriptor, do kterého nacpete co chcete, než mít proměnný počet parametrů.

Navíc vše musí být dostatečně přenositelné. Proto se třeba v systémových voláních vyhýbáme předávání parametrů typu floating point number, nebo boolean.

Proměnný počet parametrů lze implementovat různými způsoby a různé jazyky to také dělají. Byl by v tom další problém.

[Miloslav Ponkrác]

Protože jednou ustanovené API se velmi těžko mění.

Ve světle dnešní rychlé doby, ba přímo módy, kdy třeba Python, Perl, Ruby a další překopávají rozhraní to mnoho lidfí těžko chápe.

Představte si to tak, kdyby každou změnou API kernelu přestalo fungovat polovina programů. Protože se API změnilo. Nebo byste musel přepsat z každou verzí bashe skripty, protože by se nekompatibilně změnila sybtaxe shell skriptů.

To se nesmí stát, a proto na prvním místě je stabilita a neměnnost API. Je nutné zajistit, aby jendou ustanovené volání API zůstalo na věky věků stejné. Jinak přestanou fungovat programuy, knihovny, začne se to hroutit.

Z toho důvodu se při vymýšlení systémových volání myslí v první řadě na budoucnost, a na stabilitu a neměnnost tohoto volání v budoucnosti. Protože pokud to neodhadnete, musíte přidat později funkce2, pokud ani tak, pak funkce3 – a to vše se musí v budoucnu třeba desítky let udržovat včetně zastaralých neodhadnutých funkcí. Což má zvýšený nárok na údržbu, programátory, atd. atd. atd.

V dlouhodobých projektech se v první řadě myslí na úzdržbu takového API.

Rozhodně je lepší přidat flags, které se v určitých případech nepoužije, než ho nepřidat a namísto X systémových volání míst dvojnásobek a celé to udržovat.

Mechanicky se ale flags vždy nepřidává, protože někteří lidé vyvíjející Linux nemyslí dostatečně dopředu (programují jen lidé), a nebo proto, že v některých voláních si absolutně nikdo nedokáže představit, že by to kdy mělo jakýkoli význam přidat flags.

Odhadování budoucnosti různých volání API se zkrátka vždy nepovede. Chce to značné zkušenosti a i tak někdy vývoj překvapí.

Miloslav Ponkrác

[nikdo]

Děkuji za Váš odstavec č.8, který se vyjadřuje k mé otázce (byť se mi zdá, že pouze fabulujete, chybí mi nějaký příklad či jiná fakta).

Zbývajících 8 odstavců je sice pěkné slohové cvičení, nicméně je poněkud mimo téma.

Neměl by náhodou někdo jiný více informací o tématu "návrhový vzor" flags v jádru linuxu"?

[Miloslav Ponkrác]

Určitě měl. Jmenuje se Google.

Jenom si člověk nesmí hrát na pašu.

[nikdo]

Kdybych odpověď našel pomocí gůglu, jistě bych se na ni neptal zde. Hledal jsem, nenašel. Ostatně je to ten typ dotazů, na něž gůgl odpověď dává málokdy.

Tak ať si na něj ten člověk nehraje.

[Stanislav Brabec]

Ostatně zmíněná 31bitová architektura S390 je také příkladem udržování API. Existuje zde kvůli 40–60 let starým programům – 32. bit se používá jako flag. Hodnota 1 identifikuje platnost horních bitů adresy. Hodnota 0 signalizuje program pro S360 nebo S370, kde se horních 8 bitů adresy ignorovalo (tedy program pro hardware z let 1964 až 1983).

A aby kompatibilita byla dokonalá, S390 bootuje z děrné pásky (pravda, virtuální).

[Michal Kubeček]

Dodal bych, že i když je v plánu odstranit architekturu S/390 (ve 3.16), nadále zůstane v jádře podpora pro spouštění 31-bitových aplikací na S/390-64 (podobně jako lze spouštět 32-bitové x86 aplikace na x86_64 nebo IA-64), takže ty programy ze šedesátých let v dohledné době fungovat nepřestanou, jen tam místo jedné vrstvy pro zpětnou kompatibilitu budou dvě.

[petr_p]

Bývaly doby, kdy jste měl v procesoru jen 4 registry k obecnému použití. Protože v Linuxu se používá jediné přerušení, tak pro argumenty systémového volání zbývají jen 3. Takže přidávat bezhlavě argument pro příznaky nebylo možné.

[Miloslav Ponkrác]

Což není principiálně problém, protože další argumenty lze ukládat na stack – viz sys_ipc.

Ostatně neexistují jenom x86 procesory, měl jsem dojem, že linux kernel chodí i na jiných procesorech. Na každém musíte vymyslet nějaké volací schéma systémových volání.

[petr_p]

Principiální problém to není, ale je to pomalejší. Psal jsem bývaly doby. Linux začínal na x86.

[Michal Kubeček]

Abychom to nepřeháněli, začínalo se na 80386, sice se později objevily i pokusy portovat Linux i na starší verze, ale to byly spíš takové experimenty a IIRC to k ničemu kloudnému nevedlo.

C sice podporuje funkce s proměnným počtem parametrů, ale kdo s tím někdy pracoval, dospěl nejspíš k závěru, že lze-li se tomu vyhnout, je rozhodně lepší tak učinit. Aspoň já ano.

A předávat všechno přes pointer na strukturu? Jde-li o komplikovanější data, jako třeba u sigaction(), pak jistě. Ale představa, že bych místo

  L = read(fd, buf, len);

měl pokaždé psát

  struct read_params par;
  ...
  par.fd = fd;
  par.buf = buf;
  par.count = len;
  L = read(&par);

(s tím, že nemám-li C99, musí být první řádek na začátku bloku) mi rozhodně nepřipadá jako krok správným směrem. A i pro debugování je lepší, když u jednodušších syscallů (a těch je většina) najdu parametry v registrech a nemusím je dohledávat na zásobníku nebo dokonce v paměti, kterou nemusím ani mít k dispozici.

Jinak řečeno, je vždycky nepříjemné, když se ukáže, že člověk nebyl dostatečně prozíravý. Ale být prozíravý až příliš také není ideální.

[Pev]

počet argumentů v zásvislosti => závislosti.

Díky za hezký překlad .