Jaderné noviny - 7. 5. 2008

26. 6. 2008 | Jirka Bourek | Jaderné noviny | 2787×

Aktuální verze jádra: 2.6.26-rc1. Citáty týdne: Andrew Morton, Rusty Russel, Willy Tarreau. Poslední záležitosti, které prošly začleňovacím oknem 2.6.26. Je na čase zpomalit vývoj jádra? Vázané připojení pouze ke čtení.

Obsah

• Aktuální verze jádra: 2.6.26-rc1
• Citáty týdne: Andrew Morton, Rusty Russel, Willy Tarreau
• Poslední záležitosti, které prošly začleňovacím oknem 2.6.26
• Je na čase zpomalit vývoj jádra?
• Vázané připojení pouze ke čtení

Aktuální verze jádra: 2.6.26-rc1

Současná předverze jádra 2.6 je 2.6.26-rc1 vydaná 3. května. Tak tohle začleňovací okno bylo poněkud drsné ve smyslu, že se o něm vedlo hodně hádek, ale já osobně si zároveň myslím, že z technického úhlu pohledu bylo v poslední době pravidlem, že se děly méně děsivé věci. Při přibližně 7500 commitech obsahuje tento cyklus méně změn, než mělo těch pár předtím; spousta změn je v infrastruktuře, takže viditelných nových vlastností bude v 2.6.26 méně než v jeho předchůdcích. Detaily vizte ve zkráceném changelogu, spoustu detailů v kompletním changelogu.

Do hlavního repozitáře po vydání -rc1 proudil relativně pomalý proud patchů.

Současná verze stabilního jádra je 2.6.25.2 vydaná 6. května. Toto vydání obsahuje jedinou opravu pro lokálně zneužitelný bezpečnostní problém v kódu zámků souborového systému. Tato oprava byla vydána také v 2.6.24.7 a 2.4.36.4.

Větší skupina oprav byla vydána v 2.6.25.1 a 2.6.24.6. Pokud se neobjeví nějaké bezpečnostní záležitosti, pravděpodobně nebudou žádné další aktualizace stabilního 2.6.24.

Citáty týdne: Andrew Morton, Rusty Russel, Willy Tarreau

Obvykle vězí základ mých problémů s gitem v tom, že nemám PhD v hermeneutické metafyziologii, ale tentokrát ne. Si myslím.

-- Andrew Morton

Děti: nestrkejte do svého jádra náhodné jaderné moduly. Jenom protože něco dělá Linus, to ještě nemusí být dobrý nápad...

Polovinu jaderné inteligence jsme přesunuli do uživatelského prostoru v udev, initrd a modulech; je skutečně nefér, že s námi nesdílíte ten skvělý proč-můj-stroj-nebootuje pocit.

-- Rusty Russel

Jaderný tým se vyvinul z malého týmu kámošů do velkého podniku. A abychom přežili tuto evoluci, možná budeme muset použít některé z těch nemorálních principů, které jsou k vidění u velkých firem.

-- Willy Tarreau

Poslední záležitosti, které prošly začleňovacím oknem 2.6.26

Po zveřejnění prvního a druhého shrnutí začleňovacího okna 2.6.26 bylo začleněno okolo 500 sad změn. Začleňovací okno bylo uzavřeno; zde je poslední sada změn, které se dostaly dovnitř:

• Nové ovladače pro

  • ethernetové řadiče založené na řadiči Solarflare Communications Solarstorm SFC4000,
  • karty s TV tunerem Hauppauge HVR-1600,
  • USB hostitelské řadiče ISP 1760,
  • OTG řadiče Cypress c67x00 a
  • USB řadiče Intel PXA 27x.

• Na architektuře x86 jsou opět výchozí 8kB zásobníky. Situace, kdy dojde paměť, jsou méně problematické, než tiché a těžce laditelné poškození zásobníku.

• Typ klist (kseznam) má nyní pro deklaraci a inicializaci makra v obvyklé formě: DEFINE_KLIST() a KLIST_INIT. Dvě nové funkce (klist_add_after() a klist_add_before()) mohou do klistu přidávat záznamy na specifikovanou pozici.

• struct class_device byla podle plánu odstraněna z jádra ovladačů společně s ní spojenou infrastrukturou. Třídy jsou nyní implementovány pomocí běžné struct device.

• kmap_atomic_to_page() již není exportována modulům.

• Jsou k dispozici nové obecné funkce pro provádění 64bitového celočíselného dělení v jádře:

  u64 div_u64(u64 dividend, u32 divisor);
  u64 div_u64_rem(u64 dividend, u32 divisor, u32 *remainder);
  s64 div_s64(s64 dividend, s32 divisor)
  s64 div_s64_rem(s64 dividend, s32 divisor, s32 *remainder);

  Narozdíl od do_div() je u těchto funkcí explicitně udáno, jestli se jedná o znaménkovou nebo bezznaménkovou matematiku. Pro x86 specifická funkce div_long_long_rem() byla odstraněna ve prospěch těchto nových funkcí.

