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 | Komunita

Přesně před rokem Valve představilo nový Steam Play s integrovaným forkem Wine s názvem Proton umožňující v Linuxu přímo ze Steamu hrát hry do té doby běžící pouze ve Windows. Aktuální přehled her pro Windows běžících na Linuxu díky Protonu na stránkách ProtonDB.

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

Na OpenPOWER Summitu bylo oznámeno, že OpenPOWER Foundation – včetně POWER Instruction Set Architecture (ISA) a klíčových hardwarových referenčních návrhů – Open Coherent Accelerator Processor Interface (OpenCAPI) a Open Memory Interface (OMI) – bude začleněna pod Linux Foundation.

Ladislav Hagara | Komentářů: 0
včera 16:00 | Komunita

MojeFedora.cz informuje, že Fedora schválila konec 32 bitových repozitářů Modular a Everything. I nadále by měly být zachované multilib balíčky, takže kompatibilita s 32bitovým softwarem nebude ohrožená.

Ladislav Hagara | Komentářů: 3
včera 13:00 | Komunita

Konference LinuxDays 2019 proběhne o víkendu 5. a 6. října v Praze v Dejvicích v prostorách FIT ČVUT. Konference OpenAlt 2019 proběhne o víkendu 2. a 3. listopadu na FIT VUT v Brně. Přihlaste svou přednášku nebo workshop (LinuxDays, OpenAlt). Upozorněte známé. LinuxDays CFP končí již v pondělí 26. srpna v 23:59.

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

Článek na Opensource.com představuje nástroj gocryptfs pro šifrování souborů. Gocryptfs využívá FUSE, stejně jako například EncFS. Naprogramovaný je v programovacím jazyce Go. Porovnání s podobnými šifrovacími nástroji v tabulce. Jako GUI pro gocryptfs lze použít SiriKali.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Zajímavý projekt

Na Humble Bundle byla spuštěna akce Humble Book Bundle: Python Programming by No Starch Press. Za 1 dolar a více lze koupit 5 elektronických knih, za 8 dolarů a více lze koupit 10 elektronických knih a za 15 dolarů a více lze koupit 14 elektronických knih věnovaných programovacímu jazyku Python od nakladatelství No Starch Press. Peníze lze libovolně rozdělit mezi No Starch Press, Humble Bundle a neziskové organizace The No Starch Press Foundation a Python Software Foundation.

Ladislav Hagara | Komentářů: 0
19.8. 20:33 | Nová verze

Byla vydána nová verze 3.0.8 multiplatformního multimediálního přehrávače VLC (Wikipedie). Jedná se o minor verzi řešící několik regresí a opravující 13 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
19.8. 06:00 | Pozvánky

Srpnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 22. 8. 2019 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tématem bude jako obvykle svobodný software a hardware. A pokud vás zajímá bezpečnost bezdrátových klávesnic a myší (útok MouseJack a spol.) a nějaké takové zařízení máte, vezměte ho sebou – trochu ho potrápíme o ověříme jeho bezpečnost.

xkucf03 | Komentářů: 3
18.8. 16:33 | Nová verze

David Heinemeier Hansson oznámil vydání nové major verze 6.0 frameworku pro vývoj webových aplikací Ruby on Rails (Wikipedie). Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Přispělo 801 vývojářů.

Ladislav Hagara | Komentářů: 13
17.8. 18:11 | Nová verze

Byla vydána verze 2.23.0 distribuovaného systému správy verzí Git. Přispělo 77 vývojářů, z toho 26 nových. Přehled novinek v poznámkách k vydání nebo v příspěvku na blogu GitHubu.

Ladislav Hagara | Komentářů: 8
Používáte ještě 32bitový software na PC?
 (20%)
 (15%)
 (17%)
 (43%)
 (6%)
 (29%)
Celkem 449 hlasů
 Komentářů: 36, poslední 18.8. 21:46
Rozcestník

Jaderné noviny – 21. 4. 2011: Swapování po síti

2. 5. 2011 | Jirka Bourek | Jaderné noviny | 4389×

