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í
×

včera 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

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

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

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

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (13%)
 (2%)
 (0%)
 (2%)
 (73%)
 (11%)
Celkem 62 hlasů
 Komentářů: 4, poslední včera 21:50
    Rozcestník

    Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19

    18. 1. 2015 | Tadeáš Pelech | Jaderné noviny | 3650×

    Stav vydání jádra. Citát týdne. Otevírá se začleňovací okno verze 3.19. Připojení programů eBPF k soketům. Rozhraní iov_iter.

    Obsah

    Stav vydání jádra

    link

    Je otevřené začleňovací okno 3.19, takže není žádné aktuální vývojové jádro. Do hlavního stromu začaly proudit opravy pro vývojový cyklus 3.19; podrobnosti viz samostatný článek níže.

    Verze jádra 3.18 byla vydána dne 7. prosince (oznámení).

    Stabilní aktualizace: Stabilní verze jádra 3.17.5 byla vydána 7. prosince s následujícím komentářem: „Nikdo by ji neměl používat“; místo ní by se měla použít verze 3.17.6 vydaná bezprostředně po ní, která obsahuje důležité odvolání oprav. K dispozici jsou také verze 3.14.26 a 3.10.62.

    Citát týdne

    link

    Microsoft poskytne integrovaný ovladač a dodavatelé mají možnost ho použít nebo si certifikovat vlastní pomocí WHQL, což je trochu jako volba mezi zmrzlinou zdarma a bušením hlavou do prkna plného hřebíků.

    Alan Cox (díky Vishalu Vermovi).

    Otevírá se začleňovací okno verze 3.19

    link

    V době vzniku tohoto článku se začalo poněkud pomalu rozjíždět začleňovací okno vývojového cyklu verze 3.19; prozatím bylo do hlavního repozitáře přijato necelých 2 000 sad změn bez začlenění. Jak je patrné z níže uvedených seznamů, i to stačí na to, aby si do jádra našlo cestu několik nových zajímavých zdrojových kódů.

    Mezi změny ve verzi 3.19 viditelné uživatelem patří:

    • Do jádra byla přidána podpora technologie Intel MPX. Procesory s podporou MPX (které lze stále sehnat jen velmi obtížně) mohou provádět kontrolu hranic na odkazech do paměti v naději, že zachytí spoustu chyb a zablokují zneužití zranitelností při přetečení vyrovnávací paměti. Použití této funkce však vyžaduje poskytnutí procesoru spousty informací o přijatelných mezích pro každý odkaz do paměti, takže se dá čekat, že její plné přijetí nějakou dobu potrvá.
    • Došlo k výraznému zlepšení výkonu cíle mapovače zařízení „thin provisioning“, hlavně v souvislosti s agregací vstupně-výstupních operací na stejném bloku před jejich použitím na podkladové zařízení.
    • Jádro nyní obsahuje podporu pro procesor Altera „Nios II“.
    • Architektura Arm64 získala podporu pro subsystém zabezpečených výpočtů („seccomp“).
    • Podpora nového hardwaru zahrnuje:
      • Systémy a procesory: Strukturované systémy na čipu (SoC) Broadcom IPROC, Amlogic Meson8 SoC, Allwinner A80 SoC, Samsung Exynos4415 SoC, Freescale LS1021A SoC, Alphascale ASM9260 SoC a AMD Seattle SoC. Prostřednictvím přírůstků ve stromu zařízení jsou navíc podporovány desítky nových systémů.
      • Bloková zařízení: Adaptéry Tekram DC390(T) a Am53/79C 974 SCSI a adaptéry Western Digital WD7193/7197/7296 SCSI.
      • Různé: Rozhraní karet SD/MMC Toshiba typ A, A-D převodníky X-Powers AXP288, master adaptéry Diolan DLN2 USB-I2C/SPI/GPIO, špičkové řadiče LCD Atmel, hardwarové sledovací čipy Nuvoton NCT7802Y, regulátory Richtek RT5033 a jednotky správy systémové paměti NVIDIA Tegra.

    Mezi změny viditelné pro vývojáře jádra patří:

    • Subarchitektura Atmel AT91 byla zcela převedena na mechanismus stromu zařízení. Na oslavu vývojáři odstranili všechny soubory starých desek pro tuto řadu, a tím snížili velikost jádra o 24 000 řádků kódu.
    • Práce na problému roku 2038 pokračují. Vnitřní funkce do_settimeofday(), timekeeping_inject_sleeptime() a mktime() jsou nahrazeny verzemi fungujícími i po roce 2038. Nová verze každopádně přidává k názvu funkce „64“ a přepne na typ time64_t nebo timespec64 pro reprezentaci času. Nyní může začít proces zařazení starých verzí mezi zastaralé a konverze zdrojového kódu.
    • Podpora domény hierarchických přerušení byla sloučena do jádra řešení přerušení. Tato podpora je nutní k řádné reprezentaci komplexního hardwaru, který má připojeno více řadičů přerušení složitým způsobem. Další informace najdete v nové části přidané do souboru Documentation/IRQ-domain.txt.

    Pokud bude zachován obvyklý postup, začleňovací okno zůstane otevřené do 21. prosince, kdy bude uvolněna první prepatch verze 3.19. LWN bude – jako obvykle – sledovat změny začleněné během tohoto okna v dalších článcích.

    Připojení programů eBPF k soketům

    link

    V předchozích vývojových cyklech jádra jsme byli svědky přidání subsystému rozšířeného filtru paketů Berkeley (eBPF) do jádra. Od verze 3.18 však může program uživatelského prostoru načíst program eBPF, ale nedokáže ho spustit v žádném užitečném kontextu; programy lze načíst a ověřit, ale nic víc. Vývojář eBPF Alexej Starovojtov samozřejmě předpokládá, že tento subsystém bude hrát významnější roli. Jádro 3.19 by mělo zahrnovat novou sadu oprav, která poprvé předvede schopnosti, které má Alexej na mysli.

    Hlavní funkcí, která má být přidána ve verzi 3.19, je možnost připojit programy eBPF k soketům. Operace probíhají tak, že se nejprve nastaví program eBPF v paměti, pak se pomocí nového systémového volání bpf() (od verze 3.18) nahraje program do jádra a získá se popisovač souboru, který na něj odkazuje. Program lze potom připojit k soketu pomocí nové možnosti SO_ATTACH_BPF setsockopt():

        setsockopt(socket, SOL_SOCKET, SO_ATTACH_BPF, &fd, sizeof(fd));

    Kde socket představuje příslušný soket a fd obsahuje popisovač souboru pro načtení programu eBPF.

    Program se po načtení spustí na každý paket, který se objeví na daném soketu. V současnosti jsou dostupné funkce stále omezeny v několika směrech:

    • Programy eBPF mají přístup k datům uloženým v paketu samotném, nikoli k žádným dalším informacím uloženým v datové struktuře jádra skb. Do budoucna se počítá se zpřístupněním části těchto metadat, ale ještě není jasné, která data budou dostupná a jak.
    • Programy nemohou žádným způsobem ovlivnit doručení ani obsah paketu. I když se tyto programy označují jako „filtry“, v současnosti mohou pouze ukládat informace do „map“ eBPF, které může využívat uživatelský prostor.

    Konečným důsledkem je, že programy eBPF budou ve verzi 3.19 použitelné v podstatě jen pro sběr statistických údajů.

    Každopádně to je dobrý začátek. Jádro 3.19 by mělo v adresáři samples obsahovat několik příkladů s ukázkami použití této funkce. Dva z nich jsou verze jednoduchého programu, který z každého paketu získává nízkoúrovňové protokoly (UDP, TCP, ICMP,...) a udržuje v mapě eBPF počitadlo pro každý protokol. Pokud chce někdo takový program napsat přímo v jazyce virtuálních strojů eBPF, dopadne to nějak takto:

        struct bpf_insn prog[] = {
    	BPF_MOV64_REG(BPF_REG_6, BPF_REG_1),
    	BPF_LD_ABS(BPF_B, 14 + 9 /* R0 = ip->proto */),
    	BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, -4), /* *(u32 *)(fp - 4) = r0 */
    	BPF_MOV64_REG(BPF_REG_2, BPF_REG_10),
    	BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -4), /* r2 = fp - 4 */
    	BPF_LD_MAP_FD(BPF_REG_1, map_fd),
    	BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem),
    	BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
    	BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */
    	BPF_RAW_INSN(BPF_STX | BPF_XADD | BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
    	BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
    	BPF_EXIT_INSN(),
        };

    Je celkem zřejmé, že takové programy nepředstavují pro většinu z nás právě poučné čtení. Ale jak je uvedeno v tomto příkladu, program lze také napsat v omezující verzi jazyka C:

        int bpf_prog1(struct sk_buff *skb)
        {
    	int index = load_byte(skb, 14 + 9);
    	long *value;
    
    	value = bpf_map_lookup_elem(&my_map, &index);
    	if (value)
    	    __sync_fetch_and_add(value, 1);
    
    	return 0;
        }

    Tento program lze předložit speciální verzi překladače LLVM, která vytvoří soubor objektu pro virtuální stroj eBPF. Prozatím je nutno použít Alexejovu verzi LLVM, Alexej však pracuje na začlenění těchto změn do hlavního stromu LLVM. Nástroj uživatelského prostoru může načíst program ze souboru objektu a nahrát ho do jádra obvyklým způsobem; není třeba používat přímo jazyk eBPF.

    Výhoda možnosti práce s jazykem vyšší úrovně je zřejmá při pohledu na poslední příklad, který se přeloží do 300 instrukcí programu eBPF. Ten provádí sledování toku, počítá pakety podle adres IP. Program samotný má možná omezené použití, ale ukazuje, že některé poměrně složité věci lze provést s virtuálním strojem eBPF v jádře.

    Do budoucna se počítá s použitím eBPF na řadě jiných míst včetně subsystému zabezpečených výpočtů („seccomp“) a pro filtrování nálezů trasovacích zarážek. Vzhledem k tomu, že se eBPF v jádru stává univerzálním prostředkem, dá se očekávat, že vývojáři přijdou na další místa, kde by se dal použít. Počítejte s tím, že se v následujících letech objeví další zajímavé možnosti využití eBPF.

    Rozhraní iov_iter

    link

    Jedním z nejčastějších úkolů v jádře je zpracování vyrovnávací paměti dat poskytnutých uživatelským prostorem i v několika blocích. Asi nikoho nepřekvapí, že takový kód jádra často bývá nesprávný, což vede k chybám a případně i k bezpečnostním problémům. Jádro obsahuje základní operaci (jménem „iov_iter“), která by měla tento úkol zjednodušit. I když se iov_iter v současnosti používá většinou jen při správě paměti a vrstev souborových systémů, pomalu se šíří do dalších částí jádra. Toto rozhraní není zatím zdokumentované, tento článek se pokusí situaci napravit.

    Koncept iov_iter není nový, poprvé ho přidal Nick Piggin pro verzi jádra 2.6.24 v roce 2007. V loňském roce ale probíhaly pokusy o rozšíření toto API a o jeho použití ve více částech jádra; v začleňovacím okně 3.19 by se například měly objevit první případy využití v síťovém subsystému.

    Struktura iov_iter je v podstatě iterátor pro práci prostřednictvím struktury iovec definované v <uapi/linux/uio.h>:

        struct iovec
        {
    	void __user *iov_base;
    	__kernel_size_t iov_len;
        };

    Tato struktura odpovídá struktuře uživatelského prostoru iovec definované v POSIX, kterou používají systémová volání jako readv(). Jak napovídá přípona „vec“, struktury iovec se obvykle používají v polích; iovec celkově popisuje vyrovnávací paměť, která může být rozptýlena ve fyzické i virtuální paměti.

    Struktura iov_iter samotná je definována v <linux/uio.h>:

        struct iov_iter {
    	int type;
    	size_t iov_offset;
    	size_t count;
    	const struct iovec *iov; /* ZJEDNODUŠENO – viz níže */
    	unsigned long nr_segs;
        };

    Pole type popisuje typ iterátor. Je to bitová maska obsahující, mimo jiné, READ nebo WRITE podle toho, zda se data do iterátoru načítají nebo z něj zapisují. Směr dat tedy neodkazuje přímo na iterátor, ale na druhou část transakce dat; do iov_iter s typem READ se bude zapisovat.

    Kromě toho iov_offset obsahuje pozici prvního bajtu zajímavých dat v prvním iovec, na který odkazuje iov. Celkové množství dat, na které odkazuje pole iovec, je uloženo v count a počet struktur iovec je uložen v nr_segs. Většina z těchto polí se změní, když kód „projde“ vyrovnávací paměti. Popisují kurzor do vyrovnávací paměti, nikoli celou vyrovnávací paměť.

    Práce se strukturou iov_iter

    Před použitím musí být iov_iter inicializována, aby obsahovala (již naplněnou) iovec:

        void iov_iter_init(struct iov_iter *i, int direction,
    		       const struct iovec *iov, unsigned long nr_segs,
    		       size_t count);

    Potom lze například přesouvat data mezi iterátorem a uživatelským prostorem pomocí funkcí:

        size_t copy_to_iter(void *addr, size_t bytes, struct iov_iter *i);
        size_t copy_from_iter(void *addr, size_t bytes, struct iov_iter *i);

    Názvy jsou možná trochu matoucí, dokud jim přijdete na kloub. Volání copy_to_iter() zkopíruje data bytes z vyrovnávací paměti na adrese addr do vyrovnávací paměti uživatelského prostoru zadané iterátorem. copy_to_iter() lze tedy považovat za obdobu copy_to_user(), která místo jedné vyrovnávací paměti používá iterátor. Podobně copy_from_iter() zkopírujete data z vyrovnávací paměti uživatelského prostoru do addr. Podobnost s copy_to_user() pokračuje i vrácenou hodnotou, která představuje počet nezkopírovaných bajtů.

    Tato volání budou „posouvat“ iterátor vyrovnávací pamětí s ohledem na objem přenesených dat. Jinými slovy, pole iov_offset, count, nr_segs a iov iterátoru se všechna změní podle potřeby. Dvě volání copy_from_iter() tedy zkopírují dvě po sobě jdoucí oblasti z uživatelského prostoru. Mimo jiné to znamená, že kód vlastnící iterátor si musí pamatovat základní adresu pole iovec, protože hodnota iov ve struktuře iov_iter se může změnit.

    K dispozici jsou i další funkce. Pro přesun dat odkazovaných pomocí struktury page do iterátoru nebo z něj použijte:

        size_t copy_page_to_iter(struct page *page, size_t offset, size_t bytes,
    			     struct iov_iter *i);
        size_t copy_page_from_iter(struct page *page, size_t offset, size_t bytes,
    			       struct iov_iter *i);

    Zkopírována bude pouze jedna zadaná page, tyto funkce tedy nelze používat ke kopírování dat, která by překročila hranice stránky.

    Kód spuštěný v atomickém kontextu se může pokusit získat data z uživatelského prostoru pomocí:

        size_t iov_iter_copy_from_user_atomic(struct page *page, struct iov_iter *i,
    					  unsigned long offset, size_t bytes);

    Protože tato kopie bude probíhat v atomickém režimu, uspěje pouze v případě, že data jsou již uložena v paměti RAM; volající proto musí být připraven na nadprůměrnou pravděpodobnost neúspěchu.

    Pokud je to nezbytné k mapování vyrovnávací paměti uživatelského prostoru do jádra, lze použít jedno z těchto volání:

        ssize_t iov_iter_get_pages(struct iov_iter *i, struct page **pages,
                                   size_t maxsize, unsigned maxpages, size_t *start);
        ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct page ***pages,
        	    			     size_t maxsize, size_t *start);

    Každá z těchto funkcí se změní na volání get_user_pages_fast(), které (doufejme) způsobí načtení stránek a uložení jejich umístění do pole pages. Rozdíl mezi nimi je, že iov_iter_get_pages() očekává, že pole pages alokuje volající, zatímco funkce iov_iter_get_pages_alloc() provede alokaci sama. Potom pole vrácené v pages musí být nakonec uvolněno pomocí volání kvfree(), protože mohlo být přiděleno pomocí kmalloc() nebo vmalloc().

    Průchod iterátorem bez přesouvání dat lze provést pomocí:

        void iov_iter_advance(struct iov_iter *i, size_t size);

    Vyrovnávací paměť, na kterou odkazuje iterátor (nebo jeho část), lze vyčistit pomocí:

        size_t iov_iter_zero(size_t bytes, struct iov_iter *i);

    Informace o iterátoru je k dispozici od řady pomocných funkcí:

        size_t iov_iter_single_seg_count(const struct iov_iter *i);
        int iov_iter_npages(const struct iov_iter *i, int maxpages);
        size_t iov_length(const struct iovec *iov, unsigned long nr_segs);

    Volání iov_iter_single_seg_count() vrátí délku dat v prvním segmentu vyrovnávací paměti. iov_iter_npages() hlásí počet stránek obsazených vyrovnávací pamětí v iterátoru a iov_length() vrátí celkovou délku dat. Poslední funkci je nutno používat opatrně, protože důvěřuje poli len ve strukturách iovec. Pokud tato data pochází z uživatelského prostoru, mohou v jádře způsobit celočíselné přetečení.

    Nejen iovecs

    Definice struct iov_iter uvedené výše se zcela neshodují se skutečnou situací v jádře. Namísto jediného políčka pro pole iov obsahuje skutečná struktura (ve verzi 3.18):

        union {
    	const struct iovec *iov;
    	const struct bio_vec *bvec;
        };

    Struktura iov_iter je tedy také nastavena pro práci se strukturami BIO, které používá bloková vrstva. Takové iterátory jsou označeny zahrnutím ITER_BVEC do bitové masky pole type. Když je takový iterátor vytvořen, všechna výše uvedená volání s ním budou pracovat, jako by to byl „obyčejný“ iterátor, který používá struktury iovec. Prozatím je použití iterátorů využívajících BIO v jádře minimální; nacházejí se jen v kódu odkládací paměti a splice().

    Novinky ve verzi 3.19

    Jádro 3.19 pravděpodobně zaznamená značnou míru změn v kódu iov_iter, které by měly redukovat značný objem standardizovaného kódu potřebného k zavedení všech výše uvedených funkcí. Kód je skutečně kratší, ale za cenu zavedení poměrně velkého zapojení lehce děsivé magie maker preprocesoru, která pomáhá vygenerovat potřebný standardní kód na požádání.

    Kód iov_iter již funguje, pokud je vyrovnávací paměť „user-space“ umístěna v prostoru jádra. Ve verzi 3.19 bude všechno trochu formalizováno a optimalizováno. Iterátor se potom bude vytvářet takto:

        void iov_iter_kvec(struct iov_iter *i, int direction,
    		       const struct kvec *iov, unsigned long nr_segs,
    		       size_t count);

    Pro tento případ také do unionu přibude nové pole kvec uvedené výše.

    Byly také konečně přidány některé funkce, které pomáhají se síťováním; v rámci procesu například bude možné zkopírovat vyrovnávací paměť a generovat kontrolní součet.

    Znamená to tedy, že rozhraní iov_iter se pomalu stává standardním způsobem, jak skrýt mnoho složitostí spojených s manipulací s vyrovnávací pamětí uživatelského prostoru. Do budoucna můžeme očekávat, že bude doporučováno na více místech. Zabralo zhruba jen sedm let, ale zdá se, že iov_iter se blíží do stavu, kdy se stane rozhraním, o kterém bude chtít většina vývojářů jádra vědě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ář

    18.1.2015 16:17 linuxtardis
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Jsem zvědav, jak to bude s verzí po 3.19, jestli bude ta extra stabilní verze 4.0.
    19.1.2015 08:40 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Proč? Co se ti nelíbí na 3.20?
    David Watzke avatar 19.1.2015 17:28 David Watzke | skóre: 74 | blog: Blog... | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Linus něco takovýho před ~rokem naznačil.
    “Being honest may not get you a lot of friends but it’ll always get you the right ones” ―John Lennon
    Max avatar 20.1.2015 00:09 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Jako, vývoj je dobrý, ale myslím si, že se jádro dostává do stadia, kdy by měl jednou za čas takový release vyjít.
    Zdar Max
    Měl jsem sen ... :(
    20.1.2015 08:56 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Nestaci ti jadro 3.2, momentalne 3.2.66?
    Jendа avatar 20.1.2015 10:08 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Nebo obecně nějaké distribuční. LTS je víc, z Debianu a Ubuntu třeba 2.6.32, 3.2 a teď bude 3.16. Nebo CentOS 7 má tuším 3.10.
    20.1.2015 12:13 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    a teď bude 3.16
    ... na kterém mi přestal fungovat software suspend kvůli ovladači radeon. Poslední fungující (z těch, co jsem zkoušel) je pro mě 3.2, takže kdybych to měl řešit, tak je to bisect přes 14 verzí, přičemž přinejmenším jedna z nich mi panikařila už při bootu. :-(
    Quando omni flunkus moritati
    20.1.2015 13:57 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Bisekcia ma priblizne rovnaky pocet krokov, ci ho robis to medzi 2 alebo 14 verziami. Ak vies rychlo kompilovat, tak to mas za hodinku-dve hotove. Pouzivam na kompilaciu 8-jadrovy server a predtym si minimalizujem config. Horsie je, ked nevies bug spolahlivo a rychlo reprodukovat.
    20.1.2015 15:24 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Což reprodukovat to jde snadno, stačí se pokusit uspat na disk. Problém je v tom - už jsem to psal - že mezi verzemi 3.2 a 3.16 mi některá verze (3.10, iirc) panikařila už při bootu. S největší pravděpodobností kvůli jiné chybě taky v ovladači pro grafiku.
    Quando omni flunkus moritati
    20.1.2015 16:13 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    To v principe nie je problem, staci preskocit nefunkcnu verziu (git bisect skip), akurat to predlzi bisekciu.
    21.1.2015 09:47 pc2005 | skóre: 34 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Možná by šlo navíc ten bisect urychlit omezením na powermanagement subsystém.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    21.1.2015 18:43 R
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Toto by som skor obmedzil na radeon. Ale pokym nemas uplnu istotu, je lepsie to nerobit. Lahko sa moze stat, ze budes robit este druhu bisekciu, tentokrat bez obmedzenia :D
    Max avatar 20.1.2015 11:00 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Ne :).
    Zdar Max
    Měl jsem sen ... :(
    22.1.2015 19:56 Petr Ježek | skóre: 10
    Rozbalit Rozbalit vše Re: Jaderné noviny – 10. 12. 2014: Otevření začleňovacího okna verze 3.19
    Díky za perfektní popis iov_iteru. Ten dává rozhodně smysl a vypadá to na velmi kvalitně pojaté řešení.
    Archlinux for your comps, faster running guaranted!

    Založit nové vláknoNahoru

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