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

Štítky: Apache, BSD, C, Git, hardware, Intel, Internet, kernel, kompilace, Makefile, OpenBSD, patch, PCMCIA, programování, proxy, RSS, sítě, Version Control System

Jaderné noviny 333

8. 12. 2005 | Robert Krátký | Jaderné noviny | 4738×

Pročištění kódu pro detekci HT a Multi Core. Úvahy o kódování cest k souborům v git. git na OpenBSD. Manuálové stránky verze 2.08. Problémy se zátěží z gitweb.cgi na kernel.org.

Pročištění kódu pro detekci HT a Multi Core, 14 e-mailů

5. říj - 13. říj

Suresh B. Siddha napsal:

Tento patch pročišťuje kód detekující x86 a x86_64 Intel HT a Multi Core. Dotýká se následujících oblastí:

a) Pročištění a sloučení kódu pro detekci HT a Multi Core na x86 a x86_64.

b) Pole získaná přes cpuid vektor 0x1(ebx[16:23]) a vektor 0x4(eax[14:25], eax[26:31]) značí maximální hodnoty a nemusí být vždy shodná s tím, co je dostupné a co vidí OS. Takže si dejte pozor na to, aby hodnoty "siblings" a "cpu cores" v /proc/cpuinfo obsahovaly hodnoty tak, jak je vidí OS, ne podle instrukcí cpuid. Tím se také napraví případy vadných BIOSů (například když cpuid na jednojádrovém CPU hlásí, že jsou tam "2" sourozenci [siblings], ačkoliv je HT v BIOSu vypnuto http://bugzilla. kernel.org/show_bug.cgi?id=4359).

c) Opravuje kód detekce keše, který očekával, že počet vláken sdílejících keš bude roven buď počtu jaderných nebo HT sourozenců.

Andi Kleen si všiml několika #ifdef, které do kódu nepatřily. Poznamenal, že se Suresh snaží mezi architekturami sdílet příliš kódu. Chvíli se dohadovali o tom, co má Andi vlastně na mysli, až v jednu chvíli Andi řekl: Byl bych raději, kdyby ta podpora detekce intelských CPU nebyla rozdělena na tolik malých souborů. Pokud bys ji chtěl sdílet, dej vše do jednoho souboru a sdílej ten. Ale jen kód, který je možné sdílet čistě, bez ifdef. A doplnil: Také by obecně bylo vhodnější, kdybys nejprve provedl pročištění a pak teprve přidal samostatné patche s různými zlepšeními. Je pak snazší změny kontrolovat a pomáhá to při binárním prohledávání v případě problémů. Suresh odpověděl: Nechme to sdílení kódu na později. Chci mít jen jistotu, že se tato zlepšení dostanou do -mm stromu (a pak i 2.6.15) než odjedu na dovolenou:). Poslal patch a pokračoval s Andim v probírání technických podrobností.

Úvahy o kódování cest k souborům v git, 33 e-mailů

7. říj - 14. říj

V mailové konferenci o git se objevila otázka, jak by měl git řešit taby a odřádkování v cestách. V jednu chvíli začal Paul Eggert uvažovat, jak by bylo možné podporovat používání různých druhů kódování znaků pro názvy souborů; a Linus Torvalds odpověděl:

To prosím nedělejte. Berte názvy souborů jako binární kusy dat, to je jediný způsob, který má dobrou šanci uspět. Ano, nemusí fungovat v případě, že bude překlad znaků provádět ještě něco jiného, a/nebo kdyby lidi měnili kódování patche na jiné, ale to se dá říct o všech způsobech.

Nakonec snad budou všichni používat UTF-8 a o nic jiného vlastně nejde. Ale podstatné je, že když vidíte názvy souborů jako kusy dat, funguje to i s UTF-8, takže to nebude "špatně" ani z dlouhodobého hlediska. A dokud nebudou všichni používat jediné kódování, nepůjde to prostě poznat a bude velmi snadné něco zvorat.

Šikovné je na způsobu "kusu binárních dat" to, že mu uživatelé rozumí. Lidi, kteří aktivně používají různé formáty kódování, o konverzích moc dobře vědí a možná vás budou proklínat, že nepoužíváte jejich náhodné kódování podle denního menu, ale budou mít možnost si s tím poradit.

Naproti tomu, když začnete provádět konverze, můžu vám zaručit, že si s tím lidi neporadí, uděláte-li něco divného - změnili byste data.

Osobně bych dával přednost normálnímu citování v C. Mezery ponechte a tab/odřádkování jako \t a \n. Mezi programátory je to docela všeobecně známé, i mimo C. A není nutné, aby takovému velmi neobvyklému formátu patchů rozuměl i někdo jiný.