• Je zde nová řetězcová funkce:

  bool sysfs_streq(const char *s1, const char *s2);

  Porovnává dva řetězce a ignoruje přitom volitelný znak konce řádky.

• Prototyp pro i2c metody probe() se změnil:

  int (*probe)(struct i2c_client *client,
               const struct i2c_device_id *id);

  Nový argument id podporuje aliasing jmen i2c zařízení.

• Byla zavedena nová konfigurační volba (MODULE_FORCE_LOAD), která určuje, jestli je možné násilím nahrát modul, i když si jádro myslí, že to není správně; výchozí hodnota je "ne."

Je na čase zpomalit vývoj jádra?

Všechny komunity si postupem času vybudují rituály. Jedním z přetrvávajících rituálů na linux-kernel je pravidelná vášnivá diskuze na téma vývojový proces a kvalita jádra. Pro vnějšího pozorovatele tyto události mohou budit dojem, že celý ten podnik se musí rozpadnout. Nicméně skutečnost je dost podobná oslavě nového roku, u níž měl autor článku příležitost být v Pekingu: spousta hluku a kouře, ale druhý den se všichni vrátí do práce.

Nicméně i v diskuzích tohoto typu se skrývá nějaká skutečná hodnota. Jakákoliv skupina, která se zabývá věcmi, jako je kvalita, musí občas udělat krok zpět a vyhodnotit situaci. I když z toho nejsou žádné okamžité výsledky, nápady, které se objeví, se často vrací během několika následujících měsíců a vedou ke skutečnému zlepšení.

Inspirací pro toto kolo diskuze byly nefungující systémy jako výsledek začleňovacího okna 2.6.26. Tento vývojový cyklus měl drsnější start než jiné, větší než obvyklé množství patchů způsobilo selhání při bootu a další nevhodné chování. To vedlo mezi vývojáři k nějakým tahanicím o to, jak by mělo být nakládáno s patchi. Vadné patche jsou nepříjemné, ale stojí za to poznamenat jednu věc: tyto problémy byly podchyceny a opraveny ještě předtím, než bylo vydáno 2.6.26-rc1. Problémy, které nastartovaly tohle kolo diskuze, nejsou chyby, které by postihly uživatele Linuxu.

Nadevší pochybnost ale budou jiné chyby, které se vynoří pomaleji a budou pomaleji opraveny. Počet těchto chyb vedl k mnoha voláním po tom, aby byl vývojový proces nějakým způsobem zpomalen. V tomto ohledu se hodí si všimnout, že proces se zpomalil, začleňovací okno 2.6.26 přineslo mnohem méně sad změn, než bylo k vidění v 2.6.24 či 2.6.25. Jestli bude toto pomalejší tempo pokračovat i v budoucích cyklech, nebo to byla prostě přestávka po dvou obzvláště rušných vývojových cyklech, to se ještě uvidí.

Jenže jestli se proces nezpomalí sám, jsou zde vývojáři, kteří by chtěli nalézt způsob, jak ho k tomu přinutit. Někteří argumentovali pro prosté přiškrcení [throttling] procesu tak, že by například omezili počet nových vlastností v každém vývojovém cyklu pro jednotlivé subsystémy jádra. Také kolovaly řeči o vybrání subsystémů s nejhorším počtem regresí a nezačleňování nových vlastností do doby, než se věci zlepší. Faktem ovšem je, že omezování situaci pravděpodobně nepomůže.

Zpomalení začleňování totiž vývojářům nezabrání vyvíjet, akorát to udrží jejich kód mimo strom. Extrémní příklad lze najít v jádře 2.4: začleňování nového kódu bylo dlouho značně omezováno, až nakonec došlo k tomu, že distributoři začali začleňovat nový vývoj sami, protože jejich uživatelé to požadovali. Takže spousta jader, které se jmenovaly "2.4", se podstatně lišila od čehokoliv, co se dalo stáhnout z kernel.org. Na této cestě čeká fragmentace a téměř s určitostí také nižší kvalita.

Linus ve skutečnosti tento argument vzal a použil ho k tvrzení, že rychlé začleňování patchů vede k lepší kvalitě:

Osobně věřím, že nejlepší způsob, jak zlepšit kvalitu kódu, je distribuovat ho. Ano - pro účely této diskuze - jako patche, ale ještě více jako část soudržného celku - jako začleněné patche!

Vtip je v tom, že na kvalitě jednotlivých patchů nezáleží! Záleží na kvalitě celkového výsledku. A lidé budou mnohem více zatahováni do toho, aby se dívali, testovali a pracovali s kódem, který je začleňován, než s kódem, který není.

