kernel xconfig vs. qt4

3.8.2010 18:23 | Přečteno: 1226×

Pokud make xconfig vybleje hromadu errorů, může to být tím že vanilkový kernel si neporadí s Qt4.

Řešením je patch který se bohužel zatím do mainline (ještě teplá 2.6.35) neprobojoval. Legrační na tom je, že s qt3 mi poslední mainline verze taky nefungovaly. Tedy, teoreticky fungovaly - zkompilovalo se to, spustilo se to. Ale s fontem, který se skládá výhradně ze čtverečků to není úplně to pravé…        

Komentáře

[xxx]

Není trochu zbytečný používat nějakej patch, když existuje menuconfig?

[rADOn]

Polozil jsem si tutez otazku, jen jsem ji trochu jinak frazoval.

[Jardík]

Není patch menší, než ncurses+závislosti?

[David Watzke]

Qt3 xconfig mi funguje, nedávno jsem pro něj psal pár-řádkovej patch, abych získal strom dostupných konfiguračních voleb. (Že bych třeba obnovil kernel wiki.)

[pc2005]

Tak xconfig jsem dneska viděl poprvé . Vypadá hezky, je tam hlavně vidět všechno najednou. Ale přes ssh by asi moc používat nešel :-/, takže ho asi používat nebudu.

[Grunt]

Spíš by potěšil patch, který by rozjel menuconfig pod Widlema. Bohužel, to díky jednoduchosti terminálu a ncurses nehrozí.

[VSi]

Jako že by to šlo v okně cmd.exe? K čemu to? To by se spouštělo přímo na Windows nebo přes ssh? V putty menuconfig funguje OK.

[Grunt]

Jako že by to šlo v okně cmd.exe?

Problém není v tom emulátoru z Windows (zkoušel jsem i urxvt), ale v samotných Windows.

K čemu to?

Třeba aby se dala nastavit konfigurace i ve Windows? S make config to není moc slavné (teda aspoň já osobně neznám člověka, kterému by se chtělo prolézat všechny konfigurační volby a na každou jednotlivě odpovídat Y/N) a s make gconfig je to podobně slavné. Jen to Qt mě nenapadlo, to je pravda.

To by se spouštělo přímo na Windows nebo přes ssh?

Jak přes ssh? No jasně že přímo ve Windows. S pomocí MinGW a MSYSu to není (většinou) problém až na těchto pár drobností.

V putty menuconfig funguje OK.

A k čemu je mi v Putty když nemám po ruce žádný UNIXový stystém ale jen Windows?

[pc2005]

To si můžeš sestavit nějaký jednoduchý evaluátor z Kconfig sám. Grafický frontend pak není problém .

[Grunt]

Nač vymýšlet znova kolo? IMHO make menuconfig nad očekávání dobře.

[pc2005]

Chtěl jsi nastavovat konfiguraci ve Windows a jestli menuconfig nefunguje, tak ho buď portovat a nebo si udělat vlastní grafiku.

[Grunt]

a jestli menuconfig nefunguje

Jo, ale není to kvůli menuconfig samotnému, ale kvůli neshodě ncurses a oken.

[pc2005]

Teď jen zda zprovoznění ncurses a oken trvá dýl než vlastní čistá implementace... Btw nejlepší by bylo, kdyby měl někdo nějaký generátor pro html/php/js. Třeba takovej etherboot je vtipnej, člověk nakliká na webu parametry a ono to vyplivne binárku. Tady by to akorát vyplivlo .config (i když i hotový jádro by se hodilo). Akorát by asi byl problém dostrkat někam všechny Kconfigy.

[Grunt]

Teď jen zda zprovoznění ncurses a oken trvá dýl než vlastní čistá implementace...

Není to zas taková katastrofa. Jen pár hacků.

Btw nejlepší by bylo, kdyby měl někdo nějaký generátor pro html/php/js.

Ale fuj. V tomhle jsem zajedno s Frantou.

[pc2005]

Ale fuj. V tomhle jsem zajedno s Frantou.

No pravda, je to trochu overkill (a stejně jsem si pak stáhnul zdrojáky etherbootu samotný ). Každopádně by to chtělo nějakej jazyk nezávislej na hw, kterej to bude, už je nepodstatné. Schválně zda by šly rozjet ncurses třeba i na symbianu .

[VSi]

