Jaderné noviny 231

25. 9. 2003 | Robert Krátký | Jaderné noviny | 4046×

Status ReiserFS 4. Diskuze o binárních modulech. Nový démon pro podporu zapojení síťového kabelu za provozu. Zpětné opravy záznamů v changelogu BK. Větvení kódu softwarového uspání v 2.6-test.

Do konference přišlo celkem 2456 emailů, nejvíce jich poslali Andrew Morton, Alan Cox, Mike Fedyk.

Status ReiserFS 4, 35 e-mailů

Oleg Drokin oznámil:

Právě jsem vydal další snímek reiser4. Doufám, že ho vyzkouší všichni, kteří mají zájem. Vydání je ke kernelu 2.6.0-test4. Najdete jej zde /snapshots/2003.08.26. Přikládám poznámky k verzi.

Reiser4 snímek z 26. 8. 2003.

VAROVÁNÍ!!! Tento kód je experimentální! NEDĚLÁME SI SRANDU! NA REISER4 ZATÍM NEDÁVEJTE ŽÁDNÁ CENNÁ DATA!

Opraveno pár chyb. A reiser4 by konečně měl jít zkompilovat na 64 bitových strojích (hmm, někdo to vyzkoušejte, protože se mi nedaří zkompilovat žádný kernel pro ia64). Reiser4 by teď měl jít zkompilovat bez zapnutého debugování. Byla opravena důležití SMP chyba (postihovala pouze SMP kernely na strojích s méně než 3 procesory). Pořád pracujeme na problémech s OOM, ale jinak doufám, že problémy s kompilací, které někteří lidé hlásili, už jsou opraveny. Připojení pouze pro čtení (a tedy reiser4 jako rootfs) také není podporováno.

Aktualizace reiser4progs obsahuje pár 64 bitových oprav a další věci. fsck stále nefunguje, takže to ani nezkoušejte spouštět.

O několik zpráv dále napsal Felipe Alfaro Solana, že narazil na problém při kompilaci ReiserFS jako modulu místo zakompilování do binárky kernelu. A Oleg odpověděl: Kompilace jako modul zatím také není podporována. Steven Cole poslal patch, který upozorňuje na tento stav, ale Hans Reiser řekl, že pokud nebude fungovat, tak by bylo lepší tu funkci úplně zakázat a ne jen na ni upozornit.

Diskuze o binárních modulech, 6 e-mailů

Joe Briggs se zeptal: Mám klienta, jehož RAID řadič je podporovaný ve Windows a teď by chtěli podporovat Linux jako bootovatelné zařízení. Některá jejich obchodní tajemství jsou misto ve firmware řadiče obsažena v ovladači. Takže prozatím chtějí určitým beta zákazníkům dát k dispozici pouze binární verzi ovladače. Tj. 1. stupněm portování je funkčnost srovnatelná s Windows. Je to tak, že aby bylo z toho zařízení možné bootovat, musel by být ovladač staticky nalinkován do jádra, kdežto modul by mohl být distribuován v binární podobě k jednotlivým revizím distribučních kernelů?

Stephen Hemminger odpověděl: Ovladač by mohl být jako modul zaveden v initramfs. Když se ti povede natáhnout základní image Linuxu a initramfs, mělo by to jít. Problém by byl spíš v booloaderu (LILO nebo GRUB), protože by si neuměl poradit s RAID. /boot oblast by musela být na oddílu mimo RAID. Stejný problém by byl i kdyby byl driver staticky nalinkován do kernelu.

Alan Cox poznamenal: Podle mě to není ani tak kvůli obchodnímu tajemství, ale kvůli "zvyšování obtížnosti změny prodejce" 8). Skoro všechny starší PATA řadiče nedělají hardwarový RAID, ale BIOS/ovladač RAID - tj. je to (zhruba) ekvivalent MD vrstvy, ale musíš zůstat u stejného dodavatele. Čestnou výjimkou je 3ware karta (a pár dalších - Promise Supertrak100, SX6000).

A Joe odpověděl: Myslím si, že firmám nakonec dojde, že otevřít kód svých ovladačů je levnější a přínáší více. To je ale závěr a přístup, ke kterému se budou muset dobrat samy - když se jim to bude vnucovat, bude to trvat déle. Prvním krokem je jejich hardware na platformě (Linux) podporovat a o to se snažím.

Nový démon pro podporu zapojení síťového kabelu za provozu, 13 e-mailů

Bryan O'Sullivan oznámil:

Netplug je démon, který reaguje na zapojení nebo odpojení síťového kabelu zapnutím nebo vypnutím síťového rozhraní. To se obzvlášť hodí u systémů spravovaných pomocí DHCP, které jsou často přemísťovány. Například laptopy a systémy v klustrových prostředích.

Více podrobností a pokyny pro download naleznete na homepage netplugu: http://www.red-bean.com/~bos/

