abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 1
dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 2
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 1
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 993 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

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

    29. 7. 2014 | Luboš Doležel | Jaderné noviny | 3247×

    Aktuální verze jádra: 3.16-rc4. Citáty týdne: Andrew Morton, Paul McKenney, Eric Dumazet. Nejistá budoucnost realtime Linuxu. Anatomie systémového volání, část první: Tabulka systémových volání; Spouštění systémových volání na x86_64.

    Obsah

    Aktuální verze jádra: 3.16-rc4

    link

    Aktuální vývojová verze jádra je 3.16-rc4 vydaná 6. července.

    Stabilní jádra: Greg Kroah-Hartman 3. července oznámil, že 3.14 bude příštím dlouhodobě udržovaným stabilním jádrem; bude jej udržovat přibližně do srpna 2016.

    Stabilní jádra 3.15.4, 3.14.11, 3.10.47 a 3.4.97 vyšla 6. července, 9. července je následovaly verze 3.15.5, 3.14.12, 3.10.48 a 3.4.97.

    Citáty týdne: Andrew Morton, Paul McKenney, Eric Dumazet

    link

    Jinými slovy, jak by vypadalo hlášení chyby od uživatele?

    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.

    -- Andrew Morton

    Dochází mi, že kdyby ses tak zoufale nenudil, tak bys mě nikdy nežádal o to, abych hackoval skript v Perlu!

    -- Paul McKenney

    My se nesnažíme programovat defenzivně, my děláme jen a pouze logické věci.

    -- Eric Dumazet

    Nejistá budoucnost realtime Linuxu

    link

    Ve zprávě oznamující vydání realtime linuxového jádra 3.14.10-rt7 Thomas Gleixner znovu zopakoval, že problémy s financováním, které realtime Linux sužují (na což opět upozornil na loňském Real Time Linux Workshopu), se ještě zhoršily. Byla tu snaha získat zdroj peněz, ale nijak to nedopadlo. Pokud se to nezmění, tak má Gleixner v plánu omezit vývoj a dostat kód do upstreamu. Po mé poslední přednášce o stavu preempt-RT na japonském LinuxConu mi Linus řekl: „To bylo ještě smutnější, než jsem se obával.“ Hlavní řada jádra se za posledních 10 let dočkala řady užitečných věcí od preempt-RT a v upstreamu ještě zbývá udělat mnoho, než bude preempt-RT plně integrován, což by jistě opět zlepšilo stav linuxového jádra.

    Anatomie systémového volání, část první

    link

    Systémová volání jsou hlavním mechanismem pro interakci mezi programy v uživatelském prostoru a linuxovým jádrem. Vzhledem k jejich důležitosti nepřekvapí, že jádro obsahuje celou řadu mechanismů zajišťujících, že je možné systémová volání implementovat pro různé architektury obecně a je možné je uživatelskému prostoru nabízet efektivním a konzistentním způsobem.

    Autor tohoto textu pracoval na portování bezpečnostního mechanismu Capsicum z FreeBSD na Linux a jelikož k tomuto přísluší přidání několika systémových volání (včetně poněkud neobvyklého volání execveat()), musel prozkoumávat, jak jsou implementovány. Výsledkem toho je první z dvojice článků popisujících podrobnosti jejich implementace. V tomto článku se budeme zaměřovat na nejčastější případ: mechanismus obyčejného systémového volání (read()) spolu s tím, co programům na x86_64 umožňuje jeho spuštění. Druhý článek se přesune k méně obvyklým voláním a jiným způsobům jejich spouštění.

    Systémové volání se od běžného volání funkce liší tím, že volaný kód se nachází v jádře. Pro přechod procesoru do ring 0 (privilegovaného režimu) je nutné použít speciální instrukce. Navíc je spouštěný jaderný kód označen číslem volání namísto adresy funkce.

    Definování volání pomocí SYSCALL_DEFINEn()

    Systémové volání read() je ideální jako první ukázka při prozkoumávání fungování systémových volání v jádře. Je implementováno v fs/read_write.c jako krátká funkce, která nechává většinu práce na vfs_read(). Z pohledu spuštění je nejzajímavější stránkou tohoto kódu to, jak je funkce definována pomocí makra SYSCALL_DEFINE3(). Na první pohledu není hned jasné, jak se funkce jmenuje.

    SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
    {
    	struct fd f = fdget_pos(fd);
    	ssize_t ret = -EBADF;
    	/* ... */
    

    Tato makra SYSCALL_DEFINEn() jsou standardním způsobem, jak se v jaderném kódu definuje systémové volání, kdy přípona n označuje počet argumentů. Definice těchto maker (v include/linux/syscalls.h) vytváří pro každé volání dva kusy kódu:

    SYSCALL_METADATA(_read, 3, unsigned int, fd, char __user *, buf, size_t, count)
    __SYSCALL_DEFINEx(3, _read, unsigned int, fd, char __user *, buf, size_t, count)
    {
    	struct fd f = fdget_pos(fd);
    	ssize_t ret = -EBADF;
    	/* ... */
    

    První z nich – SYSCALL_METADATA() – sestavuje sadu metadat o systémových voláních pro účely trasování. Expanduje se pouze tehdy, když je při sestavování jádra definováno CONFIG_FTRACE_SYSCALLS, a jeho expanze generuje definice dat popisujících systémová volání a jejich parametry. (Více o nich se dočtete na jiné stránce.)

    Část nazvaná __SYSCALL_DEFINEx() je zajímavější, protože se v ní skrývá implementace systémového volání. Jakmile jsou různé vrstvy maker a typových rozšíření GCC expandovány, začíná být výsledný kód zajímavý:

    asmlinkage long sys_read(unsigned int fd, char __user * buf, size_t count)
    	__attribute__((alias(__stringify(SyS_read))));
    
    static inline long SYSC_read(unsigned int fd, char __user * buf, size_t count);
    asmlinkage long SyS_read(long int fd, long int buf, long int count);
    
    asmlinkage long SyS_read(long int fd, long int buf, long int count)
    {
    	long ret = SYSC_read((unsigned int) fd, (char __user *) buf, (size_t) count);
    	asmlinkage_protect(3, ret, fd, buf, count);
    	return ret;
    }
    
    static inline long SYSC_read(unsigned int fd, char __user * buf, size_t count)
    {
    	struct fd f = fdget_pos(fd);
    	ssize_t ret = -EBADF;
    	/* ... */
    

    Nejprve si všimněme toho, že implementace systémového volání má ve skutečnosti název SYSC_read(), ale je statická, a tudíž nepřístupná mimo tento modul. Namísto toho je tu zvenčí viditelná obalující funkce nazvaná SyS_read(), na kterou míří alias sys_read(). Při bližším pohledu na tyto aliasy si lze všimnout rozdílu v typech argumentů – sys_read() očekává explicitně deklarované typy (např. char __user * pro druhý argument), zatímco SyS_read() jen hromadu (long) integerů. Pokud si dohledáme původ tohoto, zjistíme, že long verze zajišťuje to, že 32bitové hodnoty jsou správně znaménkově rozšířeny na některých 64bitových platformách, čímž se předchází dávné zranitelnosti.

    Poslední věcí, kterou můžeme na obalení SyS_read() zaznamenat, je direktiva asmlinkage a volání asmlinkage_protect(). FAQ na Kernel Newbies ochotně vysvětluje, že asmlinkage znamená, že funkce by měla očekávat své argumenty na zásobníku namísto v registrech a obecná definice asmlinkage_protect() vysvětluje, že se používá k zabránění tomu, aby kompilátor předpokládal, že může bezpečně opětovně používat tyto části zásobníku.

    S definicí sys_read() (tou, která má přesné typy) souvisí deklaraceinclude/linux/syscalls.h, což umožňuje jinému jadernému kódu volat implementaci tohoto systémového volání napřímo (což se děje na řadě míst). Volání systémových volání z jiných míst v jádře se obecně nedoporučuje a moc často se nevidí.

    Tabulka systémových volání

    link

    Hledání toho, kdo sys_read() volá, nás také navede k tomu, jak se uživatelský prostor dostane až do této funkce. U „obecných“ architektur, které nemají vlastní řešení, nabízí include/uapi/asm-generic/unistd.h položku odkazující na sys_read:

    #define __NR_read 63
    __SYSCALL(__NR_read, sys_read)
    

    Toto definuje obecné číslo volání __NR_read (63) pro read() a používá makro __SYSCALL() pro spojení tohoto čísla se sys_read() způsobem specifickým pro platformu. Například arm64 používá hlavičkový soubor asm-generic/unistd.h pro naplnění tabulky, jež mapuje čísla volání na ukazetele na funkci s implementací.

    Budeme se ale soustřeďovat na architekturu x86_64, která tuto obecnou tabulku nepoužívá. x86_64 místo toho definuje vlastní mapování v arch/x86/syscalls/syscall_64.tbl, které má položku pro sys_read():

        0	common	read			sys_read
    

    Zde je vidět, že read() na x86_64 má číslo volání 0 (nikoliv 63) a má společnou (common) implementaci pro obě ABI na x86_64, jmenovitě sys_read(). (O různých ABI si povíme v dalším článku.) Skript syscalltbl.sh generuje soubor arch/x86/include/generated/asm/syscalls_64.h z tabulky syscall_64.tbl, především pak generuje spouštění makra __SYSCALL_COMMON pro sys_read(). Tento hlavičkový soubor je pak zase použit k naplnění tabulky systémových volání sys_call_table, jež je klíčovou datovou strukturou mapující čísla volání na funkce sys_name().

    Spouštění systémových volání na x86_64

    link

    Nyní se podíváme na to, jak programy v uživatelském prostoru spouštějí systémová volání. Toto už z principu závisí na platformě, takže se zbytek tohoto textu bude zaměřovat na architekturu x86_64 (na jiné architektury x86 se podíváme příště).

    V předchozí části článku jsme narazili na tabulku s ukazateli na funkce systémových volání; tabulka pro x86_64 vypadá asi tak následovně (za použití rozšíření GCC pro inicializací polí, které zajišťuje, že chybějící položky budou odkazovat na sys_ni_syscall()):

    asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
    	[0 ... __NR_syscall_max] = &sys_ni_syscall,
    	[0] = sys_read,
    	[1] = sys_write,
    	/*... */
    };
    

    Pro 64bitový kód je k této tabulce přistupováno z arch/x86/kernel/entry_64.S ze vstupního bodu system_call; pro volbu správné položky v poli se používá registr RAX, pak je funkce zavolána. Blíže k začátku funkce se používá makro SAVE_ARGS k uložení různých registrů na zásobník, aby to odpovídalo direktivě asmlinkage, kterou jsme viděli dříve.

    Pokud se posuneme dál, uvidíme, že vstupní bod system_call se používásyscall_init(), což je funkce volaná v raných fázích inicializace jádra:

    void syscall_init(void)
    {
    	/*
    	 * LSTAR and STAR live in a bit strange symbiosis.
    	 * They both write to the same internal register. STAR allows to
    	 * set CS/DS but only a 32bit target. LSTAR sets the 64bit rip.
    	 */
    	wrmsrl(MSR_STAR,  ((u64)__USER32_CS)<<48  | ((u64)__KERNEL_CS)<<32);
    	wrmsrl(MSR_LSTAR, system_call);
    	wrmsrl(MSR_CSTAR, ignore_sysret);
    	/* ... */
    

    Instrukce wrmsl zapíše hodnotu do registrů specifických pro model (Model Specific Register; MSR); v tomto případě je adresa obecné obsluhy system_call zapsána do registru MSR_LSTAR (0xc0000082), což je registr používaný při obsluze instrukce SYSCALL.

    A toto nám dokončuje cestu z uživatelského prostoru do jaderného kódu. Standardní ABI pro spouštění systémových volání na x86_64 nám říká dát číslo volání (0 pro read) do registru RAX, další parametry pak do konkrétních registrů (RDI, RSI, RDX pro první tři) a pak spustit instrukci SYSCALL). Instrukce způsobí přechod procesoru do ring 0 a spuštění kódu, na který ukazuje registr MSR_LSTAR – konkrétně tedy system_call. Kód v system_call uloží registry na zásobník jádra a zavolá ukazatel na funkci v položce dle RAX v tabulce sys_call_table – jmenovitě sys_read(), což je tenkým obalením pro skutečnou implementaci v SYSC_read().

    Teď, když jsme viděli standardní implementaci systémových volání na nejběžnější platformě, máme větší šanci porozumět tomu, co se děje na ostatních architekturách. Tomu se budeme věnovat příště.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    29.7.2014 15:33 ed | skóre: 18
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.
    29.7.2014 21:04 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.

    29.7.2014 22:01 Jan R.
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Neviete niekto, preco sa cisla systemovych volani prideluju rucne a nie je to napr velky enum?
    30.7.2014 00:36 ebik | skóre: 2
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.)
    30.7.2014 10:20 zde
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.
    30.7.2014 10:57 chrono
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Naozaj prinášajú symboly tak veľa výhod, aby kvôli tomu rozbili ABI?
    30.7.2014 11:12 zde
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.
    30.7.2014 11:27 tm
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Kernelspace ABI a userspace API su dve rozne veci.
    30.7.2014 13:27 zde
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Ano, userspace API se mění ještě častěji, o nich ale nikdo nemluvil, takže smysl vaší poznámky nechápu.
    31.7.2014 10:03 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    userspace API se mění ještě častěji
    blábol
    Quando omni flunkus moritati
    30.7.2014 12:39 Ivan
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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

    30.7.2014 13:38 zde
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.
    6.8.2014 08:59 ed | skóre: 18
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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.
    30.7.2014 10:06 rad
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Vyborny. Na toto tema by urcite nebylo spatne se rozepsat i vic.

    Dekuji.
    30.7.2014 13:37 Petr Ježek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    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ší...
    Archlinux for your comps, faster running guaranted!
    30.7.2014 13:37 Petr Ježek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    Po obědě nevidím. "Skvělý..."
    Archlinux for your comps, faster running guaranted!
    Bystroushaak avatar 30.7.2014 23:49 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 7. 2014: Anatomie systémových volání
    To je ale hovnokomentář. Skoro jak někde z novinek, zapomněl jsi jen na Kalouska, komunisty a straky.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.