Třeba aby se dala nastavit konfigurace i ve Windows? S make config to není moc slavné (teda aspoň já osobně neznám člověka, kterému by se chtělo prolézat všechny konfigurační volby a na každou jednotlivě odpovídat Y/N) a s make gconfig je to podobně slavné. Jen to Qt mě nenapadlo, to je pravda.

No to by mě vůbec nenapadlo ani v divokém snu. Že bych si na Windows rozbalil zdrojáky kernelu, a dal make menuconfig / gconfig. To bys chtěl i kompilaci dělat na Windows pomocí MSYS / MinGW?

Sám mám na desktopu Windows, a konfiguraci a kompilaci jádra dělám vždycky přes ssh na nějakém stroji s rychlou linkou a velkým výkonem Pro offline situace mám VMWare Server s linuxovou VM. Kdybych chtěl make gconfig, tak lze na Windows pustit X server a spustit to přes ssh.

Jak přes ssh? No jasně že přímo ve Windows. S pomocí MinGW a MSYSu to není (většinou) problém až na těchto pár drobností.

Myslel jsem, když se použije ssh klient třeba z cygwinu puštěný v cmd.exe, tak tam ncurses nefungují zrovna podle očekávání.

A k čemu je mi v Putty když nemám po ruce žádný UNIXový stystém ale jen Windows?

Já bych radši zprovoznil coLinux nebo bych si na Windows pustil virtuální stroj, než si hrát s MSYS / MinGW / cygwin za účelem konfigurace kernelu. I když to je možná overkill, tak lidí co chtějí konfigurovat kernel na Windows bude možná míň, než těch co používají make config.

Jo, dost mě štve make oldconfig - není nějaká lepší alternativa? Při nové verzi kernelu jsou tam někdy desítky až stovky voleb, a to rozhraní je dost nepřívětivé (třeba se nemůžu podívat, jestli na té volbě nezávisí něco dalšího)...

[pc2005]

Já teda obyčejně otevřu starý konfig v menuconfigu nového jádra.

[VSi]

A ten mě nějak upozorní na to, které volby jsou nové? Všechny návody, co jsem viděl, doporučují spustit make oldconfig.

[pc2005]

Neupozorní no, jedině atributem experimental nebo new u položky. Ale já si stejně procházím všechny položky znova, tak mě to netrápí tolik. A pak taky když si kompiluju jádro, tak proto, že chci nějakou novou specifickou volbu a u tý vím, kde je (nebo taky, že starý jádro jede a pak stejně musím projet všechno ).

Nějaké rozšíření by se ale fakt hodilo. Například kdo víte, že se uprostřed menuconfigu daj hledat volby pomocí (tuším že) lomítka? Já jsem na to přišel víceméně náhodou :-O. Ten ncurses je taky dost graficky prkennej.

[VSi]

Já pro jeden projekt potřebuju zkompilované jádro, u kterého pojede síť + disky na co největším množství moderního HW. Takže obvykle kompiluju verzi třeba o 3 vyšší (2.6.31 > 2.6.34) než předchozí, kterou jsem používal, kvůli ovladači nějaké ethernetové síťovky. A abych to celé vždy procházel, s tím se mi ztrácet čas nechce. Nové volby navíc můžou způsobovat vzájemné zavislosti, takže pro jistotu dělám make oldconfig. To poslední co potřebuju je, aby nově zkompilované jádro neběželo na HW, kde to dříve šlo. Pokaždé testovat každou HW konfiguraci nejde.

Naposledy mě vypekl Atheros ethernet v multimediálním notebooku ASUS. Tvářilo se to OK, odeslal jsem přes ten ethernet desítky GB, ale po stažení cca 300 MB spolehlivě totální výtuh, někdy to vypsalo alespoň Machine Check Exception. Ten Atheros ovladač je tuším v Experimental stadiu. Ale už jsem ho úspěšně použil na jiném HW. Jestli to odstraňuje poslední jádro zatím nevím. Ale make oldconfig se mě ptal snad na stovky různých nových voleb (všelijaké GPIO čipy, ovladače podsvícení, ...)

O hledání pomocí lomítka v menuconfig vím, dohledával jsem přes to ty závislosti... To by taky stálo za zlepšení, tahle vizualizace co závisí na čem (typicky věci okolo WiFi mají dost společných částí a sktruktura závislostí není v menuconfig hned jasná).

[Grunt]

Machine Check Exception.

, no tak to IMHO bude problém v něčem jiném než zrovna v ovladačích od Wifiny.