Aktuální verze jádra: 2.6.39-rc4. Citáty týdne: Linus Torvalds. DISCONTIGMEM, !NUMA a SLUB. Racionalizace stromu ARM. Bezpečné swapování po síti.

Obsah

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

link

Současné vývojové jádro je 2.6.39-rc4 vydané 18. dubna. Linus:

Věci už se bohužel přestaly zklidňovat. V -rc4 jsme měli více commitů než v -rc3 a já opravdu doufám, že tento rostoucí trend nebude pokračovat.

Jediná věc, která v tomto vývojovém cyklu působila problémy, jsou změny v připojování do blokové vrstvy, a od -rc4 by problémy, které jsme měli s MD, snad měly být za námi. Na této frontě tedy děláme pokroky také.

Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: 17. dubna vyšlo 2.6.34.9, 15. dubna 2.6.32.37 a 2.6.33.10 (rychle následována jádry 2.6.32.38 a 2.6.33.11, která opravovala problém v síťovém protokolu RDS.) 14. vyšlo 2.6.38.3.

V době psaní tohoto článku se revidují 2.6.32.39, 2.6.33.12 a 2.6.38.4; očekávat je lze někdy 21. dubna.

Citáty týdne: Linus Torvalds

link

Ve skutečnosti jsou jenom dva přijatelné modely vývoje: „přemýšlej a analyzuj“ a „roky a roky testování na tisících strojů“. Tyto dva opravdu fungují.

-- Linus Torvalds

DISCONTIGMEM, !NUMA a SLUB

link

napsal Jonathan Corbet, 20. dubna 2011

Jádro má dva způsoby, jak se vypořádat se systémy které mají velké díry v adresovém prostoru fyzické paměti – DISCONTIGMEM a SPARSEMEM. DISCONTIGMEM je z těch dvou starší, je napůl označený za zastaralý a zdá se, že je z jádra (pomalu) vytěsňován. Některé architektury ho ale stále používají. Nedávné změny (a jimi způsobené pády) ukazují, že existují nějaká zajímavá nedorozumění o tom, jak se s DISCONTIGMEM pracuje v jádře.

Problém je následující: DISCONTIGMEM sleduje různé rozsahy paměti tak, že každý vloží do samostatného virtuálního NUMA uzlu. Výsledkem je, že systém běžící v tomto režimu může ukazovat, že má víc NUMA uzlů, i když podpora pro NUMA není zapnuta. To zjevně většinou funguje dobře, ale nedávno to způsobilo nějaké pády ve SLUB alokátoru, který nečeká více NUMA uzlů na systému, který není NUMA.

Strhla se překvapivě prudká diskuze o tom, čí je toto nedorozumění chyba a jak ji opravit. Mezi možnosti patří změnit DISCONTIGMEM tak, aby se takto „nezneužíval“ (podle některých) koncept NUMA; to by mohlo být dlouhodobé řešení, ale chyby existují teď a jak to řekl James Bottomley: Tohle je potřeba opravit ve -stable. Opravdu si nemyslím, že přepis DISCONTIGMEM by ve -stable sérii byl to nejlepší. Další možností je vynutit zapnutí podpory NUMA, když se používá DISCONTIGMEM; tím by se ale mohlo zvětšit jádro na embedded systémech a navíc to znamená přijmout podivný koncept, že jednoprocesorové systémy mohou být NUMA. Jádro by se dalo opravit tak, aby se dokázalo vyrovnat s nenulovými NUMA uzly vždy; to by znamenalo výrazný audit kódu, protože problémy nemusí být omezeny na SLUB alokátor. SLUB alokátor by bylo možné zakázat na systémech, kde je NUMA vypnuto a používá se DISCONTIGMEM, ale i tady by se mohly objevit problémy jinde. Také by šlo urychlit proces vytěsnění DISCONTIGMEM z jádra – to by ale nebylo použitelné do stabilních řad.

V době psaní tohoto článku diskuze pokračuje; není jisté, jako podobu bude mít konečné řešení. Problém je záludný a nezdá se, že by k němu existovaly snadné opravy.