Proti omezování argumentoval i Andrew Morton:

Jestliže věci jednoduše omezíme, lidé stráví víc času sledováním teleshoppingů, ale budou začleňovat menší množství úplně stejného svinstva.

Jaderní vývojáři jsou samozřejmě známí jako notoričtí nakupovači, takže dávat jim více příležitosti provozovat tuto aktivitu pravděpodobně není nejlepší nápad. No, ale vážně: Andrew je pro zpomalení vývojového procesu, ale jenom pokud se k tomu přistoupí z jiného úhlu - jeho názorem je, že zvýšené zaměření se na kvalitu bude mít jako vedlejší efekt zpomalení vývoje. Je potřeba, aby se jaderní vývojáři zaměřili na hledání a opravu chyb místo na vytváření nových a/nebo nakupování.

Je vhodné poznamenat, že významná část komunity vývojářů věří tomu, že v tomto ohledu nejsou žádné problémy. Chyby jsou nacházeny a opravovány rychlým tempem a pro většinu uživatelů je jádro solidní. Arjan van de Ven psal:

Opravdu se ohledně kvality zhoršujeme? Můj (subjektivní) dojem je, že jsme na tom lépe než minulý rok. Na kvalitu jsme zaměření více. Opravujeme chyby, které lidem vadí nejvíc. Opravujeme většinu regresí (uznávám, ne všechny). V subsystémech vidíme plochou nebo klesající křivku počtu/poměru chyb.

Ted Ts'o upozornil na to, že mnoho problémů pochází z obskurního a nekvalitního hardwaru a že není možné uspokojit každého. Andrew není přesvědčen a zdá se, že má obavy, že kvalita jádra upadá.

V jistém smyslu je tato část diskuze pouze akademická. Nikdo by se nehádal o tom, že méně chyb není dobrý cíl, bez ohledu na to, jestli věří, že současný vývojový proces má problémy s kvalitou. Debata o způsobech, jak věci vylepšit, je tedy vždy k tématu.

Testování je stále velký problém; jádro je mnohem citlivější na to, na jakém systému běží, než většina jiných projektů. Mnoho problémů (možná většina z nich) je spojená s nějakým specifickým hardwarem nebo specifickou kombinací hardwaru; není možné, aby vývojáři, kteří nemají všechen existující hardware, mohli najít všechny chyby. Uživatelé musí v tomto procesu pomoci. Dosažení široce rozšířeného pokrytí testováním je vždy těžké; Peter Anvin tvrdí, že současný proces to ještě ztížil:

Jeden problém je, že stále fragmentujeme základnu testerů přidáváním nových úrovní sebedůvěry: nyní máme -mm, -next, -git hlavní řady, -rc hlavní řady, vydání hlavní řady, stabilní, testovací u dister a vydání u dister (a některá distra mají ještě agresivní versus konzervativní větve). Navíc kvůli kraniorektálnímu vnoření na straně výrobců grafického hardwaru musí spousta uživatelů na svých "hlavních pracovních" systémech používat proprietární ovladače, což znamená, že nová vydání nemohou testovat, ani kdyby chtěli.

Ve skutečnosti je nepřeberné množství jader, která je možné testovat, a není vždy zcela jasné, kde by uživatelé a vývojáři měli koncentrovat své snahy. Nicméně se formuje konsenzus, že by se mělo víc lidí dívat konkrétně na strom linux-next. Linux-next je místo, kde by se měly shromáždit všechny patche zamýšlené pro další začleňovací okno; současný obsah linux-next je v době psaní tohoto článku zaměřen na 2.6.27. To je místo, kde mohou být nalezeny časné problémy s integrací a jiné; jestliže bude linux-next dobře otestován, počet problémů, které se objeví v dalším začleňovacím okně, by se měl o něco zmenšit.

Strom linux-next je zajímavý experiment. Prakticky prodlužuje vývojový cyklus: od té doby, co existuje linux-next, v podstatě začal vývojový cyklus 2.6.27. Linux-next také dělá něco, čemu jaderní vývojáři měli tendence odporovat: způsobuje, že stabilizační období jednoho vývojového cyklu se překrývá s aktivním vývojem dalšího cyklu. V minulosti se vedly dohady o tom, že toto překrytí povede vývojáře k tomu, aby se více zaměřili na vytváření nových hraček než na opravování problémů v hračkách z minulého týdne.

