Jaderné noviny – 10. 7. 2014: Anatomie systémových volání (diskuse)

[ed]

Vysvetlovat mechanizmus syscall-u na niecom, co je derivovane od x86, je ako vysvetlovat mechanizmus operatorov + / - nad celymi cislami pomocou lingebry :) kopa nepotrebneho skaredeho balastu a princip ostane aj tak nepochopeny.

[Michal Kubeček]

Je důležité takto přemýšlet, protože za rok někdo, o němž jsme nikdy neslyšeli, možná bude pročítat hlášení o chybě od uživatele a bude přemýšlet, jestli to backportování této opravy vyřeší. A jsou i další důvody.

Svatá slova… Ideální commit message od opravy chyby by měl obsahovat tři důležité informace: co bylo špatně z hlediska kódu, jak se to projevovalo navenek a jak se to opravilo (je-li to relevantní, tak navíc i informaci, kdy chyba vznikla). Až příliš často tam bohužel bývá jen to první nebo třetí, v lepším případě oboje.

[Jan R.]

Neviete niekto, preco sa cisla systemovych volani prideluju rucne a nie je to napr velky enum?

[ebik]

Nevím co bylo příčinou, ale výhody vidím dvě.

První výhoda je odvození čísla volání z headeru pomocí standardních nástrojů jako je třeba grep. Když se pak člověk hrabe v živém systému nebo nějakém dumpu, tak se mu může hodit mít to rychle po ruce. Lze to také pak využít v nějakých skriptech.

Druhá výhoda je, že může být "navěky zaznamenáno", že to číslo bylo přiděleno takto, a když by byl nějaký syscall úplně vymazán, tak po něm prostě zůstane díra v číslování. (Pokud nebude jeho číslo v budoucnu znovu použito.) Díky tomu mohou programy, které byly staticky slinkované před mnoha lety, běžet i na budoucích kernelech, za předpokladu, že nepoužívají zrušené syscally. (Normální syscally se neruší, ale teoreticky se může přijít na to, že nějaký syscall je z principu špatně a nelze (bezpečně) použít.)

[zde]

Spíš by mě zajímalo proč když celý gcc toolchain používá pro identifikaci vstupních bodů funkcí symboly (které jsou přirozeně mnohem lepší a flexibilnější než ordinální čísla), proč to zrovna jádro dělá jinak. Dneska každá C++ binárka resolvuje 20-100 zbytečnejch .so, tak proč jádro jednoduše nezabije ld-linux.so.2 harakiri, nemá nativní ELF loader, a neexporuje syscally v kernel64.so, podobně jako windows.

[chrono]

Naozaj prinášajú symboly tak veľa výhod, aby kvôli tomu rozbili ABI?

[zde]

Lunix přece žadná ABI nemá, to ví každej kdo rekompiluje jaderný moduly po každým druhým updatu jádra.. A minimálně by se ušetřil ten zbytečnej range check a dispatch přes syscall table při *každém* syscallu.

[tm]

Kernelspace ABI a userspace API su dve rozne veci.

[zde]

Ano, userspace API se mění ještě častěji, o nich ale nikdo nemluvil, takže smysl vaší poznámky nechápu.

[trekker.dk]

userspace API se mění ještě častěji

blábol

[Ivan]

Jestli se nepletu tak je to uz castecne deje v pripade vdso. Kazdy proces ma ve svem adresnim prostoru namavanou binarku, ktera nelezi na disku ale lezi v adresnim protoru jadra. Takze kdyz na 64bit systemu zavolate gettimeofday tak vlastne ani zadny "syscall" nevolate.

Kdyby existovalo neco jako kernel64.so, tak by asi odpadla spousta prace pro glibc.

PS: gettimeofday je ale specialni pripad, ktery ani nepotrebuje privilegovany rezim. Pro zjisteni aktualniho casu staci precist obsah jedne specialni namapovane stranky. Funkce ktera tu stranku cte ale neni soucast glibc, nachazi se v knihovne linux-vdso.so

[zde]

Mám pocit že rychlý gettmeofday bylo to poslední co k linux-gate vedlo.. Spíš chtěli aby userspace nemusel řešit jestli použít int80, syscall, nebo sysenter.. Stejně je ten x86 svět kouzelnej: místo aby se intel chytl za nos a opravil pomalý softwarový interrupty, zavede jiný mechanismus, amd zase jinej, a aby se to sjednotilo, nalepí se nad to ještě další abstrakce.. lol.

[ed]

vzhladom k tomu, ako hovadsky vela vrstiev uz intel na x86 nalepil si myslim, ze stav SW interruptov je FUBAR. sysenter bolo jedine schodne riesenie, ked sa ukazalo, ze overengeneered memory model PentiumPro procesorov je z velkej casti nevyuzivany. SW interrupty minimalne nejde zrychlit kvoli tomu, ako vela podmienenej roboty sa pri nich musi robit, zvlast ak sa meni IOPL.

existencia SYSCALL u AMD64 je zrejme dana tym, ze samotne AMD64 je do znacnej miery oholene o balast rokmi na x86 nabaleny a definovat inu semantiku SYSENTER pre 32 a 64 bitovy rezim by bolo nevhodne.

[rad]

Vyborny. Na toto tema by urcite nebylo spatne se rozepsat i vic.

Dekuji.

[Petr Ježek]

Svělý článek. Kdyby se realtime neválčilo, bylo by dost peněz na realtime jádro. USA sypou peníze pouze do svých úzce mocenských zájmů, o kterých běžný občan nic netuší...

[Petr Ježek]

Po obědě nevidím. "Skvělý..."

[Bystroushaak]

To je ale hovnokomentář. Skoro jak někde z novinek, zapomněl jsi jen na Kalouska, komunisty a straky.