Racionalizace stromu ARM

link

napsal Jonathan Corbet, 19. dubna 2011

Podpora architektury ARM v jádře je jednou z nejrychleji se pohybujících částí projektu, který jako celek rozhodně pomalý není. Nedávné obavy o stav kódu ve stromě ARM ale hrozí významným zpomalením vývoje a někteří vývojáři mají obavy z toho, že podpora pro některé platformy může být pozdržena na neomezeně dlouhou dobu. Situace pravděpodobně není tak špatná, ale aby se vývoj ARM dostal zpátky na správnou cestu, je rozhodně potřeba provést nějaké změny.

Hlavní správce ARM Russell King se nedávno díval na patche ARM v linux-next a nebyl potěšen tím, co viděl. Přibližně 75 % ze všech změn architektur se týkalo architektury ARM a tyto změny přidávají nějakých 6 000 řádků kódu. Část z toho je rozhodně ospravedlněna tím, že nové ARM procesory a desky se objevují téměř denně, ale i tak je to problematické v prostředí, kde se volá po tom, aby se kód zmenšil. Russell tedy navrhl: Prosím, zamyslete se na chvilku, jak na tohle během příštího začleňovacího okna zareaguje Linus..

Jak se ukazuje, nebylo nutné přemýšlet moc dlouho: Linus se objevil a řekl vývojářům ARM, co mohou očekávat:

Nápověda pro všechny v konferenci arm: podívejte se na dirstat, který poslal rmk. Jestli se vaše „arch/arm/{mach,plat}-xyzzy“ objevuje hodně často, je dost možné, že váš strom nepřetáhnu, pokud ty změny nebudou představovat odstranění spousty kódu.

Lidi si musí uvědomit, že nekončící množství nového zbytečného kódu platforem je problém, a protože mohu akorát říci „pokud to nebude vypadat, že se snažíte to napravit, přetahovat od vás nebudu“, udělám nakonec přesně tohle.

Přesně v době, kdy se tak rozhodnu.

Před nějakou dobou většina správců subplatforem ARM začala spravovat své vlastní stromy a požadavky na přetažení zasílat přímo Linusovi. Tento krok dával smysl; velikost a rozdílnosti ve stromě ARM brání jedinému správci na nejvyšší úrovni všechno stíhat. Také to ale vede k situaci, kde není moc velká kontrola a vede to ke spoustě duplikovaného kódu. Jak to řekl Arnd Bergmann:

V současnosti každá subarchitektura v arm implementuje mnoho ovladačů (irq, clocksource, gpio, pci, iommu, cpufreq, ...) Tyto ovladače jsou často kopiemi ovladačů již existujících s malými modifikacemi nebo (hůře) nezávisle napsané ovladače pro stejné IP bloky. V některých případech jsou to kopie ovladačů pro věci, které jsou přítomny na jiných architekturách.

Jasným řešením je vytáhnout více kódu ze subplatforem, najít společné části a odstranit duplikace. Všichni chápou, že taková snaha by mohla výrazně omezit množství kódu v ARM stromě; strom by zároveň s tím byl obecněji použitelný a lépe spravovatelný. na tom už se začalo pracovat; například lze uvést práci Thomase Gleixnera na konzolidaci ovladačů pro čipy řídící přerušení. Rafael Wysocki a Kevin Hilman pracovali na sjednocení kódu pro správu paměti a Sascha Hauer má patch „umravňující bláznivé soubory s daty hodin“.

Z této práce by mohly profitovat i další architektury mimo ARM. Například se přišlo na to, že většina GPIO ovladačů vypadá velmi podobně. Koneckonců i vývojáři hardwaru s tou největší představivostí mohou přijít jenom na omezený počet způsobů, jak řídit drát se dvěma či třemi stavy. Jádro obsahuje neuvěřitelný počet GPIO ovladačů; pokud by se většina z nich dala omezit na deklaraci toho, se kterými do paměti mapovanými I/O bity je potřeba pracovat, aby se přečetl a změnil stav linky, mohlo by zmizet hodně kódu.