Někteří lidé tvrdí, že to se děje už teď: vývojáři netráví dost času vypořádáváním se s chybami - a na prvním místě je to jejich neopatrnost, co vytváří příliš mnoho chyb. Jiní tvrdí, že i když nebude možné opravit všechny ohlášené chyby, chybám, na kterých opravdu záleží, se někdo věnuje. Skutečné rozřešení této neshody se nezdá pravděpodobné; vytvoření smysluplného systému, který by měřil kvalitu jádra, je obtížný úkol. To nejlepší, co se dá dělat, je snažit se udržet seznam regresí tak malý, jak to jen jde; dokud systémy, které dříve fungovaly, fungují dál, je těžké hádat se příliš hlasitě o tom, že věci směřují špatným směrem.

Vázané připojení pouze ke čtení

Vázaná připojení [bind mounts] lze považovat za druh symbolického odkazu na úrovni souborového systému. Použitím mount --bind je možné vytvořit druhý přípojný bod existujícího souborového systému a vidět ho tak z jiného místa ve jmenném prostoru. Vázaná připojení jsou tedy užitečná pro vytváření specifických pohledů na jmenný prostor souborového systému; například jimi lze vytvořit takové připojení, které zviditelní část souborového systému v prostředí, které je jinak uzavřeno do chroot().

V jádrech do verze 2.6.25 je nicméně v implementaci vázaných připojení jedno omezení: platí pro ně stejné připojovací volby jako pro primární připojení. Takže příkazu jako je:

mount --bind -o ro /dulezita_data /neduveryhodny_kontejner/dulezita_data

se v /neduveryhodny_kontejner nepodaří připojit /dulezita_data pouze pro čtení, pokud byla původně připojena i pro zápis. Na systému autora článku je toto selhání tiché - vázané připojení je zapisovatelné, přestože bylo požadováno pouze pro čtení, a nevygeneruje se žádné chybové hlášení (v manuálové stránce k mount se píše, že volby nelze změnit).

Schopnost zajistit, aby byla vázaná připojení pouze pro čtení, má zjevně svoji hodnotu. Kontejnery jsou jeden příklad: správce si může přát vytvořit kontejner, ve kterém mohou běžet procesy pod rootem. Může být užitečné, aby měl kontejner přístup k souborovému systému hostitele, ale nemusí mít nutně právo do tohoto souborového systému zapisovat. Od 2.6.26 bude toto nastavení možné díky začlenění patche vázaných připojení pouze pro čtení od Dave Hansena.

Nicméně, stále není možné vytvořit vázané připojení pouze pro čtení příkazem uvedeným výše; atribut pouze pro čtení lze přidat jen znovupřipojovací [remount] operací o něco později. Potřebná sekvence příkazů je tedy takováto:

mount --bind /vital_data /untrusted_container/vital_data
mount -o remount,ro /untrusted_container/vital_data

Tento příklad nastoluje zajímavou otázku: co když nějaký proces otevře soubor pro zápis mezi těmito dvěma mount operacemi? Správce systému má právo očekávat, že připojení pouze pro čtení bude skutečně používáno pouze ke čtení. Patch do 2.6.26 je navržen tak, aby toto očekávání dodržel, i když se ukázalo, že množství k tomu potřebné práce bylo větší, než vývojáři očekávali.

Souborové systémy obvykle sledují, které soubory jsou otevřené pro zápis, aby pokus znovupřipojit souborový systém pouze ke čtení mohl být předán nízkoúrovňovému kódu souborového systému ke schválení. Nízkoúrovňový souborový systém ale neví nic o vázaných připojeních, ta jsou zcela implementována ve vrstvě virtuálního souborového systému (VFS). Takže zajistit přístup pouze pro čtení pro vázaná připojení vyžaduje, aby VFS sledoval všechny soubory, které byly otevřeny pro zápis. Nebo přesněji, VFS ve skutečnosti potřebuje sledovat pouze to, kolik souborů je otevřeno pro zápis.

Technika, která se k tomu používá, využívá něco, co vypadá jako zápisový zámek pro souborové systémy. Kdykoliv chce VFS provést nějakou akci, která zahrnuje zápis, musí nejdřív zavolat:

int mnt_want_write(struct vfsmount *mnt);

Návratová hodnota je nula, pokud je možný zápis, nebo záporný chybový kód v opačném případě. Toto volání lze nalézt na zjevných místech - jako například v implementaci open() - kde je požadován přístup s možností zápisu. Nicméně přístup k zápisu se dostává do hry v mnoha dalších situacích; například přejmenování souboru vyžaduje přístup k zápisu během trvání operace. Proto byla volání mnt_want_write() rozsypána do celého VFS kódu.

Když již není přístup k zápisu potřeba, "zápisový zámek" by měl být uvolněn voláním:

void mnt_drop_write(struct vfsmount *mnt);