To by taky stálo za zlepšení, tahle vizualizace co závisí na čem (typicky věci okolo WiFi mají dost společných částí a sktruktura závislostí není v menuconfig hned jasná).

No, ono jádro samotné nabobtnalo tak, že už by celé potřebovalo nějaký řešič závislostí jako máme v balíčkovacích systémech. Já zatím používám grep a find a hledám v Kconfig a Makefile souborech.

[VSi]

Není to WiFi, Atheros Gigabit Ethernet, setkal jsem se s ním už na 2 různých desktopových deskách. Ovladač v kernelu je (byl ještě u 2.6.34) experimental.

Měl jsem taky podezření na HW závadu. Ale dělá to úplně stejně u 2 ks nových notebooků. Na Windows 7 / XP vše OK. Ten ovladač např. může zapisovat na nesmyslné místo paměti nebo tak něco, což může vyvolat Machine Check Exception. Ale tohle je poprvé, co jsem MCE viděl.

[Grunt]

Ten ovladač např. může zapisovat na nesmyslné místo paměti nebo tak něco, což může vyvolat Machine Check Exception.

To jde? Já měl za to, že MCE může vyvolat pouze mikrokód procesoru v případě, že selžou interní testy.

[VSi]

Nevím, tu hlášku jsem viděl poprvé, tak jsem hledal pomocí google, a něco v tom smyslu jsem našel. Možná je to blbost. Každopádně podezření na těžkou HW chybu jsem v podstatě vyloučil sledováním totožného chování na 2 strojích a bezvadnou funkcí na Windows. Takže na reklamaci by to neprošlo Podle mě dovnitř toho procesoru nikdo pořádně nevidí, a chyba v jaderném ovladači může způsobit záhadné chování.

Každopádně tu chybu jde na dané verzi jádra (2.6.32, na 2.6.30 to samé) zcela spolehlivě vyvolat ve spojitosti s tím ethernetem. Někdy se Machine Check Exception vypíše, někdy ne. Vytuhne to vždy. Novější jádro jsem ještě nestihl otestovat, problémový stroj nemám teď po ruce, a není to priorita. Ten linuxový systém používám jen na zálohy a klonování disků přes síť.

[Grunt]

Podle mě dovnitř toho procesoru nikdo pořádně nevidí, a chyba v jaderném ovladači může způsobit záhadné chování.

MCE ještě většinou vypisuje důvod chyby (třeba porušení kontextu procesoru) takže doporučuji sledovat. Jediné racionální vysvětlení, které mě napadá je, že karta nějak ovlivňuje buď napájení na cílové mašině a to se dostane až do procesoru a nebo pro signalizaci používá právě špatné napěťové úrovně nebo něco podobného s elektrickým proudem a opět se to dostane až do procesoru. Jinak mě teda nenapadá jak jinak vyvolat MCE softwarově krom vypnutí ventilátorů a přehřátí a zničení procesoru.

Každopádně tu chybu jde na dané verzi jádra (2.6.32, na 2.6.30 to samé) zcela spolehlivě vyvolat ve spojitosti s tím ethernetem. Někdy se Machine Check Exception vypíše, někdy ne. Vytuhne to vždy.

V tom případě mám jednoznačné doporučení: KGDB.

[pc2005]

Ale make oldconfig se mě ptal snad na stovky různých nových voleb (všelijaké GPIO čipy, ovladače podsvícení, ...)

Mám pochyby nad tím, zda ty volby: GPIO čipy, ovladače, ... fakt mohly za chyby Atherosu. Ale možný je vše :-/. Na menuconfigu mě nejvíc štve, že nějaká volba je schopná zakrýt jinou volbu úplně jinde v menu.

[VSi]

Ne, ty volby s tím nesouvisí. Zlobilo to na 2.6.31, tak jsem chtěl zkompilovat 2.6.34, jestli to není opravené. A musel jsem si v make oldconfig tímhle očistcem stovek dotazů projít. Nemůžu se spolehnout, že nějaká nová volba, kterou nezkontroluju, nezpůsobí nefunkčnost půlky věcí. Takže si musím všechny nové volby projít, a nastavit je, i když někdy nejde pořádně zjistit, jaký mají význam a další dopad. Za chybu Atherosu může pofidérní HW a experimentální ovladač.

Na menuconfigu mě nejvíc štve, že nějaká volba je schopná zakrýt jinou volbu úplně jinde v menu.

Přesně tak.

[Grunt]