Také se mluví o reorganizaci ARM stromu tak, aby většina ovladačů přestala žít v adresářích s kódem specifickým pro subplatformu. Jakmile bude možné najít všechny ovladače specifického typu na jednom místě, bude mnohem snazší najít duplikáty a abstrahovat společné funkce.

Všechna tato práce bude ale vyžadovat čas a příští začleňovací okno se má otevřít za méně než dva měsíce. Jakákoliv práce, která by se mohla začlenit do 2.6.40, by teď měla být skoro hotová; a většina věcí, která toto kritérium splňuje, ničím nevyniká: přidávají nové platformy, desky a ovladače. Russell se obává, že tato práce již nebude začlenitelná:

Budeme někdy schopni vložit Johnův kód do jádra? Upřímně nemám tušení. Co ale vím, je, že pokud nezačneme dělat něco, co by vyřešilo problém, který dnes máme s množstvím kódu pod arch/arm a s neustálým ruchem v tomto kódu, nikdy nebudeme schopni do jádra přidat podporu pro nové platformy v jakékoliv podobě.

Russell má občas tendence věci dramatizovat, což by mohlo čtenáře vést k tomu výše uvedené přehlížet, ale tyto obavy nemá jenom on. Mark Brown má obavy, že vývoj ARM se na několik měsíců zastaví; také vyjádřil pochybnosti nad celým nápadem, že by se strom ARM měl zmenšit, než mu bude opět povoleno růst:

Říkáme lidem, že mají pracovat na náhodných zlepšeních více či méně souvisejícího kódu. To nevypadá příliš rozumně a rozhodně to bude odrazovat nové přispěvatele (jako lidi, kteří se pokoušejí zaslat nové platformy, mnoho z nich jsou nováčci, co se práce na hlavní řadě týče), protože začít pracovat na méně známém kódu, když se ještě pořád snažíte učit a máte obavy, abyste někomu nešlápli na nohu nebo něco nerozbili, nemluvě o ospravedlnění takto stráveného času vedení, je docela velký skok.

Pokud se tyto obavy vyplní, můžeme se dostat do situace, ve které jádro ztratí velkou část své hybnosti – jak ohledně podpory nového hardware, tak ohledně příspěvků od výrobců. Cena takového výsledku by mohla být poměrně velká; není překvapením, že lidé mají obavy.

Ve skutečném světě nicméně takto ošklivý vývoj událostí není pravděpodobný. Nikdo neočekává, že by strom ARM mohl být opraven do začleňovacího okna 2.6.40; ani Linus, i přes názory, které dal jasně najevo, není tak nerozumný. Ve skutečnosti v současnosti pracuje na patchi pro git, díky kterému by práce na pročištění ARM nevypadala tak špatně ve statistikách. V blízké budoucnosti není potřeba kompletní řešení; je potřeba jasný signál, že komunita ARM vývojářů na takovém řešení pracuje. Nějaké počátky práce na pročištění, opravy těch největších prohřešků a plán pro následující cykly by měly postačovat, aby se Linusův Hněv odložil na další vývojový cyklus. Pokud poté věci budou pokračovat správným směrem, mělo by nadále být možné přidávat podporu pro nový hardware.

Pozorovatelé mohou být v pokušení považovat celou tuto epizodu za černý puntík pro vývojovou komunitu jádra. Jak můžeme provozovat profesionální vývojový projekt, když na celou architekturu může padnout takováto nejistota? Ve skutečnosti tu ale vidíme příklad toho, jak se komunita pokouší myslet na budoucnost. Nacpat do jádra více a více kódu pro ARM zajistí, že současný hardware bude fungovat, ale v dlouhodobém měřítku nikdo nebude šťastný z toho, když se jádro zhroutí vlastní vahou. Se štěstím nějaká odmítnutí dnes pomohou vyhnout se mnohem významnějším problémům za několik let. Ti z nás, kdo mají v plánu stále pracovat na Linuxu (a používat ho), z toho potom budou těžit.

Bezpečné swapování po síti

link

napsal Jonathan Corbet, 19. dubna 2011