Jedním z objevů bylo, že přístup k zápisu je potřeba na více místech, než by si kdo myslel. Konkrétně se ukázalo, že je potřeba volat mnt_want_write() i v nízkoúrovňovém souborovém systému, stejně jako ve VFS vrstvě. Proto formování patche znamenalo dlouhodobý proces hledání míst, která byla přehlédnuta, a přidávání mnt_want_write(). Ve snaze snížit náchylnost tohoto procesu k chybě dal Miklos Szeredi dohromady sadu pomocných funkcí ve VFS, které obalují situace, ve kterých je potřeba přístup k zápisu. Tyto funkce nicméně do 2.6.26 začleněny nebyly.

mnt_want_write() je pochopitelná na první pohled - jednoduše inkrementuje počítadlo probíhajících přístupů k zápisu. Problém byl v jednoduché implementaci, protože sdílený čítač za každý souborový systém by způsobil problémy se škálovatelností. Na multiprocesorových systémech by řádka v cache obsahující čítač poskakovala systémem a věci by se výrazně zpomalily.

Běžnou reakcí na tento druh problému je změnit čítač na proměnnou pro každý procesor [per-CPU], čímž se umožní, aby operace s čítačem zůstaly pro daný procesor lokální. Když někdo potřebuje znát celkovou hodnotu čítačů, jednoduše sečte verzi od každého CPU; tato operace je pomalá, ale také nepříliš častá. Na velkých systémech ale počet CPU může být velký - stejně jako počet souborových systémů a vázaná připojení tento počet ještě zvýší. Výsledkem je násobící efekt, který - opět - představuje problém se škálovatelností, akorát se v tomto případě projeví jako velká spotřeba paměti.

Patch vázaných připojení pouze ke čtení řeší tuto situaci tak, že se vrací ke globálním čítačům, které jsou cachovány na specifických procesorech. Každé CPU má za tímto účelem jednu z těchto struktur:

struct mnt_writer {
    spinlock_t lock;
    unsigned long count;
    struct vfsmount *mnt;
    }

Tato struktura neustále udržuje lokální součet pro jeden souborový systém reprezentovaný mnt. Jestliže procesor potřebuje přizpůsobit počet souborů otevřených pro zápis v daném souborovém systému, jde o jednoduchou záležitost inkrementace nebo dekrementace count. Když se pozornost procesoru obrátí k jinému souborovému systému, musí nejdřív přizpůsobit globální součet starého souborového systému, potom může teprve přepnout své mnt_writer na nový. Výsledek je kompromisem mezi zcela lokálními a zcela globálními čítači a poskytuje "dostatečně dobrý" výkon na benchmarcích vytvořených k zatížení systému.

Vázaná připojení pouze ke čtení se připojují k ostatním vlastnostem (jako jsou sdílené podstromy) a vytváří tak flexibilní sadu nástrojů pro vybudování jmenného prostoru souborového systému. Není jasné, kolik z těchto funkcí je v současnosti využíváno, ale jak se implementace kontejnerů v hlavní řadě blíží dokončení, o tuto schopnost bude pravděpodobně víc zájmu. Linuxové systémy mohou mít v následujících letech komplexnější strukturu souborového systému v porovnání s tím, co bylo k vidění v minulosti.

       

Komentáře

[Filip Jirsák]

V části o zpomalení vývoje jádra je chyba: Mnoho programů (možná většina z nich) je spojená s nějakým specifickým hardwarem nebo specifickou kombinací hardwaru; – má být problémů místo programů.

[Robert Krátký]

Dík, opraveno.

[Scarabeus IV]

Kdyz si prelozil ten prvni mount prikaz nevyplatilo by se to prelozit i v tom druhem at je to oboje neduveryhodny_kontejner? Jen kvuli zachovani stylu neni to chyba ze...

[Pavel Stárek]

Navíc kvůli kraniorektálnímu vnoření na straně výrobců grafického hardwaru musí spousta uživatelů na svých "hlavních pracovních" systémech používat proprietární ovladače, což znamená, že nová vydání nemohou testovat, ani kdyby chtěli.

Hmm, hezký povzdech, avšak nevidím důvod, proč se neustále mění API v jádře. Kdyby se měnilo jen u major čísel verzí, ale ono je změněno například i mezi verzemi 2.6.25.4 a 2.6.25.5 a nvidia ovladače (96.43.05 - mám postarší kartu) už nešli ručně zkompilovat. V Livna repozitáři jsou sice zkompilované jaderné moduly, avšak to znamená že se zase to lepidlo mezi kernelem a binárním blobem od Nvidie muselo patchovat. Jsem z toho takový rozmrzelý A reakce Nvidie na nové verze jádra je žalostná

[Robert Krátký]

i mezi verzemi 2.6.25.4 a 2.6.25.5

Změna API v rámci bugfixu?

[Pavel Stárek]