Aaron Lehmann vděčně odpověděl: Díky, díky, díky. Zrovna jsem dnes myslel na to, jak je otravné, že po každém nastartování mého laptopu se dhclient spustí a snaží se získat IP adresu na ethernetovém zařízení, dokud ho nesestřelím. Vzhledem k tomu, že ethernetové rozhraní používám často, není to špatné výchozí nastavení, ale dhclient si ani sám nedokáže uvědomit, že není připojen žádný kabel.

Ale na jiném místě se J.A. Magallon zeptal, jestli Bryan věděl o projektu ifplugd, který jak se zdá dělá tu samou věc.

Jeff Garzik odpověděl: Vypadá to, že ifplugd nepoužívá netlink. Něco mi uniká? netlink je určitě upřednostňovaným způsobem, jak získat informaci o spojení. Možná by oba autoři mohli pracovat spolu a vzít to nejlepší z obou projektů...

J. A. odpověděl: To by bylo fajn, ale pořád je tu problém. Řeší netlink nějak skutečnost, že existují karty (alespoň v 2.4), které nepodporují žádnou detekční metodu?

A Bryan řekl: netlink vůbec ioctl rozhraní nepoužívá. Je-li karta schopná přes netlink rozhraní ohlásit IFF_UP nebo IFF_RUNNING, bude netplug fungovat.

Stefan Rompf dodal, že ani v 2.6 nepodporují všechny karty stav spojení přes netlink, je potřeba aktualizovat ovladač. Správci by si to měli uvědomit a přidat volání netif_carrier_on()/_off() nebo mii_check_link()/mii_check_media() . 2.4 to neuškodí, protože ty funkce tam už jsou, ale v základním kernelu nevytvářejí zprávy.

Zpětné opravy záznamů v changelogu BK, 18 e-mailů

Albert Cahalan si všiml, že do BitKeeperu se dostal špatný záznam v changelogu. Zeptal se, jestli je možné to opravit.

Larry McVoy odpověděl: Jestli chceš změnit komentář, můžu to provést na bkbits.net a každý, kdo si odtud provede aktualizaci, už dostane nové komentáře. Jestli chceš patch z BK odstranit, tak to může udělat každý pomocí cset -x.

Albert řekl, že kód sám o sobě je v pořádku a je potřeba pouze upravit komentář. Napsal: Bude mi stačit cokoliv co zařídí, že když se někdo bude dívat na logy BitKeeperu, tak neusoudí, že jsem něco pokazil.

Larry řekl: Zařazovací komentáře bohužel nejsou řízeny revizemi. Je třeba spustit příkaz pro každý repozitář, který chceš opravit. Když mi pošleš ty požadované komentáře, zadám ten příkaz. Potom, schválí-li to Linus nebo Marcelo, provedu to na bkbits.net. To by mělo stačit. Lidi většinou prohlížejí logy tam.

Albert poslal komentář, který chtěl, aby nahradil ten původní, ale Christoph Hellwig byl proti celému nápadu retroaktivně upravovat záznamy v changelogu. Zdálo se mu to jako cenzura a Larry odpověděl: O tom já nerozhoduji. Řekl jsem "schválí-li to Linus nebo Marcelo" právě kvůli případným tahanicím. Na druhou stranu je možné, že se tam prostě dostal špatný komentář a je-li tomu tak, proč jej neopravit?

Geert Uytterhoeven varoval: Retroaktivní změna zapsané zprávy může vytvořit nebezpečný precedens. Ačkoliv mohou existovat legitimní důvody (např. jasně špatný komentář nebo "ve skutečnosti tohle napsal x a ne y"), Říše zla by pak mohla tvrdit, že jsme pozměnili důkaz o tom, co kdo dělal. Revizní řízení komentářů je další možností, ale možná trochu moc složité...

Někdy v tuto chvíli poznamenal Linus Torvalds:

Ve skutečnosti to dělám pořád. Kromě toho, byl jsem to já, kdo Larryho požádal, aby přidal příkaz "bk comment", aby to bylo snadné.

Problém je, že je to těžké provést po té, co byl text vypuštěn na veřejnost - ale emailové komentáře lidem ručně opravuji jak v emailech, tak později, když už jsou v mém BK stromu. Snažím se opravit jasné překlepy a všeobecně zajistit lepší čitelnost.

A je-li komentář špatný, pak by měl být opraven. Ne kvůli nějaké "cenzuře", ale proto, že je matoucí, tvrdí-li komentář, že něco opravuje, ačkoliv to není pravda. Což může způsobit, že lidi přehlédnou tu _skutečnou_ věc, kterou dělá.

Jakob Oestergaard namítal (a Geert souhlasil), že to maří revizní řízení archívu, protože to umožňuje, aby changelogy jednu chvíli říkaly něco a druhou chvíli něco jiného, aniž by bylo zřejmé, že existovala předchozí verze.

