AbcLinuxu:/ Články / Jaderné noviny 320

Štítky: audio, C, e-mail, Git, hardware, HTML, Intel, KDE, kernel, komunikace, Linux, MIDI, ovladače, patch, programování, udev, Version Control System, web

Jaderné noviny 320

8. 9. 2005 | Robert Krátký | Jaderné noviny | 4348×

Výchozí hodnota Hz. Nový projekt pro testování výkonu jádra. Návod k používání gitu. Pár rad pro začínající hackery jádra. Autor DevFS po dlouhém mlčení obhajuje své dílo.

Výchozí hodnota Hz, 18 e-mailů

12. črc - 21. črc

Linus Torvalds oznámil Linux 2.6.13-rc3 a Lee Revell poznamenal: Výchozí hodnota Hz je pořád 250. Jak už bylo vysvětleno v jiném vláknu, způsobí to, že některé aplikace, např. MIDI sekvencery, nebudou fungovat, ale žádné velké ušetření energie baterií to nepřinese. Dokud nejsou tyhle problémy vyřešeny, měla by být výchozí hodnota 1000. Ale Linus odpověděl:

Přestaň s tím už otravovat. Já tu diskuzi viděl a naprosto nesouhlasím s tím, že by "to tam bylo vysvětleno". To prostě není pravda.

Pravda je pouze to, že 100Hz je pro některé účely příliš málo a 1000Hz je pro některé účely příliš moc. NIKDO nedemonstroval, že by 250Hz nebylo v pořádku. Lidi si jen stěžovali a kňourali, že to možná není v pořádku.

Faktem je, že programování je o nacházení řešení, které funguje "dostatečně dobře". Pokud si _ty_ myslíš, že 1000Hz je správná odpověď, pak si to tak _ty_ nastav. Ale pokud nedokážeš pochopit skutečnost, že jiní lidé mají jiné názory, proč by s tebou o tom měl někdo diskutovat?

Tohle je základní fakt programování (a vlastně jakékoliv jiné oblasti života):

Nedokážeš-li uznat, že jiní lidé mají jiné cíle a potřeby než ty, pak proč se s ostatními lidmi vůbec bavíš?

Takže to nechte být. Uvědomte si, že pro Hz neexistuje "perfektní" hodnota. 250 je teď právě docela rozumné, a máš-li extrémní potřeby, můžeš vždy zvolit svou vlastní hodnotu. Nenuť však své představy ostatním.

A mimochodem, až si někdo bude příště stěžovat ohledně Hz, budu chtít OPRAVDOVÁ DATA. Nechci kňourání. Přestaňte mě dávat do CC, nemáte-li skutečná data a neumíte-li pochopit, že jiní lidé mají _jiná_ skutečná data.

Lee odpověděl: OK, pochopil jsem. S tímhle problémem jsem v LKML skončil. Pokud o tom chce někdo dále diskutovat, pojďte do konference linux-audio-dev.

Nový projekt pro testování výkonu jádra, 9 e-mailů

14. črc - 15. črc

Kenneth W. Chen napsal:

S radostí oznamuji, že jsme založili projekt pro sledování výkonu jádra hostovaný na sourceforge.net:

http://kernel-perf.sourceforge.net

V LKML se mnohokrát diskutovalo o tom, že linuxové jádro potřebuje systematický a disciplinovaný způsob, jak pravidelně měřit a sledovat jeho výkonnost. Abychom toho dosáhli, rozhodli jsme se pravidelně provádět rozsáhlou sadu benchmarků, které pokrývají základní komponenty jádra (správa virtuální paměti, I/O subsystém, plánovač procesů, souborový systém, síť, ovladače zařízení atd.). Benchmarky jsou spouštěny každý týden na různých platformách (4P Intel Xeon procesor, 2P Xeon, několik serverových strojů ia64 atd.) a měří poslední snapshoty Linusova git stromu. Souhrnná data o výkonu v našich testech budou vydávána tak, aby k nim byl snadný přístup.

Naším cílem je pracovat s linuxovou komunitou na zvyšování výkonnosti jádra. Data dostupná na našich stránkách umožňují členům komunity sledovat zlepšení a zhoršení výkonu u každé verze jádra.

Andi Kleen odpověděl:

Tohle je výborné. Díky moc.

Bylo by možné do grafů pro porovnání přidat i údaje o 2.4.30 a případně i o jednom nebo dvou distribučních jádrech (dejme tomu RHEL3/4, SLES8/9)? Jsou to velmi vyladěná jádra a ukázalo by se tak, kde za nimi hlavní jádro zaostává.

A spouštěli jste netperf? Lokálně nebo k jinému stroji? Asi by to bylo dobré zdokumentovat.

Také by bylo fajn mít nějaké oprofile výpisy z pár testovacích průběhů.

Kenneth odpověděl, že pro hlavní jádra se rozhodli kvůli konzistenci, ale zkusí přidat i distribuční. Ohledně netperf Kenneth potvrdil, že byl spouštěn lokálně, a že to uvede v dokumentaci. O výpisech oprofile Kenneth řekl: Na tom se pracuje. Profilová data budeme uploadovat. S oprofile mám u některých verzí jádra problém, který se právě teď řeší. Andi reagoval Pokud používáte staticky zkompilovaná jádra, můžete klidně použít i starý readprofile. Jen nefunguje s moduly. A Randy Dunlap připojil: Lze zařídit, aby fungoval i s moduly (šlo to s 2.6.6), ale kdybych měl na výběr, tak bych prostě moduly nepoužíval.

Návod k používání gitu, 1 e-mail

15. črc

Jeff Garzik napsal:

Aktualizoval jsem svého průvodce pro rychlý začátek s gitem:

http://linux.yyz.us/git-howto.html

Odkazuje teď na každodenní snapshoty pro počáteční nahození [bootstrapping] od DaveJ a je lépe organizovaný pro snadnější navigaci.

A bonusový návod: jak importovat Linusovy pack [balík] soubory (je to snadné).

Tento návod předpokládá, že máte repozitář s vanilla jádrem od Linuse (/repo/linux-2.6) a svůj vlastní repozitář (/repo/myrepo-2.6).

$ cd /repo/myrepo-2.6
$ git-fsck-cache                # fsck, ujisti se, že jsme v pořádku
$ git pull /repo/linux-2.6/.git # ujisti se, že jsme aktualizovaní
$ cp -al ../linux-2.6/.git/objects/pack .git/objects
$ cp ../linux-2.6/.git/refs/tags/* .git/refs/tags
$ git-prune-packed
$ git-fsck-cache         # fsck č. 2, ujisti se, že jsme v pořádku

Tento postup zmenšil mojí synchronizaci s kernel.org z nějakých 50 000 na 5 000 souborů.

Pár rad pro začínající hackery jádra, 8 e-mailů

18. črc - 19. črc

Někdo se zeptal, jak se stát vývojářem jádra, a několik lidí poskytlo své rady. Jesper Juhl napsal:

Pár věcí, které bys měl udělat:

Podívej se do adresáře Documentation/ ve zdrojovém kódu jádra, najdeš tam množství cenných informací.
Prohlédni si http://kernelnewbies.org/.
Možná ti bude připadat užitečný i tento online prohlížeč zdrojových kódů (mně připadá) http://lxr.linux.no/.
Ulož si mezi záložky odkaz na archív LKML a prohledávej archívy vždy, když budeš mít nějakou otázku. Je pravděpodobné, že ať už se tvůj dotaz týká čehokoliv, už se na to někdo ptal před tebou a bylo to v konferenci podrobně vysvětleno. Můžeš použít třeba tento archív: http://www.ussg.iu. edu/hypermail/linux/kernel/.
Přihlas se do LKML a začni číst některá vlákna. Čtením hlášení o chybách a jejich řešeních se toho lze hodně naučit. Často se také diskutuje o nápadech, detailech implementace, debuggování atd., což může být vše hodnotné. Takže se přidej a začni poslouchat :). A nezapomeň si přečíst FAQ konference na http://www.tux.org/lkml/.
Můžeš se také přidat k Linux Kernel Janitors http://janitor.kernelnewbies.org/ - mají konferenci a pěkný seznam TODO - dobré místo, kde najít malý projekt do začátku.
Také bys měl nejspíše investovat do pár knih o jádře a přečíst je. Já bych doporučil tyhle dvě jako dobrý start: "Linux Kernel Development (2. vydání), Robert Love" a "Linux Device Drivers (3. vydání), Jonathan Corbet, Alessandro Rubini a Greg Kroah-Hartman".
A nejdůležitější ze všeho - začni číst zdrojové kódy jádra, hraj si s nimi. Čtení kódu, provádění změn, testování a učení se z chyb je výborný způsob, jak se učit.

A v dalším emailu doplnil:

Pomoci můžeš také testováním vývojových jader - potřebují otestovat co nejvíce lidmi. Začni testováním -rc jader, každodenních git snapshotů a také -mm jader. Vyzkoušej, jestli se zkompilují s tvou běžnou konfigurací, s "allnoconfig", "allyesconfig", "allmodconfig" a třeba s pár náhodnými konfiguracemi. Zjisti, jestli v pořádku nabootují, jestli mohou bez problému delší dobu běžet atd.

Když narazíš na problém, můžeš ho zkusit sám opravit a poslat patch do konference a osobě, která za daný kód odpovídá. Pokud problém neumíš opravit, pošli do konference a osobě odpovědné za kód podrobné hlášení o chybě. Podívej se na soubory REPORTING-BUGS a Documentation/BUG-HUNTING.

Brian O'Mahoney souhlasil s Jesperovými radami, ale připojil, že testování a vývoj jádra by se neměl dělat na "hlavním počítači". A pokud ano, tak je třeba neustále zálohovat. Kromě toho upozornil, že pro používání nástrojů jako kdb, kgdb a kprobe je potřeba sestava dvou počítačů.

Autor DevFS po dlouhém mlčení obhajuje své dílo, 4 e-maily

18. črc

Mezi diskuzemi o odstranění DevFS z jádra se poprvé po letech na krátko objevil původní autor DevFS, Richard Gooch. Stručně reagoval na některé výroky Grega KH.

Greg prohlásil, že Richard uznal udev jako správnou náhradu za DevFS. Richard odpověděl: Tak to je pro mě novinka!

Greg také řekl, že DevFS by mělo být odstraněno, protože postupy [policy] by měly být implementovány v uživatelském prostředí, ne v jádře. Richard poukázal na to, že SysFS, které z velké části vyvinul Greg, také implementuje postupy v jádře.

Na Gregův názor, že DevFS je nepořádek a zmatek, Richard řekl, že to záleží na tom, kdo se dívá.

A na Gregovo tvrzení, že DevFS nefunguje a nelze opravit, Richard prostě odpověděl: Žádný důkaz. Nikdy neříkej nikdy...

Jan Engelhardt se zeptal, kde byl Richard celé ty roky, očekával-li že bude DevFS spravováno a zachováno v jádře. Daniel Phillips odpověděl, že ho vyhnal svými neúnavnými útoky Alexander Viro.

V originálu Kernel Traffic 320 vyšla navíc ještě tato témata:

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.