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 03:00 | Nová verze

Po více než roce vývoje od vydání verze 1.12 byla vydána nová verze 1.13 Java edice počítačové hry Minecraft (Wikipedie). Kódový název nejnovější verze je Update Aquatic. Přehled novinek v oficiálním oznámení o vydání. Detailní přehled novinek na Gamepedii a na YouTube.

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

Společnost Epic Games vydala verzi 4.20 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Přehled novinek i s celou řadou obrázků a videi v oznámení na blogu.

Ladislav Hagara | Komentářů: 0
včera 15:55 | IT novinky

Evropská komise uložila (pdf) společnosti Google pokutu ve výši 4,34 miliardy eur za porušení antimonopolních předpisů EU. Společnost Google ukládala od roku 2011 výrobcům zařízení Android a provozovatelům mobilních sítí protiprávní omezení, aby upevnila dominantní postavení svých produktů zaměřených na všeobecné vyhledávání na internetu.

Ladislav Hagara | Komentářů: 23
včera 13:55 | Zajímavý software

Byl vydán REAPER (Wikipedie) ve verzi 5.93. Jedná se o proprietární digitální pracovní stanici pro práci s audiem (DAW). Novinkou je experimentální linuxový port [reddit].

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

Příspěvek na blogu Qt informuje, že Qt pro Python aneb modul PySide2 je již k dispozici v PyPI (Python Package Index). PySide2 je portací PySide na Qt 5 [Hacker News].

Ladislav Hagara | Komentářů: 2
včera 12:22 | IT novinky

Koncem minulého roku GitHub přidal funkci automatického varování před zranitelnostmi v závislostech projektů i s případným komunitním doporučením, jak se se zranitelnou závislostí vypořádat. Nejprve bylo možné využít funkci pouze pro programovací jazyky Ruby a JavaScript, nyní však GitHub přidal podporu také pro Python [CSIRT.CZ].

Ladislav Hagara | Komentářů: 0
včera 10:55 | Zajímavý software

Öffi (Wikipedie) je oblíbená mobilní aplikace pro Android usnadňující cestování městskou a veřejnou dopravou nejenom v Německu. Dle autora z nejasných důvodů (Payments) byla aplikace z Google Play odstraněna. Autor se následně rozhodl zdrojové kódy Öffi zveřejnit na GitLabu pod licencí GPLv3. Požádal také o začlenění aplikace do F-Droidu [reddit].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 154. brněnský sraz, který proběhne v pátek 20. června od 18:00 na zahrádce restaurace Tanganika (Horova 35). V případě nepřízně počasí uvnitř.

Ladislav Hagara | Komentářů: 0
17.7. 02:22 | Zajímavý projekt

Na Humble Bundle lze v rámci akce Humble Book Bundle: Linux Geek by No Starch Press zakoupit elektronické knihy věnované operačnímu systému Linux a open source softwaru od nakladatelství No Starch Press a navíc podpořit charitu. Za 1 dolar a více lze zakoupit 6 elektronických knih, za 8 dolarů a více dalších 6 elektronických knih, za 15 dolarů a více dalších 5 elektronických knih a za 30 dolarů a více další elektronickou knihu navíc.

Ladislav Hagara | Komentářů: 0
17.7. 01:33 | Komunita

Patrick Volkerding oznámil před pětadvaceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

Ladislav Hagara | Komentářů: 16
Jak čtete delší texty z webových stránek?
 (78%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 363 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

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

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

    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: 33 | 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.