Nevím, možné to je. Ale pokud mám nějakou funkci volatelnou uvnitř jádra, tak obvykle bývá chyba v těle té funkce, a né že se s opravou v těle funkce změní její kompletní volání tím, že se například přidá ještě jeden parametr té funkce. Ale do jádra zase tolik nevidím, a divím se těm pravým hackerům, že se v tom opravdu velkém kusu kódu vůbec vyznají.

[cronin]

Ze je obvykle chyba v tele funkcie, ale jej signatura moze zostat nedotknuta, je pekna teoria, ktora ale neplati ovela castejsie, ako by sa pri povrchnom pohlade mohlo zdat. Jadernym vyvojarom je tato skutocnost znama a stabilita APIs vo vnutri kernelu bola mnohokrat diskutovana. Naposledy sa to v jadernych novinach objavilo pred par mesiacmi. Sucasne stanovisko je velmi jasne: ziadne stabilne API vo vnutri kernelu. Trvat na stabilnom API co i len pre minor verziu by bolo jednoducho prilis obmedzujuce.

[Milan]

Protože vývojářům kernelu jsou proprietární moduly ukradené? Většina vývojářů, jak se zdá, jsou dokonce úplně proti proprietárním ovladačům.

[Pavel Stárek]

To sice jsou, a taky na ně nenadávám, jen jsem si povzdechl že by to jaderné API nemuseli měnit tak často. To je spíš věcí Nvidie a toho člověka kterého platí za to, že ty jejich proprietární drivery budou fungovat. Takový Intel taky musí přeci reagovat na změny v jádře, avšak jejich ovladače gr. karet třeba nepotřebují jaderný modul (nevím, žádnou nevlastním, takže můžu kecat). Ale Nvidii zase bude trvat nejmíň půl roku, než milostivě vydají verzi 96.43.06 (například), kde v changelogu bude věta o podpoře nových jader.

[DjAARA]

Intelí grafiky používají kernelový modul:

i915                   38144  2 
drm                   105896  3 i915

[alpha]

Osobně věřím, že nejlepší způsob, jak zlepšit kvalitu kódu, je distribuovat ho.

A proto je ted Reiser4 nejlepsi FS na svete a Hans si muze spokojene uzivat ve sve vile s manzelkou a detmi. Nebo ne?
Od Linuse je tahle hlaska dost pokrytecka.

[Robert Krátký]

A hláška o manželce a dětech je zase stupidní, protože s tím vůbec nesouvisí. Nebo chceš říct, že Hansovy osobní problémy zavinil Linus, když ReiserFS nezačlenil?

Btw, Linus nebyl jediný (a ani ten hlavní), kdo ReiserFS v hlavním jádře nechtěl. A důvodem, pokud vím, nebyla nízká kvalita kódu, ale (mimo jiné) to, že ten FS nevyužíval subsystémy jádra a místo toho si dělal věci po svém.

[alpha]

Tou hlaskou o manzelce a detech jsem chtel naznacit, ze i zbytek vety je naprosta debilita, tedy ze R4 neni nejlepsi FS, a to protoze se o nej skoro nikdo nezajima, coz IMHO prave vyvojari jadra z velike casti zavinili.
To, ze R4 nevyuziva subsystemy jadra -- a jake konkretne? Jestli mate na mysli VFS, tak to je kravina, protoze pluginy do R4 nepracuji jenom na urovni celeho FS, ale muzete mit i ruzne pluginy v ruznych slozkach/souborech, coz VFS nejen ze neumoznuje, ale ani to umoznovat nemuze, protoze ostatni FS na to nejsou zadnym zpusobem stavene. R4 je cely jenom o pluginech. V podstate je to jenom spojovac pluginu pro format disku, kompresi, tail-packing, tvorbu adresaru atd. Tezko muzete treba takovy reg40 pouzit v JFS nebo ext3, to je jako byste chteli vyhodit Emacs za to, ze do nej nejdou pluginy z Firefoxu.

[Robert Krátký]

Moje povědomí o důvodech, proč nebyl R4 zařazen do hlavního jádra (ačkoliv strávil hodně dlouho v -mm, takže na očích určitě byl), vychází z čtení diskuzí, které o tom proběhly. A ačkoliv jsem si původně přál, aby se tam dostal (dlouho jsem používal v3), tak mi ty uváděné důvody připadaly dost přesvědčivé.

skoro nikdo nezajima, coz IMHO prave vyvojari jadra z velike casti zavinili.

O tom, co se do jádra dostane, a co ne, rozhodují správci jednotlivých částí, případně Linus jako poslední instance. Velmi pochybuji, že by se cokoliv do jádra nedostalo, kdyby to tito lidé považovali za přínos. Protože měli k R4 výhrady (ať už byly jakékoliv), které Hans odmítal řešit (vlastně se o nich často odmítal i bavit), tak byl výsledek nevyhnutelný.