Větvení kódu softwarového uspání v 2.6-test, 13 e-mailů

V rámci několika vláken Pavel Machek řádně vynadal Patricku Mochelovi za několik změn v softwarovém uspání (a jinde), které Pavlovi (správce softwarového uspání) proklouzly a způsobily nefunkčnost několika věcí v oficiálním 2.6-test stromu. Pavel poslal patch, který odstranil všechnu Patrickovu práci a Patrick odpověděl: Chápu, že máš vztek, protože jsem upravil a nechtěně pokazil kód, kterého jsi správcem. Ale ani jednomu z nás neposlouží, když na oplátku úmyslně pokazíš můj kód. Zvlášť když vezmu v úvahu, že jsem už mezitím chyby ve svém kódu opravil.

O pár zpráv dále napsal:

Ne, pochop, že software_suspend() nechci volat vůbec. Ty jsi rozhodl, že swsusp změny nebudou přijaty, takže oddělíme kód. Budeme mít v kernelu soupeřící implementace uspání na disk.

Můžeš si ponechat rozhraní, která jsi měl pro to, aby ses dostal k software_suspend(), ale nesmíš upravovat sémantiku mého kódu, který to volá. Možná se někdy rozhodneš přidat odkazy na swsusp, které dodržují volací sémantiku PM jádra, takže budeš moct používat stejnou infrastrukturu.

Pošli prosím patch, který odstraňuje pouze volání swsusp_* z pm_{suspend,resume}. To bude minimální patch.

Briana Litzingera překvapilo tak závažné větvení kódu tak krátce před novou stabilní řadou.

Na jiném místě řekl Pavel Patrickovi: Řekl jsem, že chci patch vrátit. Stále na tom trvám, protože jsi měnil příliš rychle bez pořádného testování. To neznamená, že v budoucnu tvoje patche nepřijmu. (Ostatně, mám v plánu dát do -test5 verzi swsusp z -test3, pak opravit modelové/swsusp ovladače dokud nebude funkčnost stejná jako v -test3 a pak začít brát tvoje patche.) Samozřejmě to bude snazší, budeš-li se mnou spolupracovat.

Patrick odpověděl:

To je v pořádku. Dělej si co chceš, svým vlastním tempem, se svým kódem.

Mám však pocit, že nerozumíš mým slovům o tom, že s tebou nebudu pracovat. Nebudu čekat až zařadíš moje patche a nenechám se dál urážet. Mám lepší věci na práci a ne tolik času.

Doporučuji buď a) akceptovat moje změny a opravy a pomoct se začleněním Nigelových změn v 2.4 do základu, nebo b) přijmout oddělení, začlenit Nigelovy změny a později se pokusit spojit ty dva základy.

Nigel Cunningham napsal, Okej. Vzhledem k tomu, že jste oba poskytli 'uklidňující' odpovědi, přestanu si dělat starosti, pohnu s dokončením 2.4 verze 1.1 a pak aktualizuji a oživím port. Pořád si ale nejsem jistý, oproti komu připravovat patche nebo komu je posílat. Do té doby, než budu připraven vydat 1.1 pro 2.4 si to doufám vyřešíte. A vlákno skončilo.

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

       

Komentáře

[David Olszyński]

Ma jeste nekdo krome me pocit, ze tyhle clanky o vyvoji kernelu se zacina stale vic a vic podobat serialu Tak jde cas?

[Robert Krátký]

Mohl by mi nekdo ten serial strucne priblizit? Nebo alespon rict, jestli je to prirovnani lichotive nebo hanlive...

[8-]]

lol

[Ondřej Čečák]

doufam ze lichotive :o) alespon me se jaderne noviny libi a urcite nejsem sam, i kdyz muj nazor na Tak jde cas je ... :-X, melo to nejspise znamenat, ze dilu bude hafo, ale wo wo wo tom to je.

[kaaja]

Muj nazor na Tak jde cas: Priserny serial, co ja vim, tak minimalne 1500 dilu. Uplne o nicem, kdyz nahodou par dilu neuvidite, v podstate se nic nedeje (v serialu se nic noveho nestalo). Ne, ze bych ho snad nekdy trochu vic sledoval, to bych asi radsi zemrel. Nektere rysy jsou docela podobne Muj nazor na jaderne noviny: supr.

[Vladimir Kotala]

"Muj nazor na jaderne noviny: supr." Ale kdyz par dilu vynechas, stejne se nic nedeje

[Michal Kucera]

Muze to pripominat spoustu veci, ale je skvele, ze si mohu alespon v takoveto zkracene verzi precist, co je noveho v jadru Linuxu i na cem se zrovna dela. Proste je prijemne si neco precist i o pozadi vyvoje jadra. SKVELY!