abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 03:55 | Komunita

    sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.

    Ladislav Hagara | Komentářů: 0
    včera 22:11 | Nasazení Linuxu

    Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).

    Ladislav Hagara | Komentářů: 0
    včera 13:22 | IT novinky

    Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.

    Ladislav Hagara | Komentářů: 1
    včera 04:55 | Nová verze

    Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.

    Ladislav Hagara | Komentářů: 1
    včera 00:33 | Komunita

    Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.

    Ladislav Hagara | Komentářů: 27
    5.5. 23:22 | Pozvánky

    Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou

    … více »
    bkralik | Komentářů: 0
    5.5. 22:33 | IT novinky

    Dle plánu dnes končí služba Skype. Uživatelé mohou pokračovat v Microsoft Teams.

    Ladislav Hagara | Komentářů: 1
    5.5. 21:44 | IT novinky

    Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.

    Ladislav Hagara | Komentářů: 2
    5.5. 12:33 | Zajímavý projekt

    Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.

    Ladislav Hagara | Komentářů: 1
    5.5. 12:11 | Pozvánky

    Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.

    Ladislav Hagara | Komentářů: 0
    Jaký filesystém primárně používáte?
     (57%)
     (1%)
     (8%)
     (21%)
     (4%)
     (2%)
     (3%)
     (1%)
     (1%)
     (3%)
    Celkem 541 hlasů
     Komentářů: 22, poslední 5.5. 10:06
    Rozcestník

    Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře

    1. 10. 2012 | Luboš Doležel | Jaderné noviny | 2934×

    Aktuální verze jádra: 3.6-rc5. Citáty týdne - pohled zvenčí. Jaderný summit 2012: Údržba stabilních jader; Lepší trasování a ladění; Zlepšování vývojového procesu: linux-next.

    Obsah

    Aktuální verze jádra: 3.6-rc5

    link

    Aktuální vývojová verze jádra je 3.6-rc5 vydaná 8. září. Tak nám vyšlo 3.6-rc5 a všechno vypadá docela v klidu. Až moc, abych pravdu řekl; čekám, kdy se to rozjede, kdy se Greg konečně probere svým mailboxem po jaderném summitu a výletu na kajaku. Mám podezření, že i pár dalších vývojářů bylo potichu kvůli jadernému summitu a cestování s tím spojeným.

    Stabilní aktualizace: verze 3.2.29 vyšla 12. září s obvyklou dávkou důležitých oprav.

    Citáty týdne – pohled zvenčí

    link

    Tohleto není mailing list linux-kernel; tady nemáte právo chovat se neomaleně jen kvůli tomu, že máte špatnou náladu, nesouhlasíte s něčím uvažováním nebo jste omylem vypili kafe bez kofeinu.

    -- Bryan O'Sullivan

    Práva k jadernému kódu samozřejmě patří jaderným vývojářům, kteří aktivně podkopávají vynucování těchto práv. O to tu ale nejde; mají na to právo, i když je to frustrující.

    Morální práva ke kódu zase na druhou stranu patří každému, kdo, kdyby GPL bylo u jádra náležitě vynucováno, by měli právo získat a používat tento kód, který by jim umožnil používat hardware dříve na Linuxu nepodporovaný.

    -- Rich Felker

    Jaderný summit 2012

    link

    Údržba stabilních jader

    link

    V krátkém shromáždění ke konci prvního dne Jaderného summitu 2012 vyjádřil Greg Kroah-Hartman, který se aktuálně stará o stabilní jádra, své obavy o stabilní jádra, a odpovídal na otázky přítomných.

    Greg řekl, že si může stěžovat jen na jednu věc: subsystémy, které neoznačují patche za vhodné pro stabilní řadu. Greg zmínil několik takových subsystémů a současně pochválil Dava Millera za to, že odvádí spoustu náročně práce v síťování. Greg pak vyslechl názory ostatních lidí.

    Ted Ts'o poznamenal: Rád bych označoval některé méně urgentní patche jako 'odložené-stabilní' (stable-deffered), abych je v případě výskytu regresí mohl odvolat. Greg řekl, že se pokusí tuto funkci implementovat, protože to je dobrý nápad.

    Několik lidí chtělo lépe porozumět kritériím, která určují, jestli má patch být zaslán do stabilní řady, někteří poukázali na to, že Greg má v tom, co se považuje za přijatelný patch, trochu nepořádek. Greg toto uznal s tím, že důvěřuje správcům subsystémů, aby rozhodli, co se má zaslat do stable@bger.kernel.org. Co se týče rozhodování, co se má poslat do stable, pochopitelně připomenul Documentation/stable_kernel_rules.txt a shrnutí odůvodnění stable: pokud by patch mohl být zajímavý pro distribuce, které chtějí dodávat stabilní jádro, tak by patch měl být zaslán do stable.

    James Bottomley řekl, že má spoustu patchů pro SCSI, které nejde na stabilní jádro aplikovat, takže z nich odstraňuje tag stable. Zeptal se, co se má v takovém případě dělat?; Greg odpověděl, že by měl tag stable ponechat a pak odpovědět na automatizovaný e-mail, který dostane poté, co se nepodaří patch aplikovat na stabilní strom, se správnou cestou ke staršímu stromu.

    Greg setkání uzavřel otázkou, jestli je současné tempo vydávání stabilních řad v pořádku. Lidé se obecně shodli, že současné tempo – vydání jednou za týden nebo dva – je dobré a mnoho jich také ocenilo, jakou výbornou práci Greg odvádí.

    Lepší trasování a ladění

    link

    Během prvního dne Jaderného summitu proběhla diskuze o zlepšování trasování a ladění jádra pod taktovkou Jasona Wessela a Stevena Rostedta. Jason se zajímal hlavně o to, jak od uživatelů, kteří posílají hlášení o pádu jádra, dostávat lepší údaje.

    Většina diskuze se točila kolem Jasonova návrhu na změny v jádře, které by umožnily, aby součástí backtrace z pádu jádra byla čísla řádek ze zdrojových souborů, aby bylo původ pádu snadnější identifikovat. Navrhovaná technika je implementovaná zahrnutím tabulek ELF s potřebnými informacemi do kompilovaného jádra. S Jasnovým patchem je používání této funkce přímočaré: jádro je konfigurováno s CONFIG_KALLSYMS_LINE_LOCATIONS a kompilováno s ladící informací. Jakmile je to hotové, tak situace jako paniky jádra generují backtrace včetně názvů zdrojových souborů a čísel řádek:

        Call to panic() with the patch set
        ----------------------------------
        Call Trace:
         [<ffffffff815f3003>] panic+0xbd/0x14 panic.c:111
         [<ffffffff815f31f4>] ? printk+0x68/0xd printk.c:765
         [<ffffffffa0000175>] panic_write+0x25/0x30 [test_panic] test_panic.c:189
         [<ffffffff8118aa96>] proc_file_write+0x76/0x21 generic.c:226
         [<ffffffff8118aa20>] ? __proc_create+0x130/0x21 generic.c:211
         [<ffffffff81185678>] proc_reg_write+0x88/0x21 inode.c:218
         [<ffffffff81125718>] vfs_write+0xc8/0x20 read_write.c:435
         [<ffffffff811258d1>] sys_write+0x51/0x19 read_write.c:457
         [<ffffffff815f84d9>] ia32_do_call+0x13/0xc ia32entry.S:427
    

    Lepší backtrace poskytovaný těmito patchi bezpochyby usnadní diagnostiku některých pádů jádra. Má to ale i stinnou stránku: objem paměti spotřebované takovým jádrem je větší. Během diskuze bylo zmíněno číslo 20 MB, ačkoliv v později zaslaném e-mailu Jason upřesnil, že se jedná spíše o 10 MB.

    Značné zvýšení spotřeby paměti jako následek Jasonovy techniky hned vedlo ke skepticismu ostatních, co se užitečnosti týče. Jak někdo poukázal, takové zvýšení by jistě neuvítali uživatelé, kteří jádro provozují například na virtuálních strojích na službách jako Amazon EC2, kde je dostupná paměť (například) omezena na 0,5 GB. Jiní zase řekli, že by pravděpodobně bylo možné dosáhnout toho samého přes vhodně sestavené jádro, které by bylo v případě pádu spuštěno přes kexec(). (Ale i tento nápad byl zpochybňován, neboť i tato technika by mohla vést ke značné paměťové režii.)

    Pak se do debaty vložil Linus, který s návrhem také nesouhlasil. Podle jeho názoru představují paniky jádra natolik malý podíl chybových hlášení, že jsou náklady tohoto řešení neopodstatněné; 1 MB režie by ale byl přijatelý. Linus dále řekl, že při troše snahy by mělo být možné získat podobný traceback načtením jádra do GDB.

    I když patche navrhované Jasonem poskytují užitečné zlepšení v ladění, tento přístup se setkal s takovým odporem, že je nepravděpodobné, že by cokoliv v této podobě bylo kdy začleněno. Jason se ale dost možná ještě nevzdal. V později poslaném e-mailu uvažoval o úpravách, které by mohly srazit využití paměti na nějakých 5 MB, stejně tak o dalších technikách, které by se mohly využít k tomu, aby měl uživatel větší kontrolu nad tím, kdy je tato funkce nasazena v běžícím jádře. Proto je možné, že se tento nápad v nějaké jiné podobě objeví později.

    Zlepšování vývojového procesu: linux-next

    link

    Dalším tématem ke konci prvního dne Jaderného summitu 2012 byl strom linux-next a případný doplňující strom.

    Steven Rostedt řekl, že by rád viděl strom „linux-devel“, který by měl podobný účel, jako měl kdysi strom „-mm“ Andrewa Mortona: bylo by to místo, kde by se rozumně stabilnímu kódu dostalo dalšího testování. Dále řekl, že by takový strom mohl být užitečný kupříkladu pro API, která ještě nebyla stabilizována. Steven se zeptal ostatních, zda i je by cosi takového zajímalo.

    Chris Mason měl pochyby o tom, jestli by takový strom vůbec v praxi fungoval. Když se má a tvá práce spojí dohromady, tak lidé viní mě za tvé chyby a naopak. Na základě zkušeností s podobným přístupem z jiného projektu Ben Herrenschmidt ukázal na další problém: lidé začnou vyvíjet kód proti tomuto stromu namísto proti k tomu určenému stromu (vytvoření linux-devel by mohlo zapříčinit, že lidé začnou vyvíjet proti němu místo linux-next). Tony Luck řekl, že význam linux-devel by se odvíjel podle toho, kolik testování by se mu skutečně dostalo a odhad lidí byl takový, že by se mu dostalo testování ještě méně než linux-next, kterému by se také jistě hodilo testování více.

    I kdyby se došlo k názoru, že linux-devel za tu námahu stojí, bylo by mu třeba najít správce. Na otázku, kolik práce je třeba pro údržbu linux-next, se ozval Stephen Rothwell, že je třeba mezi čtyřmi až deseti hodinami denně, v závislosti na aktuální fázi vývojového cyklu. Steven Rostedt nakonec sám uznal, že reakce na ideu stromu linux-devel byla nedostačující.

    Pozornost se pak přesunula k linux-next. Ted Ts'o se zeptal: jsou lidé spokojení s tím, jak strom funguje? Lidé se shodli, že funguje dobře. H. Peter Anvin to shrnul svým vlastním názorem, že nedokonalosti linux-next jsou odrazem skutečnosti, že jde o výtvor ze skutečného světa. Ted se pak přítomných zeptal – a zjevně očekával odpověď NE – používá někdo z vás linux-next na svém vývojovém systému? a docela ho překvapilo, že značné množství přítomných vývojářů používá své vlastní dílo každý den. Po více než třech letech je jasné, že se linux-next stal důležitou součástí vývojového modelu jádra.

           

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

    1.10.2012 07:48 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    objem paměi spotřebované takovým jádrem je větší Díky za překlad.
    1.10.2012 07:54 Pev | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    &bso; => &nbsp;
    1.10.2012 09:19 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    pochopitelně připomenul Documentation/stable_kernel_rules.txt

    Když se podívám, co všechno jde do stable větví, nemám pocit, že by tahle pravidla ještě někdo bral vážně…

    mirec avatar 1.10.2012 10:58 mirec | skóre: 32 | blog: mirecove_dristy | Poprad
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    Iba mne druhý citát pripomenul nášho prezidenta, budem citovať:
    „Na druhej strane si myslím, že Slovensko niekedy, žiaľbohu, a niekedy je to aj chvalabohu, že žiaľbohu, že na Slovensku predsa len tá pracovná sila je ešte stále lacnejšia a teraz, chvalabohu, že je lacnejšia."
    LinuxOS.sk | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
    Bedňa avatar 1.10.2012 12:02 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    Ja už chválabohu niekoľko rokov nesledujem politiku, pretože mi to žiaľbohu prišlo zbytočné.
    KERNEL ULTRAS video channel >>>
    1.10.2012 14:14 Jindřich Makovička | skóre: 17
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    Hm, Riche Felkera si pamatulu z MPlayer mailing listu, a vždycky to byl tak trochu magor. Občas mu zdatně sekundoval Ivan Kalvachev.
    D.A.Tiger avatar 1.10.2012 21:12 D.A.Tiger | skóre: 8 | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    ...Lepší backtrace poskytovaný těmito patchi bezpochyby usnadní diagnostiku některých pádů jádra. Má to ale i stinnou stránku: objem paměi spotřebované takovým jádrem je větší. Během diskuze bylo zmíněno číslo 20 MB, ačkoliv v později zaslaném e-mailu Jason upřesnil, že se jedná spíše o 10 MB. ...
    Celé je to dobrý nápad, ale stejně bych byl rád, aby celý ten mechanizmus byl postaven tak, aby jej bylo možno při kompilaci kompletně vyřadit.
    Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
    2.10.2012 17:05 filbar | skóre: 36 | blog: Denicek_programatora | Ostrava
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    A proč při kompilaci? Nebylo by lepší při bootu udělat volbu pro debug a non nebug jádro? ;-)
    D.A.Tiger avatar 2.10.2012 17:59 D.A.Tiger | skóre: 8 | Brno
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    No jde mi o to, že jsou stroje, kde takový věci nechci a nevyžaduji; navíc, čím méně je tam zbytečností, které zabírají paměť, zdržují při startu, nebo při práci (jádra), tím lépe. A počítám, že pravděpodobně díky těm tabulkám to bude hodně rozlezlé po jádře, tak si říkám, že by bylo mnohem jednoduší to při kompilaci (vyžaduje-li to uživatel) to do toho jádra buď přidat, nebo to z něj vyříznout.

    Konec konců, já mám na komplu většinou dvě verze jednoho jádra: optimalizovanou, co nejvíce monolitickou, ořezanou o všechny možné debug funkce a zbytečnosti na "ostrý provoz". Druhou zkompilovanou s různýma debug volbama a vším možným "co by se mohlo hodit na hraní" :) I když je pravda, že k té druhé se poslední dobou dostávám čím dál, tím méně.... Není holt "na hraní" čas...
    Radost z toho, že někdo objeví něco nového, je omyl starý 6000 let... (Jean Paul) | anthill inside
    Otto Šabart avatar 3.10.2012 01:35 Otto Šabart | skóre: 13 | blog: KatiePC blog
    Rozbalit Rozbalit vše Re: Jaderné noviny – 13. 9. 2012: Vývojové procesy v jádře
    Po více než třech letech se jasné
    Po více než třech letech je jasné
    *´¨)¸.·´¨)¸.·***·>>> www.seberm.com

    Založit nové vláknoNahoru

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