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 00:30 | Nová verze
Po více než 10 letech vývoje vyšel NetworkManager 1.0.0, sada nástrojů pro správu síťových připojení. Nejnovější verze přichází například s novou klientskou knihovnou libnm, novým DHCP klientem nebo vylepšeným nmcli.
Ladislav Hagara | Komentářů: 14
19.12. 02:09 | Komunita
V listopadu přešla Wikimedia z Bugzilly na Phabricator. K migraci se v příspěvku na svém blogu vrací André Klapper. Bugzilla byla používána 10 let. Vloženo bylo 73681 oznámení. Registrováno bylo přibližně 20000 uživatelských účtů. Porovnání Bugzilly s Phabricatorem na stránkách MediaWiki.
Ladislav Hagara | Komentářů: 75
18.12. 23:04 | Zajímavý software

Dnes vyšla na Steamu linuxová verze počítačové hry. Civilization: Beyond Earth Stalo se tak necelé dva měsíce po vydání Windows verze.Díky vánoční slevové akci lze hru na Steamu do zítřejších 19 hodin koupit s 40% slevou.

menphis | Komentářů: 13
18.12. 23:03 | Pozvánky
7. a 8.3.2015 proběhne na pražském Strahově další InstallFest. Můžete posílat náměty na přednášky nebo si rovnou svoji přednášku či svůj workshop přihlásit.
Jendа | Komentářů: 1
18.12. 23:02 | Nová verze
Laboratoře CZ.NIC vydaly ostrou verzi desktopové aplikace Datovka nesoucí označení 4. Tato verze plně nahrazuje starší Datovku 3.1 napsanou v jazyce Python. Podrobnější popis Datovky 4 a informace o rozdílech a vylepšeních naleznete na stránkách projektu nebo na blogu CZ.NIC. … více »
Vilem Sladek | Komentářů: 14
18.12. 18:00 | Nová verze
Byl vydán PostgreSQL 9.4. Nejnovější verze tohoto relačního databázového systému s otevřeným zdrojovým kódem přináší celou řadu nových vlastností a vylepšení. Zdůraznit lze například podporu nového datového typu JSONB. Podrobnosti v poznámkách k vydání.
Ladislav Hagara | Komentářů: 0
18.12. 02:30 | Nová verze
Byla vydána verze 14.12.0 KDE Aplikací (KDE Applications). Většina z nich je založena na knihovnách KDE Platform 4. Některé, například Kate, KWrite nebo Konsole, jsou už ale založené na KDE Frameworks 5. Podrobnosti v kompletním seznamu změn a na stránce s dalšími informacemi. Před několika dny vyšly také knihovny KDE Frameworks 5.5.0 a prostředí KDE Plasma 5.1.2.
Ladislav Hagara | Komentářů: 23
18.12. 02:30 | Bezpečnostní upozornění
Organizace ICANN se stala terčem spear phishingového útoku, při kterém útočníci získali přístup do několika zaměstnaneckých e-mailů. Následně získali administrátorský přístup také do aplikace "Centralized Zone Data System". Z tohoto důvodu byla hesla na účtech uživatelů CZDS deaktivována a uživatelé si musí požádat o reset hesla. Zároveň se uživatelům doporučuje provést změnu hesla i v dalších systémech, pokud někde používali stejné přihlašovací údaje. [CSIRT.CZ]
Ladislav Hagara | Komentářů: 8
17.12. 15:00 | Nová verze
Po ipfwadm, ipchains a iptables přichází nftables. Subsystém pro filtrování paketů nftables se v lednu dostal do Linuxu 3.13 (zprávička). Včera vyšla verze 0.4 balíku nftables. Nejnovější verze nftables a nástroje nft přináší například podporu Linuxu 3.18 a 3.19.
Ladislav Hagara | Komentářů: 0
17.12. 13:00 | IT novinky
Google na Google+ oznámil, že jeho Dokumenty, Tabulky a Prezentace nově otevřou také soubory ve třech hlavních ODF formátech (.odt, .ods a .odp).
Ladislav Hagara | Komentářů: 3
Disketu jsem naposledy použil během
 (46%)
 (3%)
 (11%)
 (37%)
 (3%)