Swapování stejně jako zpětný zápis stránek funguje za velmi významných omezení. Možnost zapsat špinavé stránky zpět na úložiště je pro správu paměti kritická; je to jediný způsob, jak tyto stránky lze uvolnit pro další použití. Swapování tedy musí fungovat i za situace, kdy systém nemá téměř žádnou paměť, kterou by mohl postrádat. Zápis stránek na úložiště nicméně sám o sobě vyžaduje paměť – to je problém, který byl (pomocí fondů paměti [mempools]) vyřešen pro lokální zařízení, ale síťová zařízení přidávají problémy navíc a ty ještě nebyly vyřešeny zcela uspokojivě.

Samozřejmě se nejedná o nový problém; na LWN se článek o swapování na síťová bloková zařízení [network block devices, NBD] objevil téměř před šesti lety. Tehdy byly navrženy různé přístupy, ale začleněn nebyl žádný; uvidí se, jestli nejnovější pokus (zaslaný Melem Gormanem a založený na práci Petera Zijlstry) bude úspěšnější.

Jaderný alokátor stránek své poslední stránky rozdává jenom těm procesům, o kterých si myslí, že se snaží uvolnit paměť. Konkrétně daný proces musí mít nastaven příznak PF_MEMALLOC nebo TIF_MEMDIE; PF_MEMALLOC dává najevo, že proces právě pracuje na shlukování paměti nebo přímém znovuzískávání [direct reclaim]. TIF_MEMDIE znamená, že proces narazil na zabijáka při nedostatku paměti [out-of-memory killer] a pokouší se ukončit. Toto pravidlo by mělo sloužit k tomu, že když je potřeba uvolnit více paměti, nějaká by pro tento účel měla být volná; jeden aspekt tohoto mechanismu ale nefunguje příliš dobře: interakce se slab alokátory.

Slab alokátor si zabere celou stránku a rozdává ji po malých kouscích. Pokud proces označený PF_MEMALLOC či TIF_MEMDIE požádá slab alokátor o objekt, alokátor na splnění tohoto požadavku může použít rezervovanou stránku. Problém je, že její zbytek je poté dán k dispozici všem ostatním procesům, které si požádají; tak může být vyplýtván procesy, které situaci paměti zhoršují a ne zlepšují.

První věc, kterou dělá Melova série patchů, je tedy adaptace Peterova patche, který do slab alokátorů přidává víc informací. Do struct page přibývá nová pravdivostní hodnota (pfmemalloc), která informuje o tom, že daná stránka byla získána z rezerv; její příjemce s ní má podle toho pracovat. Slab i SLUB alokátory byly upraveny tak, aby tento příznak rozpoznaly a rezervovaly zbytek stránky pro vhodně označené procesy. Tato změna by mohla pomoci zajistit, že paměť bude v případě potřeby k dispozici, ovšem za cenu, že jiné alokace paměti mohou selhat, i když budou k dispozici volné objekty.

Dalším krokem je přidání GFP příznaku __GFP_MEMALLOC, který označí požadavky na alokaci, které mohou používat rezervy. Tento příznak odděluje označení urgentních požadavků na alokaci od stavu procesu – tato změna bude užitečná později v sérii patchů, kde by mohl chybět vhodný stav procesu. Bude zajímavé sledovat, za jak dlouho se nějaký vývojář pokusí tento příznak někde jinde v jádře zneužít.

Velkým problémem pro swapování po síti je, že pro zpracování síťových protokolů je potřeba paměť navíc. Pokud tedy má swapování po síti fungovat spolehlivě, musí síťová vrstva být schopna používat rezervy paměti. Poměrně velká část práce se sítí probíhá v obsluhách softwarových přerušení, které běží nezávisle na procesu. Příznak __GFP_MEMALLOC těmto obsluhám umožňuje přistupovat k rezervované paměti a byla přidána i nějaká další vylepšení.

