Jaderné noviny 248

2. 2. 2004 | Robert Krátký | Jaderné noviny | 4084×

Dohledávání informací k údajně zkopírovaným souborům. Vyvažování zátěží procesů a řešení priorit. Patche pro třídu SysFS, které usnadní podporu ovladačů. Navýšení PAGE_SIZE pro 2.7. Pravidla posílání patchů. Potíže s udev a odebratelnými médii.

Do konference přišlo celkem 1221 emailů, nejvíce jich poslali Greg KH, Geert Uytterhoeven a Linus Torvalds.

Dohledávání informací k údajně zkopírovaným souborům, 54 e-mailů

22. pro - 2. led

Stan Bubrouski poslal seznam souborů, o kterých SCO tvrdí, že byly do Linuxu nelegálně zkopírovány. Kromě jiných to byl i 'include/asm-i386/errno.h'. Tom Felker na to řekl: Původní errno.h z linux-0.01 obsahuje informaci, že byl převzat z Minixu - a je stejný až po 40. Mezi linux-0.96c a linux-0.97 byl ten soubor nahrazen současnou verzí, která má chybové řetězce a je stejná až do 121. Kde se tedy vzala ta verze 97?

Erik Andersen odpověděl: V případě errno.h jsem - jak vyplývá z tohoto - Linuse přiměl, aby do kernelu 2.0.32 přidal ENOMEDIUM a EMEDIUMTYPE, což bylo součástí mé práce na (budoucím) cdrom ovladači založeném na původní práci Davida van Leeuwena (archiv). Pak jsem prosadil tyto definice do glibc a libc5. Takže minimálně tyto dvě definice nepocházejí od SCO... Poblíž přidal Linus Torvalds:

errno.h obsahuje _velký_ komentář o tom, odkud se ta čísla vzala (a několik nadávek na POSIX ;).

Jak se tak dívám na signal.h, tak ta čísla se také zdají být stejná jako v Minixu - což dává smysl, protože jsem k nim měl přístup.

V obou případech však jde pouze o ta čísla. A ani ne všechna - z nějakého důvodu jsem signální čísla ponechal shodná (asi lenost - ani mi tolik nezáleželo na těch samotných číslech jako na seznamu názvů signálů), ale například SA_xxxx makra - v tom samém souboru - se těm minixovým vůbec nepodobají.

J.W. Schultz řekl: A kvůli těm názvům by možná mohli zažalovat Open Group: signal.h.html. A to se asi týká všech těch hlavičkových souborů.

Vyvažování zátěží procesů a řešení priorit, 31 e-mailů

22. pro - 2. led

Con Kolivas napsal:

Aktualizoval jsem své dávkové plánování [batch scheduling], které si rozumí i s hyper-threadingem.

Co je to dávkové plánování? Označení úlohy jako dávky umožňuje využít čas procesoru pouze je-li nějaký k dispozici, místo aby měla přidělený čas podle hodnoty nice.

Proč potřebuji dávkové plánování, které si rozumí s hyper-threadingem?

Máte-li hyper-threadingový procesor (P4HT) a používáte-li ho jako dva logické procesory, mohou se vyskytnout nízkoprioritní úlohy, které budou při běhu spotřebovávat 50 % fyzické kapacity procesoru bez ohledu na to, jak vysokou prioritu mají jiné běžící procesy. Například pokud používáte klienta pro distribuovaný výpočet SETI@home, bude běžet s polovinou rychlosti vašeho CPU, ačkoliv bude nastaven na nice 20. Dávkové plánování u normálních procesorů zajišťuje využití volného času pouze pro dávkové úlohy, ale u HT CPU povolí využít volný čas pouze pokud jsou oba logické procesory nečinné.

Nechci to protlačit do hlavního kernelu, ale problém nízkoprioritních úloh, které zpomalují HT procesory, musí být vzat v úvahu má-li být kdy začleněn HT plánovač. Tento patch představuje dočasné řešení pro lidi s HT procesory a zároveň ukazuje způsob, jak s nimi nakládat v hlavním vývojovém kernelu.