Celkem 1612 hlasů
 Komentářů: 54, poslední 9.12. 17:16
    Rozcestník
    Reklama
    Autoškola testy online Levný benzín

    Jaderné noviny - 31. 1. 2007

    23. 2. 2007 | Robert Krátký | Jaderné noviny | 4308×

    Aktuální verze jádra: 2.6.20-rc7. Citáty týdne: Dave Airlie, Matt Mackal. Vývoj ovladačů pro Linux zdarma. Shrnutí API změn v 2.6.20. Síťové jmenné prostory. Fibrily a asynchronní systémová volání.

    Obsah

    Aktuální verze jádra: 2.6.20-rc7

    link

    Aktuální předverze řady 2.6 je 2.6.20-rc7, vydaná 30. ledna. Linus k tomu řekl: No jo, vím, řekl jsem, že bude jen -rc6 a pak už finální 2.6.20, ale věc se má tak, že seznam známých regresí se nezmenšil tak rychle, jak jsem doufal, a proto máme ještě -rc7. V této verzi je slušná řádka oprav, ale nic moc jiného.

    2.6.20-rc6 vyšla 24. ledna. Obsahuje také dost oprav a dva nové ovladače pro paměťová zařízení (flash).

    Od vydání -rc7 zatím do hlavního repozitáře žádné patche nepřibyly.

    Aktuální verze -mm stromu je 2.6.20-rc6-mm3. Mezi nedávné změny patří velká aktualizace ACPI, nová sada patchů pro dynamický čas a časovač s vysokým rozlišením, podpora stínových adresářů v sysfs, preemtibilní RCU a velká hromada pročišťovacích patchů pro sysctl().

    Starší jádra: 2.6.16.39 bylo vydáno 31. ledna. Opravuje relativně malé množství problémů, z nichž žádný se přímo netýkal bezpečnosti.

    Citáty týdne: Dave Airlie, Matt Mackal

    link

    K vytvoření komunitního ovladače pro jakýkoliv grafický procesor, ke kterému je dostupná specifikace, je potřeba příliš mnoho času. Pokud ten ovladač neudělá sám výrobce nebo za to někomu nezaplatí, je malá šance, že by byl ovladač v použitelném stavu v době, kdy je produkt ještě v prodeji.

    -- Dave Airlie

    Takže ano, pokud uživatel nahlásí problém, který lze připsat chybě v jediném bitu paměti [single bit memory error], a není možné jej reprodukovat ani vysvětlit, je úplně normální to svést na kosmické záření, dokud nepůjdou z hlášení o chybách vypozorovat nějaké souvislosti.

    -- Matt Mackall

    Vývoj ovladačů pro Linux zdarma

    link

    Greg Kroah-Hartman učinil výrobcům hardwaru nabídku: komunita vývojářů jádra pro vás bude psát ovladače zadarmo. Už se nemusíte trápit se všemi těmi příklady v Linux Device Driver Kit nebo se probírat tisíci ukázkovými ovladači ve snaze objevit takový, který by se nejvíce podobal tomu, co potřebujete. Není na tom samozřejmě nic nového, ale jde o jasný popis výhod poskytnutí informací o hardwaru.

    Shrnutí API změn v 2.6.20

    link

    Přestože v době psaní tohoto textu ještě jádro 2.6.20 nevyšlo, nebude to trvat dlouho. Veškeré změnu interního API měly proběhnout nejpozději před měsícem, takže mělo by být bezpečné sepsat shrnutí těch nejvýznačnějších. Pro tuto verzi jich bylo docela dost a některé způsobily v kódu pořádné vlny.

    • API pracovních front bylo od přepracováno, což si vyžádalo změny téměř všude, kde se pracovní fronty používají.

    • Většina kódu týkajícího se sysfs byla změněna tak, aby byla používána struct device místo struct class_device. Druhá jmenovaná bude posléze odstraněna, až dojde ke spojení mechanismů tříd a zařízení.

    • Nová funkce:

          int device_move(struct device *dev, struct device *new_parent);
      

      Změní předka daného zařízení na new_parent, přičemž provede potřebné sysfs změny a vygeneruje speciální událost KOBJ_MOVE pro uživatelský prostor.


    • Množství hlavičkových souborů, které includovaly jiné hlavičky, s tím přestalo. Například <linux/fs.h> už neincluduje <linux/sched.h>. Mělo by to urychlit kompilaci jádra, protože se tím zbavíme velkého počtu nepotřebných includů. Na druhou stranu to může způsobit problémy modulům nezařazeným do jádra, které výslovně neincludují vše, co potřebují.

    • Interní funkce __alloc_skb() má nový parametr - číslo NUMA uzlu, na kterém by měla být struktura alokována.

    • API slab alokátoru bylo trochu pročištěno. Stará definice typu kmem_cache_t je pryč; místo toho je třeba používat struct kmem_cache. Příznaky SLAB_ATOMIC, SLAB_KERNEL atd. byly pouze aliasy pro ekvivalentní příznaky GFP_, takže byly odstraněny.

    • Nový bootovací parametr (prof=sleep) způsobí, že si jádro bude vyhodnocovat množství času stráveného nepřerušitelnými spánky.

    • dma_cache_sync() má nový parametr: strukturu device pro zařízení provádějící DMA.

    • Kód paravirt_ops byl začleněn, takže bude snazší podporovat více hypervizorů. Pokud by chtěl na tento kód někdo portovat hypervizor, měl by mít na paměti, že je poněkud nestálý a nějakou dobu takový ještě bude.

    • Byly začleněny změny struct path, které se postupněě dostávají i do subsystémů souborových systémů a ovladačů zařízení.

    • Obecná vrstva pro vstupní zařízení; kód USB HID byl překlopen do této nové vrstvy.

    • Nová funkce round_jiffies() zaokrouhluje hodnotu jiffies na další celou vteřinu (plus offset za každý procesor). Účelem je vytvoření podmínek pro to, aby k vypršení času [timeout] docházelo zároveň, takže se procesor nemusí probouzet tak často.

    • Bloková "funkce aktivity" - zpětné volání pro implementaci signalizace diskové aktivity v programech - byla odstraněna; nikdo ji nepoužíval.

    Pokud už se těšíte na to, co bude v 2.6.21, tak několik věcí lze odhadnout už teď. Je pravděpodobné, že budou odstraněny staré příznaky SA_*, které se používaly s request_irq(); místo nich by měly být používány nové příznaky IRQF_*. Na další vývojový cyklus čeká také změna API časovače. Kromě toho si můžeme být jisti, že se chystá i nějaké to překvapení.

    Síťové jmenné prostory

    link

    V poslední době se věnuje hodně pozornosti hypervizorům a plně virtualizačním (nebo paravirtualizačním) řešením. Příznivci kontejnerového konceptu - při kterém běží všechny virtualizované systémy v pečlivě oddělených prostředích na hostitelském jádře - se příliš neprojevovali. Rozhodně však nezaspali, jak je vidět z úsilí, které je věnováno síťovým jmenným prostorům.

    Aby kontejnerový přístup fungoval, musí být každý globální zdroj v systému zabalen do nějakého jmenného prostoru. To už bylo provedeno pro některé relativně jednoduché zdroje, například informace utsname nebo ID procesů; části výsledného kódu už si i našly cestu do jádra. Jenže pro kontejnery, které jsou zcela izolované od okolního světa, není příliš užití; obyčejně je potřeba nějaká schopnost síťovat. Kontejnery mohou být například užitečné pro uzavření webového prohlížeče (což jej drží pryč od zbytku systému pro případ, že by byl napaden) nebo webserveru - ale pouze pokud funguje síťování. Kontejnery by však neměly vidět pakety jiných kontejnerů a, pokud možno, by měly mít možnost se vázat na stejné porty, aniž by si navzájem překážely.

    Aby to fungovalo, jsou potřeba síťové jmenné prostory. Tyto jmenné prostory virtualizují přístup ke všem síťovým zdrojům - rozhraní, čísla portů atd. - což každému kontejneru umožňuje přístup k síti, který potřebuje (ale nic více). Jako každý počítačový problém, i síťové jmenné prostory mohou být řešeny další vrstvou. S takovým přístupem je však trochu problém: síťovací kód je velká hromada komplexního a pečlivě vyladěného kódu, o nějž se starají vývojáři, kteří nemají moc pochopení pro změny, které by mohly přinést výkonnostní režii nebo potenciální chyby. Dosáhnout začlenění implementace síťových jmenných prostorů bude vyžadovat pořádný kus velmi citlivé a opatrné práce.

    Dmitrij Mišin

    link

    Jeden přístup je možné vidět v sadě patchů s síťovými jmennými prostory L2, kterou nedávno poslal . Tyto patche se zaměřují na spodní úrovně síťového stacku ve snaze založit řádné jmenné prostory pro síťová zařízení a IPv4 vrstvu. Aby se minimalizoval dopad na ostatní síťovací kód, zavádí L2 patch myšlenku "aktuálního síťového jmenného prostoru", který je držen v proměnné na každém procesoru. Aktuální jmenný prostor je implementován jako stack s operacemi push [dej] a pop [vezmi]; teoreticky to umožňuje provádění všech síťových operací v rámci jmenného prostoru. Nepodařilo se mi [Jonathan Corbet] uvěřit, že by to mohlo fungovat společně s jakoukoliv jadernou preempcí, ale možná jsem se jen špatně díval.

    Struktura net_device dostává pole net_ns, které obsahuje jmenný prostor, k němuž zařízení náleží. Je to nastaveno na jmenný prostor aktuální ve chvíli vytvoření zařízení. Funkce pro vyhledávání zařízení jsou si teď vědomy jmenných prostorů; pokud zařízení nepatří k aktuálnímu jmennému prostoru, bude neviditelné. Pro každý jmenný prostor je zvlášť vytvořeno loopback zařízení. Kód pro IPv4 routování byl rozšířen tak, aby měl každý jmenný prostor své routovací tabulky. A kód, který přiřazuje příchozí pakety k soketům, také se jmennými prostory spolupracuje; pořád je jediná hashovací tabulka, ale jmenný prostor byl přidán do rozřazovacích kritérií.

    Síťová rozhraní pro skutečný hardware zůstanou i nadále v kořenovém jmenném prostoru. Komunikaci s ostatními jmennými prostory zajišťuje "virtuální ethernetové" zařízení, které je součástí patche. Virtuální zařízení si lze představit jako spojení s vyhrazeným jmenným prostorem; vytvoří zařízení v rámci jmenného prostoru a také v předkovi (obyčejně root). Pakety zapsané na jedno zařízení se objeví na druhém. Díky přidání několika směrovacích pravidel v kořenovém jmenném prostoru mohou být pakety, které splní stanovená kritéria, poslána do (nebo ven z) konkrétních jmenných prostorů.

    L2 patch poskytuje základy pro vytvoření malých virtualizovaných internetů v rámci jediného systému, ale ještě není k dispozici úplná izolace. Proces může ve svém jmenném prostoru překonfigurovat rozhraní, což by mohlo způsobit problémy pro celý systém. Řešení nabízí patch vytvářející jmenné prostory L3, který poslal Daniel Lezcano. Jmenný prostor L3 je vždy potomkem L2; je to však slepá ulička - sám už potomky mít nemůže. L3 také nemá žádné možnosti správy sítě; jakmile je takový jmenný prostor vytvořen, musí si vystačit s konfigurací, kterou mu přidělil předek.

    Výsledkem je, že by uzavřený systém mohl být vložen do jmenného prostoru L3, a měl by tak mít možnost provádět síťování bez zásahu do ostatních systémů v jiných jmenných prostorech (dokonce bez toho, aby je viděl).

    Eric W. Biederman

    link

    Trochu jiný přístup je patrný u patchů se síťovými jmennými prostory od Erica W. Biedermana. Eric, maje na vědomí problémy spojené se začleňováním síťových jmenných prostorů, se daleko více stará o vlastní proces než o konkrétní implementaci. Jeho patche se tedy zaměřují hlavně na to, aby bylo správné interní API.

    První úkol je vymyslet, jak budou síťové jmenné prostory reprezentovány. Místo struktury zvolil Eric mechanismus, který určitým způsobem označuje všechny síťovací globální zdroje. Tyto zdroje jsou nalinkovány do speciální sekce jádra, která může být klonována při vytvoření nového jmenného prostoru. Každá globální proměnná se stane offsetem do sekce vztahující se ke každému jmennému prostoru; přistupovat se musí pomocí speciálního makra. Tento způsob se zdá obtížný, ale má pár výhod. Je-li natažen modul s proměnnými specifickými pro jmenný prostor, mohou být tyto proměnné do každého existujícího jmenného prostoru přidány za běhu. A pokud nejsou jmenné prostory používány, spadne režie celého mechanismu na nulu. To je důležitá vlastnost: aby existovala naděje na začlenění, implementace nebude smět mít vliv na systémy, které ji nepoužívají.

    Patche (31 kousků) se pak propracovávají různými částmi síťovacího API, přičemž přidávají parametr pro jmenné prostory funkcím, které to potřebují. Ericovy patche nemají žádný koncept "aktuálního jmenného prostoru"; místo toho je to všude explicitní parametr. Takže například každá funkce, která vytvoří soket (existují ve všech implementacích protokolů), dostane parametr jmenného prostoru. Struktuře sk_buff (která reprezentuje paket) bude přiřazeno pole jmenného prostoru buď z procesu, který ji vytváří (u odchozích paketů), nebo ze zařízení, ze kterého byla přijata; příslušné funkce specifické pro daný protokol by ten jmenný prostor měly vzít na vědomí. Funkce, které se starají o netlink sokety, také dostanou parametry jmenného prostoru, podobně jako ty, které implementují vyhledávání síťových zařízení, generování událostí a Unix-domain sokety. Stejně jako L2 patche, i Ericova implementace obsahuje virtuální síťové zařízení (nazývané "etun"), které lze použít k routování paketů mezi jmennými prostory.

    Na rozdíl od L2/L3 řeší Ericovy patche i virtualizaci síťových rozhraní v /proc, sysctl a sysfs. To vyžaduje podporu stínových adresářů v sysfs. Stínové adresáře uvolňují vazbu mezi sysfs a interní hierarchií kobject, což různým jmenným prostorům umožňuje vidět na stejném místě různý obsah.

    Klíčovým aspektem Ericova patche je, že implementuje minimum mechanismu jmenných prostorů. Místo toho je velká část síťovacího stacku nucena testovat přidělený jmenný prostor a selhat, pokud není využíván kořenový jmenný prostor. Účelem je nejprve správně zvládnout rozhraní a potom po malých kouscích doplňovat mechanismus. Testy pojistí, že síťový stack uživatele nepřekvapí provedením nesmyslu, dokud nebude plně připraven na práci s nekořenovými jmennými prostory.

    Přestože byly představeny všechny tyto patche, nijak zvlášť se nediskutovalo. Skoro se zdá, že vývojoři sítí to ještě neberou vážně. Samo od sebe však tohle téma nezmizí; i nadále je velký zájem o začlenění kontejnerových funkcí do hlavního jádra, takže dříve nebo později to přijde na přetřes.

    Fibrily a asynchronní systémová volání

    link

    Jaderná podpora asynchronního I/O je nekompletní a vždy taková byla. Ačkoliv některé druhy operací (například přímé I/O na souborový systém) fungují v asynchronním režimu dobře, mnohé jiné ne. Implementace asynchronních operací je mnohdy obtížná a zatím se nenašel nikdo, kdo by to zprovoznil. V jiných případech jsou už nějakou dobu v oběhu patche, které se však nikdy nedostaly do jádra; AIO patche mohou být dost invazivní a tím pádem je složité je začlenit. Ať už je důvod jakýkoliv, věci se v oblasti AIO pohybují velmi pomalu.

    Zach Brown se rozhodl trochu rozvířit hladinu položením jednoduché otázky: co když je způsob, kterým jádro AIO implementuje, úplně špatný? Stávající přístup totiž věci dost komplikuje, protože vyžaduje explicitní zpracování AIO v každém subsystému, který to podporuje. Je potřeba předávat IOCB struktury a jádro musí pořád kontrolovat, jestli se má při dané operaci zablokovat, nebo vrátit jeden z kódů "pracuje se na tom". Bylo by mnohem lepší, kdyby šlo většinu jaderných operací prostě vyvolat asynchronně, aniž by bylo nutné je komplikovat explicitní podporou.

    Zach tedy poslal předběžnou sadu patchů, která podporu asynchronního I/O výrazně zjednodušuje. Ale tím nekončí: zároveň umožňuje volat jakékoliv systémové volání v asynchronním režimu. Klíčem je nový druh lehkého jaderného vlákna nazývaný "fibril" [vlákno].

    Fibril je prováděcí vlákno, které běží pouze v jaderném prostoru. Proces může mít libovolný počet aktivních fibrilů, ale v jednom okamžiku může být v procesoru prováděn jen jediný. Fibrily mají vlastní stack, ale jinak sdílejí všechny zdroje svého procesu-předka. Uchovávány jsou v linkovaném seznamu připojeném ke struktuře úlohy.

    Když proces provede asynchronní volání, vytvoří jádro nový fibril a volání spustí v tomto kontextu. Pokud je dané systémové volání okamžitě ukončeno, je fibril zničen a výsledek je vrácen volajícímu procesu jako obvykle. Pokud se však fibril zablokuje, bude zařazen do fronty a kontrolu opět převezme volající kód, který pak může vrátit stavový kód "pracuje se na tom". "Hlavní" proces pak může běžet v uživatelském prostoru, zadat další asynchronní operace nebo si prostě dělat cokoliv jiného.

    Dříve či později bude operace, která fibril zablokovala, dokončena. Struktura záznamu v čekací frontě byla rozšířena o informaci o tom, na čem byl fibril zablokován; probouzecí kód tento fibril najde a přidá do speciálního linkovaného seznamu "spouštěcí fronta" v struktuře úlohy předka. Jádra pak naplánuje spuštění fibrilu, čímž možná odstaví "hlavní" proces. Fibril trochu pohne s prací a zase se zablokuje nebo práci dokončí. Ve druhém případě je uschován ukončovací kód [exit code] a fibril je zničen.

    Přesunutím asynchronních operací do samostatného vlákna Zachův patch velmi zjednodušuje jejich implementaci - až na několik výjimek nebude nutné jádro kvůli podpoře asynchronních volání měnit. Vytvoření fibrilů by mělo zajistit, že k začlenění dojde brzy - fibrily mají být méně nákladné než jaderná vlákna nebo běžné procesy. Jejich sémantika, založená na jeden-po-druhém, pomáhá minimalizovat problémy se souběžností, které by se jinak mohly objevit.

    Uživatelské rozhraní začíná následující strukturou:

        struct asys_input {
    	int 		syscall_nr;
    	unsigned long	cookie;
    	unsigned long	nr_args;
    	unsigned long	*args;
        };
    

    Od aplikace se očekává, že dá požadované číslo systémového volání do syscall_nr; parametry daného volání jsou v args a nr_args. Hodnota cookie bude procesu předána po dokončení operace. Uživatelský prostor si může vytvořit pole takových struktur a předat je:

     long asys_submit(struct asys_input *requests, unsigned long nr_requests);
    

    Jádro pak spustí každý z těchto požadavků ve fibrilu a vrátí kontrolu uživatelskému prostoru. Začne-li proces zajímat, jak jeho požadavky dopadly, použije toto rozhraní:

        struct asys_completion {
    	long 		return_code;
    	unsigned long	cookie;
        };
    
        long asys_await_completion(struct asys_completion *comp);
    

    Volání asys_await_completion() způsobí blok, který počká, dokud se nedokončí aspoň jedna asynchronní operace, a pak vrátí výsledek ve struktuře, na kterou ukazuje comp. Zároveň bude vrácena i hodnota cookie, která byla zadána na začátku.

    Všiml jsem si [Jonathan Corbet], že aktuální verze asys_await_completion() nekontroluje, jestli jsou nějaké asynchronní operace právě prováděny; pokud ne, čekalo by volání dost dlouho. Celá sada patchů má několik problémů, o kterých však autor ví. Například se moc neuvažovalo o tom, jak by měly fibrily reagovat na signály. Zach neměl v úmyslu prezentovat hotové dílo, ale spíše nápad, aby se dozvěděl, co si o něm lidé myslí.

    Linus byl nadšen:

    Jupí! [...]

    Velmi rád souhlasím, i když vlastní patche jsem prohlížel jen zběžně. Myslím, že jde o správný přístup, ale s detaily bude největší práce. Možná, že režie při alokaci stacku nebo nějaký jiný drobný avšak zásadní problém nakonec způsobí, že to nebude praktické. Ale velmi rád bych to začlenil.

    Těch detailů je mnoho - Linus například poznamenal, že není omezeno, kolik fibrilů může proces vytvořit - ale vypadá to, že by byl rád, kdyby bylo AIO implementováno tímto způsobem. Připojil, že fibrily by se mohly hodit i v kódu kevent.

    Ingo Molnar je naopak proti fibrilům; jeho argumentace je dlouhá, ale stojí za přečtení. Ingo říká, že existují jen dvě vhodná řešení pro jakýkoliv problém týkající se operačních systémů: 1) to, se kterým se nejlépe programuje, a 2) to, které nabízí nejlepší výkon. V oblasti I/O jsou nejjednodušší synchronní I/O volání a procesy v uživatelském prostoru. Nejrychlejší přístup pak bude "ryzí a minimalistický stavový stroj" optimalizovaný pro konkrétní úkol; svůj web server Tux dává jako příklad.

    Podle Inga neslouží fibrily ani jednomu z těchto účelů:

    Kam spadají všechny ty nápady na LWP, vlákna, fibrily, mikro-vlákna nebo N:M? Většinou jen oslabují koncept číslo jedna. A proto nakonec prohrají, jelikož číslo jedna je o programovatelnosti a ty nápady nenabízejí nic nového: protože nemohou. Buď chcete programovatelnost nebo výkon. Žádná střední cesta v jádře neexistuje!

    Ingo tvrdí, že Linux je při přepínání mezi běžnými procesy dostatečně rychlý a že výhody, které nabízejí fibrily, jsou přinejlepším minimální a nestojí za to.

    Tyto patche jsou v raném stadiu a bude ještě chvíli trvat, než bude jasné, jak to dopadne. I kdyby s nimi vývojáři souhlasili, může se stát, že proces přeměny na robustní jadernou funkci by byl příliš náročný na to, aby se vyplatily. Je to však zajímavý nápad, který nabízí nový pohled na způsob provádění AIO v jádře, takže je těžké si příliš stěžovat.

           

    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ář

    CIJOML avatar 23.2.2007 00:32 CIJOML | skóre: 58 | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Dvakrat ti tam ujelo dvojpismenko... Jinak posledni dobou jsem potesen, ze uz tu cestinu neznasilnujes kaktusem do analu ;) Diky
    23.2.2007 07:58 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Dvakrat ti tam ujelo dvojpismenko...
    To by mě zajímalo, kde se tam tyhle chyby berou. Ve včerejším článku také. Spellcheck je však v době vkládání na server nehlásí, takže bych se vsadil, že v redakčním systému řádí šotek.
    23.2.2007 08:52 Docture
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Může mi prosím někdo osvětlit následující skutečnost.

    V článku se uvádí že aktuální verze jádra je: 2.6.20-rc7. ale na www.kernel.org je : The latest stable version of the Linux kernel is: 2.6.20.1

    Díky David
    23.2.2007 08:56 Michal Kubeček | skóre: 69 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Opravdu se u (skoro) každého dílu musí objevit někdo, kdo se na to znovu zeptá? Co myslíte, pročpak je článek nadepsán "Jaderné noviny - 31. 1. 2007" (a tento název je mimochodem součástí titulku vašeho dotazu), přestože v kalendáři stojí 23. února?
    23.2.2007 09:25 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    To už je skoro na sepsání FAQ :-)
    When your hammer is C++, everything begins to look like a thumb.
    23.2.2007 09:54 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Často si říkám, jestli by nebylo lepší do toho úvodního odstavce uvádět aktuální údaje, ale to by pak při čtení po roce naopak mátlo. Ono tomu nepomáhá ani to, že mám o dva díly zpoždění... Snad se mi podaří to brzy dohnat.
    23.2.2007 10:19 Michal Kubeček | skóre: 69 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Možná by stálo za pokus psát tam něco jako "Aktuální verze jádra k 31.1.2007: ...". Ale bojím se, že by nepomohlo ani to; mám zkušenost, že i červený nápis zvětšeným fontem na bílém pozadí (zbytek stránky měl pozadí světle šedé) dokáže ignororat polovina návštěvníků…
    25.2.2007 17:00 xor | skóre: 14
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Ja myslim, ze je to dobry napad, ten soucasny nadpis je opravdu nejasny, sam jsem se na to nachytal. Celkem dobre se bavim, jak to nektere snadno startovaci lidi nadzvedne. Kliiid, tak jsme to prehlidli, to neni cilena provokace :)
    23.2.2007 11:58 Docture
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Hmm to jsem teda MEGATROTL - uz jsem si toho taky vsimnul.

    Vsechny namitky prijimam a kaju se.
    23.2.2007 22:53 Kaluzman
    Rozbalit Rozbalit vše Malý překlep
    Zdravím. Vidím malý překlep:

    "Ale tím nekončí: záároveň umožňuje volat jakékoliv", správně asi "Ale tím nekončí: zároveň umožňuje volat jakékoliv"

    // Nechci rýpat, po opravení smažte tenhle komentář :-)
    24.2.2007 09:48 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Malý překlep
    Díky. Zase zdvojené písmeno. To by mě zajímalo, kde se berou...
    Nechci rýpat, po opravení smažte tenhle komentář :-)
    Takové "rýpnutí" není ke škodě :-)
    24.2.2007 16:57 DNA
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    díky za článek, Jaderné noviny je zde jedno z mých nejoblíbenějších počtení. Mimochodem, vesmírné záření nejspíš funguje i na lidi - po včerejších pivech mi zmizel z hlavy jeden bit (nejspíše z alokační tabulky) a díky tomu jsem přišel o všechna data nashromážděná v průběhu večera :o)))
    25.2.2007 23:58 dta
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    lepší nechat zmizet bit než jít blít :)
    26.2.2007 02:51 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Tomu druhému se, tuším, říká taktické odplivnutí. Ostatně třeba takoví Římané považovali zvracení za zdravé, navíc jim to umožňovalo pokračovat v jídle.
    Quando omni flunkus moritati
    26.2.2007 09:24 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 31. 1. 2007
    Ano, třeba takový jícen po každém takovém chlapském odflusnití vysloveně pookřeje :-)
    When your hammer is C++, everything begins to look like a thumb.
    25.2.2007 20:20 petr_p | skóre: 58 | blog: pb
    Rozbalit Rozbalit vše fibril
    fibril [en] ma jiz v bunecne chemii cesky predklad fibrila (rod zensky, vzor zena).

    (Co takhle v readakcnim systemu povolit atribut xml:lang?)
    Možná je v rámci budování odborné czenglish rozumné připustit rozlišení fibrily v buňce a fibrilu v jádře. Ona buňka má taky jádro, tak si zkuste představit, jak hnusně zmatený si musí připadat mikrobiolog-linuxák :-).
    Godot používá GNU/Hurd.
    27.2.2007 13:28 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: fibril
    Ani ne, zdrojáky jsou dostupné v obou případech, jen je jednodušší navštívit kernel.org, než číst DNA. Jediný rozdíl je ten, že u geneticky modifikovaných věcí jaksi neplatí žádná GPL :-)
    When your hammer is C++, everything begins to look like a thumb.

    Založit nové vláknoNahoru

    ISSN 1214-1267   Powered by Hosting 90 Server hosting
    © 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.