Není ale žádoucí umožnit každé síťové operaci používat rezervy; bittorrent či prohlížeč webu nesmí mít možnost používat paměť, která je urgentně zapotřebí jinde. Pro označení socketů, které pracují na uvolnění paměti, slouží nová funkce sk_set_memalloc(). Alokace pro tyto sockety použijí příznak __GFP_MEMALLOC, zatímco všechny ostatní alokace budou mít normální prioritu. Předpokládá se, že takto budou označeny pouze sockety spravované jádrem; jakýkoliv socket, který končí v uživatelském prostoru, by neměl být schopen přistupovat k rezervám. Swapování přes souborový systém připojený pomocí FUSE tedy není něco, od čeho by se mělo očekávat, že to bude fungovat.

Je tu ale další problém: příchozí pakety nemají zvláštní příznak „je zapotřebí pro získání paměti“. Síťová vrstva tedy musí být schopna alokovat paměť pro všechny příchozí pakety alespoň na tak dlouho, než se podaří identifikovat ty důležité. Za tímto účelem všechny alokace pro příchozí data mohou přistoupit k rezervám, pokud je to potřeba. Jakmile je paket identifikován a spojen se socketem, lze zkontrolovat příznaky socketu; pokud byl paket alokován z rezerv a cílový socket není spojen se získáváním paměti, paket se hned zahodí. Tato změna by měla umožnit důležitým paketům dostat se do systému, aniž by se spotřebovalo příliš mnoho paměti pro nedůležitý provoz.

Výsledkem je, že systém by měl být schopen bezpečně swapovat přes síťové blokové zařízení. Tedy přinejmenším by to mělo být bezpečné, pokud je dost vysoký spodní vodoznak – ten určuje, kolik paměti se rezervuje. Systémy, které swapují po síti, mohou rezervy využívat relativně intenzivně, takže jejich správci by možná měli vodoznak zvýšit (k nalezení v /proc/sys/vm/min_free_kbytes). Poslední patch v sérii hlídá rezervy a začne omezovat procesy, které pracují na přímém znovuzískávání, pokud jsou rezervy vyčerpány. Cílem je zajistit, aby pro menší počet takových procesů zůstalo více paměti a aby mohly opravdu něco udělat. Úprava velikosti rezerv dynamicky by v dlouhodobém měřítku mohla být lepším řešením, ale tato vlastnost byla zatím opomenuta, aby série patchů nebyla příliš velká.

       

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

multi avatar 2.5.2011 13:04 multi | skóre: 38 | blog: JaNejsemOdsut
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
Koneckonců i vývojáři hardwaru s tou největší představivostí mohou přijít jenom na omezený počet způsobů, jak řídit drát se dvěma či třemi stavy
Posledni dobou je vtipny i sam autor LWM.
2.5.2011 13:20 Peter Fodrek | skóre: 11
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
Mate na msyli jonathana Corbeta z Linux Weekly News (LWN)?

je len sefreadaktorom...
2.5.2011 17:25 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
Také jsem zvědav na jejich definice I/O API tak, aby to fungovalo univerzálně. Až to tak 40× předělají, protže jim další zařízení čas od času ukáže, že se do jejich představy API nevejde, pak toho nechají.
2.5.2011 20:46 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
No ještě že mezi současným stavem a superideálním je mnoho stavů, kde se dá zachytit ;-).
2.5.2011 15:16 Dusan | skóre: 23 | blog: Moje_trable_s_internetom
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
Racionalizace stromu ARM

Tak to sa my fakt páči prístup hlavných vývojárov a správcov. Píšem si ďalšie plus prečo používať Linuxové distribúcie.
2.5.2011 18:11 Aleš Kapica | skóre: 49 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: Jaderné noviny – 21. 4. 2011: Swapování po síti
Jediná věc, která v tomto vývojovém cyklu působila problémy, jsou změny v připojování do blokové vrstvy, a od -rc4 by problémy, které jsme měli s MD, snad měly být za námi. Na této frontě tedy děláme pokroky také.
No tak zrovna tohle bylo důvodem proč jsem se velmi rychle vrátil k jádru 2.6.38.4 Opravdu jsem neměl valné chuti reportovat bugy, jejichž příčina mi je záhadou.

Založit nové vláknoNahoru

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