Patch najdete zde:
http://ck.kolivas.org/patches/2.6/2.6.0/

Patche pro třídu SysFS, které usnadní podporu ovladačů, 13 e-mailů

23. pro - 29. pro

Greg KH napsal:

Posílám patche pro sysfs třídu - předělané pro čistý 2.6.0 strom. Vytvořil jsem prostý soubor class_simple.c, který obsahuje "jednoduchou" třídu rozhraní zařízení. Pak jsem konvertoval tty jádro, aby toto rozhraní využívalo (dohromady tyto dva patche nepředstavují žádný přidaný kód).

Pak jsou tu tři patche přidávající podporu pro zařízení třídy misc, mem a vc. Protože rozhraní pro přidání podpory jednoduché třídy pro zařízení je teď dost hluboko, mám pocit, že potřebujeme podporu mem třídy. Tak bychom ze žádného znakového zařízení neudělali zvláštní případ.

S těmito patchi je teď pro ostatní mnohem jednodušší implementovat podporu pro zbývající znakové ovladače/subsystémy.

Jeff Garzik poznamenal: Zajímavé... Vsadím se, že to bude užitečné pro lidi kolem iPAQ (nedávno jsem se probíral jejich patchi), protože vytvořili pár ultra-jednoduchých tříd pro SoC zařízení a jim podobná. Greg KH odpověděl: To si piš, že jo. Portoval jsem svůj starý patch pro framebuffer, aby to používal, a ušetřilo to hodně kódu.

Navýšení PAGE_SIZE pro 2.7, 28 e-mailů

26. pro - 29. pro

Během diskuze navrhl Eric W. Biederman navýšení PAGE_SIZE v kernelu. Linus Torvalds odpověděl:

Ano. Tohle bych vlastně chtěl tak jako tak udělat v 2.7.x. Dan Phillips k tomu měl nějaké patche před šesti měsíci.

Je potřeba být opatrný, protože pak bude muset být možné mmapovat "částečné stránky", což to znesnadňuje. Ale existuje spousta důvodů, proč to chtít, a barvení keše je vlastně spíš až druhotný problém.

William Lee Irwin III řekl: Kód Dana Phillipse jsem neviděl. Věnuji se této věci od minulého prosince. Mike Fedyk odpověděl: Vzpomínám si na jeho práci na sdílení stránkových tabulek, ale neslyšel jsem od něj nic o změně PAGE_SIZE. Nemohlo by to být to, na co si Linus vzpomíná? William řekl: Pochybuji. Myslím, že mluví o pgcl (někdy nazýváno "substránky"), ačkoliv na tom se Dan Phillips nepodílel. Asi budeme muset počkat, až se k tomu Linus vyjádří, abychom si byli jisti. A Linus napsal:

Samotný patch jsem neviděl, ale chvíli jsem s Danielem mluvil po tvé řeči na Jaderném summitu. Aspoň si myslím, že to byl on - moje paměť na jména a tváře je mizivá.

Daniel tehdy tvrdil, že mu to funguje a že to skutečně zmenšilo velikost kódu jádra. Základní přístup je prostě zvětšit PAGE_SIZE a o dočasné potřeby menších substránek se starat pomocí dynamického alokování "struct page" záznamů. Snížení velikosti bylo dosaženo zbavením se "struct buffer_head", protože z toho se stane jen další "malá stránka".

Zeptal se Daniela Phillipse na podrobnosti a Daniel řekl:

Popsal jsi to přesně.

A pokračoval dalšími technickými detaily.

Ale William chtěl vědět: Na Jaderném summitu jsi mě podpořil a teď už na tom rok dřu, abych to udržel aktuální. Mohl bys mi říct, co se to sakra děje? Počítám, že už je jasné, že jsem v háji, ale rád bych to měl oficiálně potvrzené. Linus odpověděl:

Ještě jsem se na žádné patche pro 2.7.x ani nepodíval - a několik dalších měsíců se taky nepodívám.

Je mi jedno, co to zařídí, ale chci větší PAGE_CACHE_SIZE a fungující patche jsou jedinou věcí, na které záleží. Ale prozatím mám na očích 2.6.x klapky.

William se stále cítil mizerně, ačkoliv předpokládal, že nějaká naděje tu ještě je. Linus napsal:

No, já ani nevím, jak k tomu ty přistupuješ - řekneš něco bližšího?

Mým původním plánem bylo (a je to částečně poznat ze skutečnosti, že PAGE_CACHE_SIZE je oddělené od PAGE_SIZE) umožnit stránkové keši využívat větší než "normální" stránky, přičemž normální stránky by i nadále měly velikost hardwarové stránky.

Jenže zvlášť když s mem_map[] je teď trochu problém a také kvůli všem potížím, které bychom měli, kdyby byly PAGE_SIZE a PAGE_CACHE_SIZE rozdílné, tak to vypadá, že se spokojím prostě se zvětšením PAGE_SIZE (a zároveň PAGE_CACHE_SIZE) a VM jenom naučíme mapovat "částečné stránky".

Jak to děláš ty?

William odpověděl:

Přednášel jsem o tom na Jaderném summitu. Je to vlastně stejné jako přístup Hugha Dickinse z roku 2000. Jediným rozdílem je to, že bylo potřeba všechno portovat (nebo v mnoha případech napsat úplně znova), aby to sedělo se současným kódem a funkcemi.

V podstatě se pouze zvýší PAGE_SIZE, zavede MMUPAGE_SIZE, což je makro, které představuje hardwarovou velikost stránky, a zajistí se řešení chyb. Společně s mnoha PAGE_SIZE/MMUPAGE_SIZE kousky je potřeba pár hlubších změn, protože je nutných hodně distribuovaných změn, které se vypořádávají s potížemi způsobenými jinou PAGE_SIZE než 4KB.

Vzhledem k tomu, že pouhé navýšení PAGE_SIZE způsobí nefunčnost mnoha věcí, jsem trochu podezřívavý, když se tvrdí, že všechno mohou zařídit minimalistické patche.

Mike Fedyk se zeptal, jestli by ten velký patch nešlo nějak rozdělit na menší a postupně začlenit do -mm stromu Andrew Mortona. William odpověděl:

Před nějakou dobou jsem o tom už mluvil. V celém patchi, i když je tak velký, je v podstatě jediný koncept.

Bylo mi řečeno, abych to celé udržoval mimo strom. Když jsem poslal na ukázku jak by vypadala rozdělená verze některých naprosto triviálních změn v arch/i386, Linus ani Andrew mi neodpověděli. Ty netriviální změny jsou vlastně úplně pitomé, ale dotýkají se kódu, který je "chatrný" nebo na se na něj z jiného důvodu všichni bojí sáhnout - a to je prostě odsouvá až na 2.7.

Pravidla posílání patchů, 13 e-mailů

29. pro - 1. led

Muli Ben-Yehuda poslal patch a Linus Torvalds na to řekl:

Když děláš něco podobného, mohl bys patch rozdělit na dva samostatné? Jeden bude dělat pouze opravné formátovací věci, které zaručeně nic jiného nezmění, a ten druhý provede zbytek.

Když jsou změny promíchány s formátovacími opravami, je opravdu otrava zjišťovat, které změny způsobily nějaký rozdíl.

Muli odpověděl: Máš úplnou pravdu. Ten patch se skládá ze 30 různých patchů. Nerozdělil jsem ho na dva proto, že změny, které provádí, jsou propojené a na sobě závislé, takže by bylo opravdu otrava to separovat. Jeff Garzik řekl: Třicet různých patchů nevadí. Máme skripty, které se vypořádají se záplavami patchů. A Linus připojil:

Ano i ne.

Třicet samostatných patchů dává smysl pokud skutečně provádějí koncepčně různé věci. Pak má smysl je začleňovat zvlášť, takže můžeme lidem říct "ok, když odstraníš tento, mohlo by to problém vyřešit".

Pokud však jsou všechny typu "oprav hloupou chybu v xxx", pak bych to raději viděl jako jeden velký patch. Rozdělovat to na "oprav chybu na řádku 50" a "oprav chybu na řádku 75" nemá smysl - jen to ztěžuje sledování změn.

Takže "hodně malých patchů" není automaticky lepší než jeden velký. Záleží na tom, aby byly věci koncepčně odděleny. Opravuje-li jeden patch formátování a druhý chybu, pak je to fajn.

Potíže s udev a odebratelnými médii, 8 e-mailů

1. led - 3. led

Andrey Borzenkov ohlásil:

udev vytváří názvy, když kernel rozpozná zařízení. Bohužel u odebratelných médií kernel kontroluje oddíly pouze, když se na zařízení pokusím přistoupit. Takže kernel nepošle hotplug událost a udev nevytvoří soubor zařízení. Jenže bez souboru zařízení nemohu v Unixu k zařízení přistupovat :(.

Konkrétně na mém Jaz nemohu (rozumně) přistoupit k oddílu 4 - za předpokladu, že o soubory zařízení se stará udev.

devfs tento problém řešilo takto:

• vždy exportuje alespoň základní soubor pro celý disk (například sda)
• při hledání neexistujících oddílů (/dev/sda4) používá něco jako dd if=/dev/sda count=1, což znovu prohlédne oddíly a vytvoří pro ně soubory zařízení..

Statické /dev všechny soubory zařízení prostě má, takže tímto problémem vůbec netrpí.

Bohužel udev žádný podobný mechanismus nemá. Což znamená, že uživatel musí po vložení média ručně proskenovat všechny oddíly. Při současné implementaci z toho nevidím žádné východisko. Nejblíže by mohlo být naslepo vytvořit soubory zařízení pro všechny oddíly, jakmile bude blokové zařízení dostupné.

Greg KH řekl: Kernel přeci vždy vytvoří základní blokové zařízení, ne? Pokud ano, udev to odchytí. Pokud ne, udev s takovým zařízením nikdy fungovat nebude. Sorry. Mohl bys napsat skript, který soubor zařízení vytvoří v /tmp, pustí na to dd a pak to všechno smaže, což by vynutilo proskenování oddílů. Andrey souhlasil, že kernel vytváří hlavní blokové zařízení /dev/sda, ale nechápal, jak by mu to mohlo pomoci, když potřebuje právě /dev/sda4. Mohl by napsat skript, který provede to, co navrhoval Greg, ale stejně neexistuje způsob, jak jej spustit v tu správnou chvíli. Při vložení Jaz disku žádná událost odeslána není. Ale Greg připomněl, že udev to řešit umí. Viz pravidlo CALLOUT. Může spustit jakýkoliv program nebo skript zpozoruje-li kernel nové zařízení.

---

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

• udev 011 Released
• Adaptec/DPT I2O Gone In 2.6; Replacement Sought
• Some RAID Recommendations
• Status Of ATARAID In 2.6
• Problems With Accusys Drives
• Status Of 2.6 Maintainership
• BitKeeper Usage Policy And Advice
• Status Of BitKeeper Snapshots For 2.6
• USB Updates For 2.6
• Experimental Net Driver Updates For 2.6
• SCSI Updates
• Prototype For BitKeeper 'Undo Changeset' Improvement
• Status Of kernel.bkbits.net
• Linux 2.6.1-rc1 Released; Unanswered Questions About 2.6 Release Policy
• Linux 2.4.24-pre3 Released
• udev 012 Released
• Fair Scheduling In 2.4

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licencí GPL verze 2.

       

Komentáře