[alpha]

No jiste, i ja uznavam ze Hans je idiot se kterym se neda normalne mluvit, ale prijde mi dost divne neprijmout kod z politickych duvodu, vymlouvat se na kvalitu toho kodu a malo vyvojaru a pak napsat, ze i nekvalitni kod prijima, protoze po prijeti na tom pracuje vic lidi a kvalita se zlepsi. To je vylozene pokrytecke.

[Robert Krátký]

prijde mi dost divne neprijmout kod z politickych duvodu

To je právě to, čemu nerozumím - jaké politické důvody máš na mysli? Ani jsem si nikde nevšiml, že by byl ten kód odmítán kvůli osobním antipatiím. To byl spíše sekundární důvod ("Tohle a tohle se nám na kódu nelíbí a navíc nám Hans nadává, tak proč bychom mu měli vycházet vstříc?").

[alpha]

Mne to vzdycky prislo jako: "Hans je pitomec, ale kdyz mu to reknete, tak vas pokouse."
Vazne nevidim na tom kodu nic spatneho. Nekdy je sice trochu neprehledny, ale funguje, a to velmi dobre, takze krome nejakych osobnich antipatii nevim, proc nebyl prijat. Navic v porovnani s ruznym jinym jadernym kodem, ktery prijat byl bez problemu (nenarazim na nic konkretniho).

[Robert Krátký]

http://kerneltrap.org/node/6844

(Starší, ale vzhledem k tomu, že brzy po té už začaly ty problémy s nezvěstnou manželkou, tak asi ne extrémně neaktuální.)

[alpha]

To jsem cetl, ale na moje pochyby to neodpovedelo: "Kod byl proveren, zjistilo se ze obsahuje zasadni nedostatky a Hans je odmitl opravit," ale uz tam ten clovek nerika jake nedostatky. Ja to vim: je to zase o tech pluginech, ktere by Hans pry mel mergnout do VFS, coz ale proste nejde, nemuze to jit, nikdy to nepujde a i kdyby, tak by to nemelo zadny smysl, ale ti lide, kteri nechteji R4 zaclenit do jadra na to budou neustale upozornovat. To je to, cemu ja rikam politicke duvody.

[Robert Krátký]

je to zase o tech pluginech, ktere by Hans pry mel mergnout do VFS, coz ale proste nejde, nemuze to jit, nikdy to nepujde

To mi připadá jako designové rozhodnutí, ne politické.

[alpha]

No jo, ale proc tedy nevyhodi i jine FS? Jak se vlastne R4 od tech ostatnich lisi? Pouziva pluginy. Je to spatne? Podle mne ne -- je to proste jen zpusob jeho funkce, a ocividne funguje dobre, vzhledem k tomu, ze pro praci s malymi soubory je to v soucasnosti nejrychlejsi linuxovy FS na svete.
Je to politicke rozhodnuti -- vyradit funkcni a spravne napsany kod jenom kvuli tomu, ze se nekomu nelibi, bez jakehokoliv racionalniho duvodu, je politicke rozhodnuti. Asi jako kdyby se jim nelibil nazev nebo pismo pouzite v tistene dokumentaci.

[trekker.dk]

No jo, ale proc tedy nevyhodi i jine FS?

A proč by měli? Vývojáři jiných FS byli zjevně schopni splnit podmínky pro to, aby jejich kód byl začleněn do jádra. Není důvod jejich dílo vyhazovat jenom proto, že se někdo rozhodl udělat si věci po svém a zatarasil si tak cestu...

[alpha]

Zatarasit si cestu tim, ze si delam veci po svem? To jako: "Vstupte do KSC, nedelejte si veci po svem!" To uz tu bylo.
Zkratka -- politicke duvody. Ten kod funguje, nic nerozbiji, je velmi kvalitni, ale vyvojari ho presto nechteji. Kdyby to misto Hanse zastitoval nekdo jiny, tak uz tam R4 davno je. Ale to by ho zase nikdo nechtel, protoze by bud mazal soubory, nebo by byl pomaly jako FAT. Hans je dobry vyvojar, ale geekstejsi nez geekove. A kromtoho nadava vsem okolo.

[Robert Krátký]

To jako: "Vstupte do KSC, nedelejte si veci po svem!" To uz tu bylo.

To je blbost. Není nic politického na tom, když správci jádra řeknou, že fs začleněné do jádra musí splňovat určitá pravidla. Můžeme se bavit o tom, jestli jsou jejich požadavky z technického hlediska správné, nebo špatné, ale je laciné to furt svádět na nějakou politiku.

[alpha]

"FS začleněné do jádra musí splňovat určitá pravidla," coz R4 splnuje. Jejich pozadavky jsou z technickeho hlediska spatne, coz politika je, protoze jine a horsi FS jejich kontrolou prosly.