No to by mě vůbec nenapadlo ani v divokém snu. Že bych si na Windows rozbalil zdrojáky kernelu, a dal make menuconfig / gconfig.

No já osobně si představoval instalátor ve kterém mi naběhne menuconfig, dám Next, stáhne se toolchain a zkompiluje se, pak se zkompiluje jádro, vyplivne bzImage, dám Finish a hotovo (instalace GRUBu ve Windows by mohla být ještě příjemný mezikrok, ale to díky WinGRUBu není nejmenší problém). Ale vystačím si i s pár příkazy.

To bys chtěl i kompilaci dělat na Windows pomocí MSYS / MinGW?

Ne, to nejde. Remcá to nad těmi Windowsými .OBJ. Už jsem to zkoušel. Je potřeba mít nastavený gcc cross-compilátor na ELFy a binutils též. MinGW jen z toho důvodu aby se Kconfig zkompiloval jako EXE a dal se spustit.

Já bych radši zprovoznil coLinux nebo bych si na Windows pustil virtuální stroj, než si hrát s MSYS / MinGW / cygwin za účelem konfigurace kernelu.

To je naprd. To už vyžaduje funkční binárku Linuxového jádra (a jinak zcela nepotřebnou).

I když to je možná overkill, tak lidí co chtějí konfigurovat kernel na Windows bude možná míň, než těch co používají make config.

Netvrdím že ne, ale z důvodu úplnosti by to mělo fungovat.

[pc2005]

No já osobně si představoval instalátor ve kterém mi naběhne menuconfig, dám Next, stáhne se toolchain a zkompiluje se, pak se zkompiluje jádro, vyplivne bzImage, dám Finish a hotovo (instalace GRUBu ve Windows by mohla být ještě příjemný mezikrok, ale to díky WinGRUBu není nejmenší problém). Ale vystačím si i s pár příkazy.

Jo takovej instalátor jsem si pro sebe dělal, abych se nezbláznil ze semestrálního projektu. Je to pár desítek řádků v bashi a v zásadě nakopíruješ konfiguráky (bylo to na FPGA, takže i jiný než .config) spustíš. Ono to otestuje existenci toolchainu, zdrojáků a na konci ti to vyplivne rootfs co se jen nahraje na flashku. Ale bylo to jak jsem říkal na FPGA, takže vysoce specializované.

[Grunt]

Jo takovej instalátor

Sorry. Jsem se špatně vyjádřil. Jsem myslel tenhle instalátor.

[Matlák]

No to je mi ale nápad k čemu to jako má bejt? Nainstaluju barebone linuxové játro na windows-only disk stylem next next next finish??? rofl to bych chtěl mít na linuxu

[Grunt]

Ne, ale každá správná instalace Gentoo nebo LFS začíná kompilací jádra. A to zatím jde jenom zase jenom z GNU/Linuxu a nebo jiných POSIX systémů, ovšem ne z Windowsů. Což je samozřejmě chyba.

k čemu to jako má bejt?

Aby se mohlo říkat, že jádro je natolik univerzální, že se dá přeložit i v konkurenční operačním systému. Dovedl by něco takového ten konkurenční operační systém?

[pc2005]

Přece si nemyslíš, že Vista se kompilovala na normálním stroji. Určitě to bylo na nějakým clusteru, na kterým běžívá právě Linux .

[rADOn]

Musim priznat, ze tohle me nenapadlo. Ani by nebylo nutne to jadro kompilovat, stacilo by ulozit .config a zkompilovat z livecd. Na dnesnim hw je preklad jadra otazka minut, ale proklikat vsecky volby je cim dal vetsi fuska

[Grunt]

Ani by nebylo nutne to jadro kompilovat, stacilo by ulozit .config a zkompilovat z livecd.

To už by nebylo ono. Gentoo lze nainstalovat z libovolného operačního systému bez jediné předkompilované binárky. Teda samozřejmě krom Windows. Ale tady nejde tak ani o to, spíš jako o tu čest. Něco ve symyslu: GCC už je schopno zkompilovat samo sebe nebo jako když se poprvé podařilo zkompilovat Linux na Linuxu.

[Jardík]

msys je 32bit šmejďárna.

[stativ]

Ahaa, to vysvětluje proč to nebere nastavení v qtconfig. Tak pustíme qt3config… Paráda!

[Michal Kubeček]

Ale s fontem, který se skládá výhradně ze čtverečků to není úplně to pravé…

Ale je to větší dobrodružství. :-)