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 10:00 | Zajímavý software

Deskreen byl vydán ve verzi 1.0.0. Jedná se o aplikaci umožňující používat libovolné zařízení s webovým prohlížečem jako druhou obrazovku, viz videoukázka. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPLv3.

Ladislav Hagara | Komentářů: 5
dnes 09:00 | Zajímavý software

Byla vydána nová verze 0.11.0 raw photo editoru Filmulator. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3. Ke stažení je také spustitelný balíček ve formátu AppImage.

Ladislav Hagara | Komentářů: 0
včera 09:00 | Nová verze

Byla vydána nová verze 13.8 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
22.1. 16:33 | Zajímavý článek

Otevřená certifikační autorita Let’s Encrypt v příspěvku na svém blogu představila své nové databázové servery. Hardware: 2U rack server Dell EMC PowerEdge R7525, CPU 2x AMD EPYC 7542, Memory 2TB 3200MT/s, Storage 24x 6.4TB Intel P4610 NVMe SSD. Software: OpenZFS a MariaDB s InnoDB.

Ladislav Hagara | Komentářů: 16
22.1. 15:33 | Zajímavý článek

Článek systemd pro vývojáře: lokální vývojové servery v systemd na MojeFedora.cz doporučuje vývojářům používání systemd k ovládání svých projektů pomocí "systemctl --user".

Ladislav Hagara | Komentářů: 23
22.1. 14:44 | Nová verze

Vyšla nová verze souborového manažera Midnight Commander 4.8.26. Mezi hlavní novinky patří zachování obsahu příkazové řádky při přepínání panelů pomocí Ctrl+O, stíny okolo dialogových oken jako v Norton Commanderu a dalších (vytvořeno autorem zprávičky), podpora jakkoli dlouhých názvů souborů a spousta dalších drobnějších věcí.

Aleš Janda | Komentářů: 15
22.1. 07:00 | Komunita

Projekty Elasticsearch a Kibana změní s verzí 7.11 licenci. Už se nebude jednat o open source software. Důvodem změny licence byl spor se společností AWS (Amazon Web Services). AWS na změnu licence odpovídá vlastním forkem. Vycházet bude z verze 7.10 a zůstane pod open source licencí Apache.

Ladislav Hagara | Komentářů: 18
21.1. 23:33 | Komunita

Lidé ze společnosti Corellium se včera na Twitteru pochlubili screenshotem Ubuntu na Apple Siliconu aneb zprovoznili Ubuntu na počítači Apple s novým ARM procesorem M1. CTO jej už používá k vývoji ve svém herním křesle s 49 palcovým monitorem. Dnes byly na blogu Corellium publikovány detaily a pro případné zájemce i návod a obraz ke stažení. Upravili obraz Ubuntu pro Raspberry Pi.

Ladislav Hagara | Komentářů: 24
21.1. 13:22 | IT novinky

Rodina počítačů Raspberry Pi se rozšířila o jednočipový počítač Raspberry Pi Pico v ceně 4 dolary s vlastním procesorem RP2040. Představení na YouTube.

Ladislav Hagara | Komentářů: 17
20.1. 22:33 | Komunita

Společnost Red Hat na svém blogu oznámila, že Red Hat Enterprise Linux (RHEL) bude možné provozovat zdarma na 16 serverech.

Ladislav Hagara | Komentářů: 38
Jestliže používáte distribuci CentOS, kterou náhradu plánujete vzhledem k oznámenému ukončení vydávání?
 (27%)
 (4%)
 (2%)
 (21%)
 (0%)
 (3%)
 (44%)
Celkem 198 hlasů
 Komentářů: 3, poslední 10.1. 13:01
Rozcestník

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

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

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