[trekker.dk]

"FS začleněné do jádra musí splňovat určitá pravidla," coz R4 splnuje.

Určitá pravidla znamená pravidla, která stanovili vývojáři jádra, ne pravidla, která si stanovil Reiser sám, víme?

[Robert Krátký]

vyradit funkcni a spravne napsany kod jenom kvuli tomu, ze se nekomu nelibi, bez jakehokoliv racionalniho duvodu, je politicke rozhodnuti.

Racionálních důvodů bylo uvedeno hned několik. Ale především: když se kód nelíbí správcům jádra, tak je to zcela legitimní důvod, proč ho v jádře nemít. Samozřejmě nemusíme s pohledem a argumentací těch správců souhlasit, ale je zbytečné furt omílat, že tam ten fs není z jiného důvodu než kvůli technickým připomínkám.

[alpha]

Legitimni to je, o tom zadna, kernel hacking neni demokracie. Ale politicke duvody jsou to taky. Zkratka to technicke vysvetleni neni dostatecne pro to, aby tenhle kod prijat nebyl a jiny ano.

[trekker.dk]

Zkratka to technicke vysvetleni neni dostatecne pro to, aby tenhle kod prijat nebyl a jiny ano.

To tvrdíš ty.

Technické vysvětlení je dostatečné v tom smyslu, že byla stanovena pravidla - technické podmínky. Všichni ostatní je byli schopni dodržet, jen Raiser4 ne. Proto kód všech ostatní přijat byl (včetně FS pro 50 uživatelů na světě), jenom kód Reiser4 ne. Jak jednoduché.

Když si chceš hrát na něčím písečku, musíš dodržovat jeho pravidla.

[alpha]

Problem je prave v tom, ze ta pravidla stanovena nebyla. Nejsou nikde sepsana ani nebyla nikdy nikym vyrcena, takze R4 byl vlastne odmitnut zcela bez duvodu, s vysvetlenim odkazujicim na neco, co neexistuje. Prijde mi to jako fraska -- R4 je stejne dobry jako kterykoliv jiny, ale v jadre bez udani jedineho rozumneho, technickeho a skutecneho duvodu neni.

[Robert Krátký]

bez udani jedineho rozumneho, technickeho a skutecneho duvodu

Neustálým opakováním to nezačne být pravda...

[ased]

No neviem vazeni, ale cely vyvojovy proces jadra mi pride tak trochu pritiahnuty za vlasy... Prestal som sa podielat na vyvoji jadra, a kym nieco s tym procesom nespravia urcite sa k nemu nevratim. 1.) Absolutne nesuhlasim s menenim api v uplne kazdej verzii, naozaj aspon opravne verzie by ho mohli dodrzovat. 2.) Nesuhlasim so striktnym odmietanim binarnych modulov. Podla mna binarne moduly licencie splnaju, tak neviem preco to pre vyvojarov jadra znamena taky problem. Vsetci sa tvaria ze je to pre vseobecne dobro a blaho, ale myslim ze to je najvacsi omyl a najvacsia brzda linuxu. Sam zo skusenosti viem ake problematicke je udrziavat neaky modul funkcny, a nie vzdy je moznost ho vydat ako open-source. Cele mi to pride ako boj z veternymi mlynmi. Mozno som uz priliz dlho v komunite open-source, ale kedysi platilo: ked mi nevyhovuje ako to robia ostatni, spravim to inak... Kde sa vytratila ta otvorenost novym veciam, nazorom a pohladom na problemy...

No a teraz ma mozte ukamenovat... :)

[Robert Krátký]

2.) Nesuhlasim so striktnym odmietanim binarnych modulov.

To bys chtěl, aby bylo možné je zařadit do jádra? Protože pokud ne, tak vývojáři sice bin. moduly nemají v lásce, ale nikomu nebrání je s jádrem používat. Když se jednou taková iniciativa vyskytla, Linus ji okamžitě smetl ze stolu.

1.) Absolutne nesuhlasim s menenim api v uplne kazdej verzii

Binární moduly jsou sice tolerovány, ale není důvod na ně brát při vývoji ohledy, když by to brzdilo/ztěžovalo pokrok jiných součástí jádra.

[Jan Molič]

Zdá se, že se to konečně dostalo do vanilly. Doufám, že se tam dostal celý patch, který byl už delší dobu v -mm jádře. Tam totiž neumí jen remountovat adresář readonly, ale umí měnit i další parametry, jako třeba noexec - což je VELICE přínosné. Mimochodem, lze tak namountovat adresář přes tentýž adresář readonly Osobně považuji toto vylepšení jako jedno z nejzásadnějších, na němž se dá postavit poměrně zabezpečený systém. Oproti unionfs je to mnohem jednodušší řešení.