Také to má zřejmý a pro ASCII bezpečný formát pro další znaky (tj. normální osmičkový zápis: \377 apod.

Přesto si však nemyslím, že to stojí za námahu. Chce-li někdo používat názvy s taby a odřádkováním, bude pracovat s diffy? Nebo je to jen chyba ovladače?

git na OpenBSD, 17 e-mailů

10. říj - 13. říj

Randal L. Schwartz si všiml, že git Makefile obsahuje OpenBSD mezi podporovanými platformami; ale když zkoušel kompilaci, narazil na chyby. Linus Torvalds napsal, že by měl použít make NO_STRCASESTR=1 nebo to přidat přímo do Makefile a poslat Juniovi otestovaný patch ;). Junio C. Hamano reagoval, že už to bylo opraveno. Randal to vyzkoušel a úspěšně rozchodil git na OpenBSD. Zároveň se nabídl, že pomůže s psaním dokumentace ke git.

Manuálové stránky verze 2.08, 4 e-maily

12. říj - 13. říj

Michael Kerrisk napsal:

Nedávno jsem vydal man-pages-2.08. Obsahují sekce 2, 3, 4, 5 a 7. Popisují následující věci:

2: (linuxová) systémová volání
3: (libc) funkce knihovny
4: zařízení
5: formáty souborů a protokoly
7: přehledové stránky, zvyklosti atd.

Co se týká této konference, tak nejvíce relevantní části jsou celé sekce 2 a 4, které popisují rozhraní jádro-uživatelský prostor; v sekci 5 manuálová stránka proc(5), která se snaží (pořád je trochu pozadu) být vyčerpávajícím popisem /proc; a různé stránky v sekci 7, z nichž některé obsahují přehled funkcí jádra (např. síťové protokoly).

Připojuji žádost vývojářům jádra: provedete-li změnu v rozhraní jádro-uživ. prostor nebo všimnete-li si rozdílu mezi manuálovými stránkami a skutečností, mohli byste mi prosím poslat (mtk-manpages@gmx.net) jedno z následujícího (nejlepší nahoře):

In-line "diff -u" patch s textem změn pro danou manuálovou stránku. (Nejčerstvější verze manuálových stránek je vždy na ftp://ftp.win.tue.nl/ pub/linux-local/manpages nebo ftp://ftp.kernel.org/ pub/linux/docs/manpages.)
Email s popisem změn, který pak mohu zařadit do příslušné manuálové stránky.
Zprávu upozorňující na to, že některá část manuálových stránek neodpovídá realitě. Já se to časem pokusím napravit.

Je zřejmé, že čím níže na seznamu, tím více mého času je potřeba, a může to déle trvat. Zvláště pokud se změny týkají některé z částí jádra, o kterých nic nevím, a nepodaří se mi sehnat pomocníka.

Na jiném místě dodal: Největší zásluhu má Andries, který byl správcem skoro 10 let. Já budu za chvíli mít své první výročí...

Jesse Barnes odpověděl: Dávalo by smysl, kdyby byly manuálové stránky (možná všechny), které se týkají konkrétních jaderných rozhraní (např. systémová volání, procfs & sysfs), dodávány přímo s jádrem? Andrew si všeobecně docela dobře hlídá, aby lidi aktualizovali věci v Documentation/, když je to třeba, takže pak by možná byly manuálové stránky udržovány aktuálnější (kdyby byli vývojáři nuceni se jimi zabývat). Michael odpověděl: Nedávno jsem uvažoval nad tou samou věcí. Je však potřeba vzít v potaz určité komplikace. C knihovny (ok, hlavně si dělám starosti o glibc) někdy přidávají funkčnost do wrapper funkcí u daného systémového volání. A to je potřeba také dokumentovat ve stránce v sekci 2. Ale dodal: Každopádně myslím, že pevnější provázání zdrojových kódů jádra a sekcí 2 a 4 v manuálových stránkách není špatný nápad. V ideálním světě by současně se změnou v jádře patch obsahoval i úpravy manuálových stránek (pokud by byly nutné) - pak by změny patch následovaly přes -mm až do Linusova stromu.

Problémy se zátěží z gitweb.cgi na kernel.org, 15 e-mailů

17. říj - 19. říj

V konferenci o git řekl H. Peter Anvin Kay Sieversovi:

Je čím dál více zřejmé, že gitweb.cgi způsobuje pro kernel.org servery nepřijatelnou zátěž. Většina požadavků je buď na hlavní stranu gitweb nebo gitweb RSS kanály. A žere to pásmo jako blázen.

Během současného výpadku jednoho ze serverů je to zvláště nepříjemné.

Kayi, gitweb opravdu musí zvládat kešování nebo běžet za kešovací proxy. Jinak to budu muset vypnout, dokud neseženeme samostatný hardware.

Kay navrhl Apache mod_cache a Peter odpověděl: Nastavil jsem mod_cache (o kterém jsem nevěděl, já trubka) a zatím to funguje. Zátěž prudce poklesla a reakční doba je daleko lepší. Přesto mám ještě prosbu. Některé gitweb stránky se mění častěji než ostatní. Konkrétně existují stránky, které se nemění nikdy (protože přímo zobrazují neměnná git data). Kdyby gitweb dokázal přiřazovat na odpovídající stránky hlavičky Last-Modified (poslední změna) a Expires (vyprší), mělo by to zlepšit výkon keše. Kay to zařídil a Brian Gerst doplnil: Také by pomohlo vložit git ikonu a styly do samostatných statických souborů.

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