Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Současné vývojové jádro je 2.6.35-rc3 vydané 11. června. Tak jsem byl týden paličatý – možná až moc – a snad to znamená, že 2.6.35-rc3 bude lepší, než bylo -rc2. Nejenom, že jsme zvládli několik regresí, ale také jsme se zbavili toho kousku, co v -rc2 poškozoval paměť a mátl lidi tím, že se projevoval jako spousta jiných chyb podle toho, který kus paměti zrovna poškodil. Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu. Linus nyní bude nějakou dobu offline, takže proud změn do hlavní řady se zpomalí.
Stabilní aktualizace: během minulého týdne žádné stabilní aktualizace nevyšly.
napsal Jake Edge, 16. června 2010
V květnu Jan Kára zaslal patch VFS, který opravoval regresi, a tento patch zaslal i lidem od stabilního stromu. Linus Torvalds poznamenal, že chyba byla zavedena během začleňovacího okna, takže pro stabilní strom patch relevantní není. To vedlo k diskuzi o tom, jak zjistit, která verze jádra obsahuje konkrétní patch. Konverzace je sice měsíc stará, ale rada je víceméně nadčasová.
Metoda Andrewa Mortona není zrovna optimální: Prostě si nechávám spoustu jaderných stromů a kouknu do nic pomocí ,patch --dry-run‘. Otrava. Christoph Hellwig a James Bottomley navrhli git-describe <revid>, což zobrazí značku [tag] verze, na kterou byl patch aplikován nebo do které byl přetažen [pull], pokud použijete příznak --contains. Jak by se ale dalo uhodnout, Linus měl několik promyšlenějších návrhů. Lze použít git name-rev přibližně stejně jako git-describe --contains, ale obskurnější způsob, jak se dostat ke stejným informacím, je:
git log --tags --source --author=viro --oneline fs/namei.c
což ukáže commity Al Vira na fs/namei.c společně s označkovanými verzemi, do kterých je commit zahrnut. Na aktuálním jaderném stromu začátek výstupu vypadá takto:
d83c49f v2.6.34 Fix the regression created by "set S_DEAD on unlink()…" commit 3e297b6 v2.6.34-rc3 Restore LOOKUP_DIRECTORY hint handling in final lookup on op 781b167 v2.6.34-rc2 Fix a dumb typo – use of & instead of && 1f36f77 v2.6.34-rc2 Switch !O_CREAT case to use of do_last()
I když specifický příklad, který Linus použil, nemusí být použitelný obecně, základní nápad za ním ano. git-blame může být při dohledávání commitu, ve kterém byla nějaká změna provedena, často užitečný, ale datum v logu může být zavádějící, když dojde na to, ve kterém jádře (jádrech) daná změna skončila. Použití kombinace describe a log zjišťování těchto věcí mnohem zjednoduší.
napsal Jonathan Corbet, 16. června 2010
Nedávno svou existenci oznámila Iniciativa pro správu běhu [Managed Runtime Initiative]. Tato skupina je odhodlána zajistit, aby kód „spravovaný za běhu“ (konkrétně programy v Javě) na linuxových systémech běžel rychleji. Snaha MRI by nevypadala jako téma pro Jaderné noviny, kdyby nebylo jedné věci: Tato skupina právě vydala tisíce řádků pochybného kódu, o němž tvrdí, že ho chce začlenit do upstreamu.
Specifický problém, který se lidé od MRI (ve skutečnosti zaměstnanci Azul Systems) rozhodli vyřešit, jsou podle všeho přestávky běhu aplikací způsobené sběrem odpadu [garbage collection]. Jejich řešení je implementováno na několika úrovních, některé z nich jsou v jádře. Zvědavci si mohou patche stáhnout z webu MRI, kde jsou užitečně zabaleny do tarballů, které obsahují RPM se zdrojovými kódy. Také ohleduplně začlenili všechny patche Red Hatu; hledejte soubory obsahující „az“, pokud chcete z šumu vytáhnout nové věci.
První jaderný patch přidává rozhraní pro nahrávatelné moduly pro správu paměti. S ním mohou nahrávatelné moduly vytvořit a zabrat vlastní VMA [virtual memory area, oblast virtuální paměti], které následně spravují. Azul dodává modul, který vytváří zvláštní zařízení, které poskytuje několik ioctl() operací pro správu paměti v těchto VMA. Co tento modul skutečně dělá, je trochu nejasné; zahrnuje to dělení paměti do „účtů“ [account] pojmenovaných jako „Ochrana před pauzou při GC“. Zdá se, že je v něm kód, který aplikacím poskytuje transparentní velké stránky. Také je zde nějaký druh uvolněného zamykání ve zvláštních VMA navržených k tomu, aby zlepšovaly škálovatelnost.
Pak je zde patch připojitelného plánovače, který vytváří plánovací třídu SCHED_ALT, která sedí mezi CFS a třídami pro běh v reálném čase. Účel modulu plánovače je popsán takto:
Umožňuje rozdělení systému na „vyhrazená“ [commited] a běžná CPU, zvláštní aplikace budou mít přednostní přístup k vyhrazeným CPU.
Webová stránka MRI tvrdí, že cílem této iniciativy je dostat tyto příspěvky do upstreamu do existujících a doplňujících se OSS projektů (např. kernel.org a openjdk.org), ale pokud autor článku ví, kód spojený s jádrem se nikdy neobjevil v žádné e-mailové konferenci spojené s jádrem. Kód je plný #ifdefů, chybí v něm komentáře a přidává spoustu exportů nízkoúrovňových funkcí kódu z plánovače a VM. A pak je tu ještě malý detail spočívající v tom, že komunita sotva bude souhlasit se základním účelem tohoto kódu. Připojitelné plánovače byly v minulosti již odmítnuty; a doteď se nikdo ani neodvážil navrhnout připojitelné moduly pro správu paměti.
Jinými slovy tu máme spoustu podivného kódu vyvinutého v naprosté izolaci; jednoho by zajímalo, kolika zákazníkům byl dodán. Jestliže Azul Systems a MRI myslí začlenění do upstreamu vážně, možná by měli opravdu brzy začít mluvit s komunitou; dá se očekávat, že budou muset pár věcí změnit.
napsal Jonathan Corbet, 15. června 2010
Přerušení je způsob, jakým zařízení jádru sděluje, že se stalo něco zajímavého. Jednou z klíčových výhod přerušení je to, že se jádro díky nim nemusí zařízení dotazovat [poll], v jakém je stavu. Jenže jako jakákoliv jiná část počítače i přerušení nemusí fungovat dobře, což vede k situacím, kdy je systém zaplaven falešnými [spurious] přerušeními – nebo naopak čeká na přerušení, které nikdy nedorazí. Jádro má ve své obecné vrstvě pro přerušení nějaké obranné mechanismy, které se s takovými situacemi vypořádají; Tejun Heo nyní zaslal sadu patchů, která má tyto mechanismy vylepšit. Věc se má tak, že nutná reakce na špatně fungující přerušení je návrat k dotazování.
Jeden problém, se kterým jsou autoři ovladačů dobře seznámeni, jsou chybějící přerušení. Ovladač typicky nastaví I/O operaci, nastartuje ji a pak čeká, dokud nepřijde přerušení informující o tom, že byla dokončena. Jestliže toto přerušení nikdy nedorazí, ovladač může čekat velmi dlouho. K takové situaci může dojít z mnoha důvodů včetně toho, že je zařízení křáp nebo má systém problémy se směrováním přerušení. Tak jako tak pokud autor ovladače tuto situaci neočekával a nepřidal do ovladače odpovídající opatření – například časový limit – věci nedopadnou dobře.
Čekání na časový limit ale významně zpomalí činnost zařízení. Tento problém lze omezit častým dotazováním zařízení, ale to má svoji režii. Ve snaze získat konzistentně nejlepší výsledky, přidává Tejunův patch nové API ovladačů:
#include <linux/interrupt.h> struct irq_expect *init_irq_expect(unsigned int irq, void *dev_id); void expect_irq(struct irq_expect *exp); void unexpect_irq(struct irq_expect *exp, bool timedout);
Volání init_irq_request() alokuje neprůhledný token, který se používá u dalších dvou funkcí; funkci by mělo být předáno číslo přerušení a stejné dev_id, které se použilo při počáteční alokaci přerušení. Když ovladač zahájí akci, která by měla vést k přerušení od zařízení, zavolá expect_irq(). Po dokončení operace je potřeba zavolat unexpect_irq(), kde timedout udává, jestli vypršel časový limit (tj. přerušení nedorazilo). Všimněte si, že ovladač nemusí struct irq_expect uvolnit; k tomu dojde automaticky při uvolnění přerušení.
Volání expect_irq() zahájí dotazování na dané přerušovací lince, „dotazování“ znamená, že je čas od času zavolána obsluha přerušení zařízení. Ze začátku je toto dotazování poměrně pomalé. Když se ukáže, že zařízení ztrácí přerušení (což je udáno parametrem timedout funkce unexpect_irq()), frekvence dotazování se zvýší až na maximum jednou za milisekundu. Fungující zařízení by mělo přerušit dřív, než dojde k prvnímu dotazu, výsledkem by tedy u spolehlivých zařízení mělo být to, že k žádnému dotazování docházet nebude. Jestliže se ale objeví problém při doručování přerušení, jádro automaticky převezme zodpovědnost za to, že se obsluha přerušení zavolá, když je očekáváno přerušení.
Toto rozhraní funguje dobře, když zařízení ví, že má očekávat přerušení; ne všechna zařízení ale fungují takto. Pro hardware, který může přerušit kdykoliv, je zde tedy API „sledování IRQ“:
void watch_irq(unsigned int irq, void *dev_id);
Tato funkce začne dotazování na specifické přerušovací lince; také sleduje stav doručování přerušení. Jestliže zjistí, že se přerušení ztrácejí (podle návratové hodnoty IRQ_HANDLED obsluhy přerušení volané dotazováním), četnost dotazování se zvýší. V opačném případě se nakonec doručování přerušení bude považovat za spolehlivé a dotazování se vypne.
Tejunův patch také mění způsob, jakým jádro reaguje na falešná přerušení – na ta, která žádný ovladač neobslouží. Současná jádra počítají na každé lince počet přerušení, pro která žádný ovladač nevrátil IRQ_HANDLED; jestliže je 99 000 ze 100 000 přerušení falešných, jádro ztratí trpělivost, danou přerušovací linku vypne a začne používat dotazování. Tato akce má značné náklady, proto jádro dovoluje, aby byl podíl falešných přerušení tak velký; jakmile k této akci dojde, není cesty zpět, i když byla falešná přerušení jenom důsledkem krátkodobé hardwarové chyby.
S mechanismem adaptivního dotazování je tato vlastnost vylepšena a jádro k řešení falešných přerušení přistupuje flexibilněji. Ke spuštění mechanismu nyní stačí 9 900 z 10 000 falešných přerušení; jako předtím je daná přerušovací linka vypnuta a zahájeno dotazování. Po nějakém čase nicméně nový kód přerušovací linku znovu zapne, aby zjistil, co se stane. Jestliže zdroj falešných přerušení zmizel, přerušení lze používat stejně jako předtím. Pokud jsou falešná přerušení doručována nadále, linka je opět zablokována na dobu o něco delší.
O této sadě patchů se zatím příliš nediskutovalo; jeden komentář vyjadřoval obavu, že by dotazování mohlo způsobit, že si uživatelé nevšimnou, že mají nějaký problém. Jak ale Tejun říká, taková reakce je zapotřebí, aby křápovitý hardware poskytl alespoň trochu slušné chování; toto tvrzení podle všeho nikdo zpochybnit nechce. Je tedy poměrně pravděpodobné, že si nějaká další verze tohoto patche najde svou cestu do hlavní řady.
napsal Jonathan Corbet, 15. června 2010
Od roku 2005 projekt realtime preempce pracuje na tom, aby bylo možné dosáhnout deterministické doby odezvy v běžných linuxových jádrech. Za tu dobu se vyjasnilo, že pro to, kdy bude všechen tento kód začleněn, nelze garantovat latenci žádnou. Na LinuxTag 2010 programátor Thomas Gleixner mluvil o stavu této sady patchů, o tom, co se chystá, a ano, i o tom, kdy by ji mohlo být možné začlenit celou. Netěšte se.
Popravdě se kód realtime preempce do hlavní řady začleňuje kousek po kousku již léta. Mezi některé z nedávno začleněných změn patří obsluha přerušení ve vláknech a patche předcházející spícím spinlockům. Obsluhy ve vláknech zjednodušují mnoho činností ovladačům (bez ohledu na běh v reálném čase) tím, že s nimi nejsou tolik zapotřebí tasklety a pracovní fronty. Také se ukázalo, že jsou užitečné při poskytování podpory pro některý podivný hardware pro řízení přerušení připojený přes i2c. Změny spinlocků (v jádrech hlavní řady) neovlivňují generovaný kód, ale jsou užitečné tím, že označují typ zámku.
I přes nedávné přesuny kódu se sada realtime patchů nijak nezmenšuje. Zdá se, že vývojáři mají zajímavý problém: Jádro s během v reálném čase je opravdu dobré místo, kde lze vyzkoušet mnoho nových vlastností. Takže i když se do hlavní řady občas nějaký kód přesune, do realtime stromu je stále přidáván nový kód.
Atraktivita tohoto stromu pro testování nového kódu je způsobena tím, že realtime jádro většinou odhalí problémy se škálovatelností rychleji než jádra hlavní řady. Preempce poskytovaná tímto jádrem je vyvážena dodatečnými náklady: Cena za soupeření zámků je mnohem vyšší. Realtime strom tedy ukáže problémy se škálovatelností při menším soupeření než běžné jádro. Zde je důležité to, že úzké hrdlo pro škálovatelnost u realtime jádra není specifikem tohoto jádra; jenom se objevuje dřív a u hlavní řady se objeví také. Pomocí realtime jádra lze tedy odhalit problémy, které bude mít hlavní řada za rok.
Tak se například u realtime jader objevují problémy se škálovatelností ve vrstvě virtuálního souborového systému, které lze jinak pozorovat jenom v laboratořích pro zátěžové testy na velkém železe. Proto jsou tato jádra užitečná pro testování a obzvláště užitečná pro testování zlepšení škálovatelnosti. To je také důvod, proč sada patchů pro škálování VFS aktuálně bydlí v realtime stromě. Většina kousků bude nakonec začleněna do hlavní řady; Thomas říká, že to bude koncem roku – ale nemá v úmyslu říct, který rok to bude.
Další sada patchů, která by se mohla přesunout do hlavní řady, je série preempce správy paměti Petera Zijlstry, která řeší některé dlouhé latence v kódu správy paměti; současný plán je tlačit tyto patche do 2.6.36. Další kousek kódu k přesunu je možnost donutit všechny ovladače používat obsluhy přerušení ve vláknech bez ohledu na to, jestli si je explicitně vyžádají. Tato volba by téměř určitě na produkčních jádrech zapnuta nebyla, ale zjednodušilo by to testování ovladačů s nedobrovolnými obsluhami ve vláknech.
Realtime strom má také několik nevyřešených problémů. Jeden z nich jsou latence ve slab alokátoru, který dlouhou dobu běží s vypnutou preempcí. Alokátor SLQB přinesl trochu naděje, ale zdá se, že nebude začleněn nijak brzy. Programátoři realtime stromu tedy musí buď vymyslet, jak opravit jeden z existujících alokátorů, nebo se vzdát a napsat si vlastní slab alokátor. Thomas poznamenal, že ve jmenném prostoru SL?B ještě zbývá pár písmen, takže v budoucnu by se klidně mohl objevit SLRB. V tuto chvíli je ale všechno neurčité; Thomas přiznal, že nemá tušení, jak bude tento problém vyřešen.
Další trvající problém je narůstající používání dat specifických pro CPU. V prostředí orientovaném na propustnost data specifická pro CPU zvyšují škálovatelnost tím, že odstraní soupeření mezi procesory. Používání těchto dat ale nutně vyžaduje, aby byla vypnutá preempce, když se s nimi manipuluje; jinak se riskuje, že proces, který na těchto datech pracuje, bude odstraněn preempcí nebo přesunut na jiný procesor, což by nadělalo nepořádek. Zakázání preempce je ale v prostředí, kde má být možné preempci použít kdykoliv, svatokrádež. Sada realtime patchů tedy aktuálně přístupy k datům specifickým pro CPU obaluje zámkem, což řeší problém preempce, ale likviduje škálovatelnost. Ani zde ještě nebylo nalezeno skutečné řešení.
Thomas nakonec mluvil o testování realtime stromu. Hodně testování na „podnikové úrovni“ probíhá v dobře vybavených laboratořích ve firmách jako IBM a Red Hat. Na úrovní embedded zařízení má svoji pěknou testovací laboratoř Open Source Automation Development Lab. Další zajímavý zdroj testování je komunita okolo audia v Linuxu; tito lidé nadšeně používají realtime jádro a pomáhají nalézt mnoho problémů. V kolekci rt-tests roste sada nástrojů pro testování.
Thomas představil realtime jako zdravý projekt, i když stále nevíme, kdy se dostane do hlavní řady. I ve světě realtime preempce jsou věci, na které se prostě musí počkat.
napsal Jake Edge, 16. června 2010
Jaderný strom pro architekturu ARM je velký a poměrně komplikovaný. Protože existuje mnoho různých variant ARM systémů na čipu (SoC) a stejně tak mnoho různých variant samotného CPU ARM, ve stromě architektury dochází ke kombinatorické explozi. To následně vedlo k explozi Linuse Torvaldse, který je již unaven zbytečným chaosem ve stromě.
Zdrojem Linusovy nespokojenosti byl požadavek na přetažení nějakých změn arch/arm/mach-msm od Daniela Wolkera, ale problém jde hlouběji. Na Danielův požadavek zareagoval a upozornil na problém, který u ARM vidí:
arch/arm/configs/ arch/arm/mach-xyz arch/arm/plat-bla
Pokračoval tím, že většina diffů je mysl ubíjející, protože není rozumně čitelná pro lidi. Následně analyzuje problém srovnáním velikosti stromů x86 a ARM, přičemž ten druhý má 800k řádek „kódu“ – přibližně třikrát víc než x86. Z toho je 200k řádek v souborech výchozích konfigurací (tj. defconfig) pro 170+ různých SoC. Pro Linuse tyto soubory nejsou nic jiného než odpad.
Ve skutečnosti dokonce zvažuje zbavit se všech ,defconfig‘ souborů úplně. Každý z těchto souborů reprezentuje konfiguraci, kterou někdo vytvořil, když překládal jádro pro specifický ARM SoC, ale nechávat si je všechny je, jak řekl, prosté plýtvání:
Další problém, který Linus odhalil, je šíření ovladačů specifických pro platformu, které by bylo velmi pravděpodobně možné zkombinovat na sdílené ovladače ve stromě drivers/ nebo jinak sloučit. Jednoduše potřebujeme někoho, kdo bude mít nějakou péči a nebude jenom bezmyšlenkovitě shromažďovat veškerý bordel. Ben Dooks souhlasil, že je zde problém, ale že mnoho velkých hráčů – firem – ještě nevidí potřebu kombinování ovladačů. Také poznamenal, že přinejmenším některé z defconfig souborů se používají pro automatizované testování překladu, nicméně souhlasí, že je mnoho starých výchozích konfigurací, které by měly být odstraněny.
Ben také dlouze popsal problémy, které mají správci ARM, když se snaží podporovat tolik různých SoC a zároveň se snaží omezit velikost a složitost stromů subarchitektur. Tito správci jsou v podstatě zaplaveni a dokud to nezasáhne kapsy těch velkých firem, je velmi těžké donutit je platit za pročištění stromu ARM a za to, aby byl do budoucna udržován čistý.
Protože Linus řekl, že plánuje odstranit soubory s výchozí konfigurací pro ARM (a jiné), správce ARM Russell King zaslal varování do e-mailové konference linux-arm-kernel:
To v této konferenci nastartovalo samostatnou diskuzi – bez ohledu na snahu Russella a dalších namířit ji zpět na linux-kernel – o způsobech, jak zredukovat množství většinou redundantních informací obsažených v defconfig souborech. Ryan Mallon je příznivcem odstranění některých defconfigů, zatímco jiní diskutovali různé způsoby, jak udržovat jenom rozdíly mezi konfiguračními soubory jednotlivých SoC.
Podle Linusových komentářů na linux-kernel schéma s uchováváním rozdílů pravděpodobně neprojde. Jeho hlavní stížnost je to, že soubory defconfig nejsou čitelné pro člověka, protože je generují různé nástroje. Navrhl několik specifických alternativ, které by umožňovaly generování těchto souborů s tím, že by se používaly soubory Kconfig, které jsou čitelné pro člověka.
Omezení počtu výchozích konfigurací, které navrhl Ryan, by mohlo pomoci, ale minimálně Russel je přesvědčen, že by to nešlo dost daleko. Věří, že Linus se již rozhodl odstranit výchozí konfigurace v příštím začleňovacím okně a ARM komunita by se měla připravit na něco jiného:
Diskuze se zaobírala jak možnými řešeními okamžitého problému s defconfig, tak s větší záležitostí ohledně omezení duplikací v ARM stromech. Aktuálně je tu snaha vytvořit jediné jádro, které by pro Ubuntu 10.10 podporovalo několik ARM platforem, což pravděpodobně pomůže některé subarchitektury zkonzolidovat. Vzhledem k tomu, že Canonical úzce spolupracuje s nově zformovanou organizací Linaro – která byla založena, aby zjednodušila Linux pro ARM – je zde důvod věřit, že věci se zlepší.
Mezitím na linux-kernel Linus založil nové vlákno, ve kterém nastínil své nápady ohledně hierarchické sestavy souborů Kconfig, které by nahradily soubory defconfig. Po nějaké diskuzi dal Linus příklad toho, co přesně navrhuje:
config MYCONFIG bool default y select USB source arch/x86/Kconfig
KBUILD_KCONFIG=Mykconfig make allnoconfig
Poté pokračoval teoretickým souborem Kconfig.omap3_evm, který by nastavil specifické parametry pro danou platformu a poté zahrnul Kconfig.omap3. Daný soubor by nastavil všechno, co je potřeba pro platformu OMAP3, a zahrnul Kconfig.arm. To by umožnilo vývojářům i nástrojům, jako je autobuild, vygenerovat potřebné konfigurační soubory bez nutnosti mít je přímo ve stromě. Dané soubory Kconfig by také byly mnohem čitelnější a diffy pochopitelnější, což je pro Linuse důležité.
To řeší významnou část problému, ale je tu ještě malá muška: závislosti. V Linusově příkladu CONFIG_USB vyžaduje CONFIG_USB_SUPPORT, což by bylo nutné přidat do Mykconfig. Když se zapomene na závislosti, vznikne jádro, které se buď nepřeloží, nebo ještě hůř, nebude fungovat správně. Závislosti mají nicméně několik možných řešení od patche Catalina Marinase, který sleduje nesplněné závislosti voleb použitých ve výrazech select, po projekt Summer of Code Vegarda Nossuma, který přidává do editorů konfigurace (menuconfig atd.) řešitele závislostí.
Rozhodně se zdá pravděpodobné, že v začleňovacím okně 2.6.36 budou soubory defconfig odstraněny. Jestli se objeví jiné řešení – založené na Linusových nápadech nebo jiné – které je nahradí, je na týmech starajících se o architektury, protože Linus se bez nich bez problémů obejde. ARM, PowerPC, MIPS a další mají spoustu souborů s výchozí konfigurací, ale pokud Linus nezmění názor, během několika měsíců je mít nebudou. Mohou je tedy buď udržovat někde v samostatném archivu, nebo najít přijatelnou metodu, jak je generovat. Krátkodobě to možná přinese problémy, ale jádro se tím zmenší a Linusovi to zjednoduší práci, což obojí stojí za snahu.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: