26.2.2008 07:35
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Rozbalit Rozbalit vše Re: Jaderné noviny - 16. 1. 2008
Portál AbcLinuxu, 10. května 2024 20:06
Aktuální verze jádra: 2.6.24-rc8. Citát týdne: Jeff Garzik. Lepší btrfs. Připojování souborových systémů bez práv. ext3 metaklusterování. Stav Unionfs.
Aktuální předverze je (k 16. 1. 2008) 2.6.24-rc8, vydaná 15. ledna. Obsahuje slušnou řádku oprav, ale nic moc dalšího. Linus Torvalds k tomu řekl: Takže jsem si docela jistý, že je tohle poslední -rc a finální 2.6.24 vyjde někdy kolem příštího víkendu. Ale do té doby to pořádně přezkoušejme a pokusme se ještě opravit poslední případné regrese. Vizte podrobnosti v dlouhém changelogu.
Po vydání -rc8 bylo začleněno jen pár oprav.
Minulý týden nevyšla žádná -mm verze.
Aktuální stabilní jádro řady 2.6 je 2.6.23.14, vydané (společně s 2.6.22.16) 14. ledna. Tyto verze obsahují jediný patch: opravu bezpečnostní chyby souborových systémů.
Starší jádra: 2.6.16.58 vyšlo 16. ledna s několika opravami.
Zajímalo by mě, jak by vypadalo malinké a ROZUMNÉ bytecodové rozhraní založené na registrech. Pro každé vlákno by byla mezi jádrem a uživatelským prostorem sdílena jedna stránka. Uživatelských prostor by ji zaplnil bytecodem, u virtuálních strojů 256 registry -- přičemž instrukce by zhruba odpovídaly systémovým voláním.
Běžný případ -- jedno systémové volání, např. open(2) -- by byl jediný bytecode a dvě uložení VM registrů. Výsledek by byl uložen v dalším VM registru.
Ale tento formát by umožňoval i komplexnější případy -- uživatelské programy by mohly jádru předat sérii systémových volání, která by byla prováděna, dokud by nedošlo k nějaké výjimečné události. Výsledky by byly uloženy ve VM registrech (nebo uživatelských adresách uložených ve VM registrech).
-- Jeff Garzik
Chris Mason nedávno vydal Btrfs v0.10, která obsahuje několik zajímavých funkcí. Obecně lze říci, že Btrfs ušlo od první zmínky v LWN (btrfs a NILFS) dlouhou cestu. Z Btrfs by se během pár let mohl stát souborový systém, který bude většina z nás používat - alespoň ti z nás, kteří budou používat rotační ukládání. Takže stojí za to ho sledovat.
Btrfs je zcela nový souborový systém vyvíjený Chrisem Masonem. Jde o copy-on-write [kopírování při zápisu] systém, který dokáže kdykoliv rychle vytvářet snímky stavu souborového systému. To snímkování je tak rychlé, že se v Btrfs používá jako transakční mechanismus, a proto není potřeba samostatný žurnál. Podporuje suboddíly [subvolumes], což jsou vlastně nezávislé souborové systémy na jednom zařízení. Btrfs je navržen pro rychlost a poskytuje také kontrolní součty všech uložených dat.
Některé patche pro jádro si brzy najdou cestu do produkčního použití. Například před rokem nikdo nemluvil o férovém plánování (snad kromě členů konference -ck); ale v tuto chvíli už je plánovač CFS několik měsíců součástí jádra. KVM se také dostalo do jádra během pouhých dvou vývojových cyklů od svého představení. U souborových systémů to však takhle nefunguje. Vývojáři souborových systémů jsou opatrná a konzervativní parta; a ti, kdo takoví nejsou, obyčejně nepřežijí prvních několik setkání s uživateli, kteří přišli o svá data. To vše znamená, že ačkoliv Btrfs postupuje rychle, nemá zatím cenu plánovat jeho produkční nasazení. Jako kdyby chtěl tuhle skutečnost každému vtlouct do hlavy, Btrfs zatím vždy shodí systém, když mu dojde místo. Verze 0.10 také, podobně jako její předchůdci, mění formát dat na disku.
Změna diskového formátu je jednou z hlavních vlastností nové verze. Formát nyní obsahuje zpětné reference na téměř všechny objekty v souborovém systému. Proto je teď jednoduché získat odpověď například na otázku "Kterému souboru náleží tento blok?" Zpětné reference přidávají redundantní informace, které lze využít pro kontrolu integrity systému. Pokud například soubor tvrdí, že mu náleží sada bloků, které však o sobě říkají, že patří jinému souboru, něco je zjevně v nepořádku. Zpětné reference lze také použít k rychlému zjištění, které soubory jsou postiženy při selhání diskových bloků.
Většinu uživatelů však bude spíše zajímat jiná nová funkce, kterou existence zpětných referencí umožnila: online změna velikosti. Nyní je možné změnit velikost souborového systému Btrfs v okamžiku, kdy je připojen a využíván - a to včetně zmenšení. Pokud se Btrfs musí vzdát nějakého prostoru, může rychle najít soubory, kterých se to týká, a přesunout příslušné bloky jinam. Btrfs by tedy měl hezky fungovat s mapovačem zařízení, kterému by pomohl zvětšovat nebo zmenšovat souborové systémy podle potřeby.
Další zajímavou funkcí ve verzi 0.10 je konvertor z ext3. Je možné nedestruktivně převést ext3 na Btrfs - a zpátky, je-li to potřeba. Konvertor funguje tak, že si uloží kopii ext3 metadat, která se nacházejí na začátku disku, a pak vytvoří paralelní adresářový strom ve volném místě souborového systému. Takže kompletní ext3 zůstane na disku, což sice zabere nějaké místo, ale umožňuje návrat, pokud by to s Btrfs nevyšlo. Vlastní data souborů jsou mezi oběma souborovými systémy sdílena; protože Btrfs provádí copy-on-write, původní ext3 zůstane i po změně Btrfs. Úplný přechod na Btrfs se provede pouhým smazáním ext3 suboddílu, čímž se uvolní zabrané místo.
A konečně, mechanismus copy-on-write lze při připojení vypnout. U některých typů zátěží copy-on-write věci zbytečně zpomaluje, aniž by nabízelo jiné výhody. Vzhledem k tomu, že 1) jedním z druhů takových zátěží je správa relačních databází a 2) Chris pracuje pro Oracle, je celkem s podivem, že to trvalo tak dlouho, než se tato možnost objevila. Pokud však na daný soubor odkazuje více snímků, copy-on-write se přesto provádí; jinak by nebylo možné udržovat snímky navzájem nezávislé.
Jste-li zvědaví, kam Btrfs míří, přečtěte si plán, který Chris připravil - popisuje v něm, čeho by chtěl letos dosáhnout. Vypadá to, že další na řadě jsou "storage pools", které by Btrfs umožnily zahrnovat více zařízení. Jakmile to bude hotovo, dojde na implementaci prokládání [striping] a zrcadlení. Dlouhodobé cíle zahrnují snímky jednotlivých adresářů, detailní zamykání (v současné době je používán jediný globální zámek), zabudovanou podporu pro inkrementální zálohování a online kontrolu souborového systému. Oprava toho otravného problémku při nedostatku místa na seznamu není, ale dá se předpokládat, že na to Chris myslí.
O začlenění se v rámci nadcházejícího vývojového cyklu 2.6.25 bude snažit několik patchů souvisejících se souborovými systémy; jedním z nich je patch umožňující připojování bez práv [unprivileged mount] od Miklose Szerediho. Patch umožňuje neprivilegovaným uživatelským procesům volat systémové volání mount() a - v určitých případech - i úspěšné vykonání tohoto volání. Mohlo by to vést k situaci, ve které by uživatelé mohli vytvářet svá vlastní prostředí a setuid utilita mount by už nebyla potřeba.
Patch přidává do struktury vfsmount nové pole uid, což jádru dává možnost sledovat vlastníka konkrétního připojení. Administrátor systému může dát vlastnictví konkrétního připojení uživateli pomocí nového příznaku MNT_SETUSER. Běžné využití by mohlo být třeba "bind" připojení uživatelova domovského adresáře na sebe sama, takže by uživateli dané připojení patřilo. Pak by mohl uživatel do tohoto bodu připojení volně připojovat jiné souborové systémy - se dvě podmínkami:
Za předpokladu, že systém povolí připojení, budou příznaky povolující soubory zařízení a setuid natvrdo odstraněny - pokud nemá uživatel potřebné kvalifikace tak jako tak. Uživatelé mohou odpojovat souborové systémy, které vlastní, ale žádné jiné. Další nový příznak (MNT_NOMNT) označuje konkrétní souborový systém jako konec řady - pod ním už nejsou povolena žádná neprivilegovaná připojení. Výsledkem toho všeho by měl být mechanismus, s jehož pomocí by uživatelé mohli organizovat své hierarchie souborových systémů bez potřeby administrátorských práv a bez rizika, že ohrozí bezpečnost systému.
Člověk by se mohl pozastavit nad tím, proč je taková změna systémového volání mount() vůbec potřeba - vzhledem k tomu, že uživatelé už mohou provádět připojování bez práv celá léta. Odpovědí je, že stávající mechanismus má pár nedostatků. Každé potenciální neprivilegované připojení musí být výslovně povoleno řádkem v /etc/fstab. To funguje dobře v případě jednoduchých situací, například chceme-li uživatelům umožnit připojování CD nebo úložného zařízení přes USB. Jakmile však chtějí uživatelé provádět komplikovanější věci, například připojovat své vlastní speciální FUSE, postup s /etc/fstab nefunguje. Existuje sice samostatný setuid program, který dá právo provádět neprivilegovaná připojení FUSE, ale to je spíše berlička než řešení.
Stávající mechanismus pro uživatelské připojování také vyžaduje, aby byla utilita mount nainstalována se setuid root. Každá setuid binárka je potenciální bezpečnostní díra, takže má cenu tyto programy odstraňovat, kdykoliv je to možné. Patch pro připojování bez práv nabízí možnost odstranit setuid program a zároveň ponechat kontrolu v rukou administrátora systému. Pokud se tedy neobjeví nějaký neočekávaný problém, je dost velká šance, že se tato funkce do 2.6.25 dostane.
Systém ext3 používá pro udržování přehledu o blocích v každém souboru klasickou unixovou metodu ukazatele na blok. Pro daný soubor obsahuje inodová struktura na disku prostor pro dvanáct čísel bloků; ukazují na prvních dvanáct bloků v souboru - prvních 48 kB prostoru. Je-li soubor větší, obsahuje třináctý ukazatel adresu prvního nepřímého bloku; tento blok obsahuje dalších 1024 (na souborovém systému se 4K bloky) ukazatelů na bloky. Pokud by to nestačilo, máme 14. ukazatel pro dvojitě nepřímé bloky - každá položka v takovém bloku je adresa nepřímého bloku. A kdyby nestačilo ani to, máme 15. položku, která ukazuje ne trojitě nepřímý blok plný ukazatelů na dvojitě nepřímé bloky.
Je to velmi efektivní způsob reprezentace malých souborů - tj. druh souborů, které unixový systém typicky obsahoval. V současné době, kdy člověk zapomene na ten adresář plný DVD obrazů a ani si nevšimne, že chybí místo, už to tak dobře nefunguje - všechny ty individuální ukazatele na bloky velké datové struktury znamenají dost režie. Proto může na ext3 trvat odstraňování velkého souboru tak dlouho - systém musí vyhledat všechny nepřímé bloky, což zase vynucuje hodně diskové aktivity. Kvůli tomu se současné souborové systémy přiklánějí k používání mechanismů založených na rozsazích [extent], ale to v případě ext3 není možné.
Další potíž s nepřímými bloky spočívá v tom, že je programy pro kontrolu souborového systému musí všechny najít a prověřit. To souborový systém rovněž zpomaluje, jelikož musí hlava disku hodně vyhledávat - fsck tedy běží pomalu. Pomalá kontrola souborového systému byla motivací pro patch, který napsal Abhishek Rai - ten se snaží zlepšit výkon u systémů s mnoha nepřímými bloky.
Je používán poměrně jednoduchý přístup: patch se snaží seskupit na disku alokace nepřímých bloků. Stávající ext3 kód alokuje nepřímé bloky, kdykoliv jsou potřeba kvůli datovým blokům přidávaným k souboru; obyčejně jsou umístěny vedle těch datových bloků. Mohli bychom si myslet, že takové umístění urychlí následné přístupy k souboru, ale nemusí to tak nutně být; ke čtení nebo zapisování nepřímých bloků obyčejně dochází v jinou dobu než k operacím s datovými bloky. Co však toto umísťování způsobí, je rozházení nepřímých bloků po celém disku. Takže proces, který musí prozkoumat všechny nepřímé bloky spojené se souborem, zařídí, že disk provádí spoustu vyhledávání.
"Metaklusterování" rezervuje sady souvislých bloků na konci každé skupiny bloků. Když je potřeba nepřímý blok, souborový systém se nejprve pokusí nějaký získat z této vyhrazené oblasti. Výsledkem je, že jsou všechny nepřímé bloky vedle sebe. Pokud někdo potřebuje přečíst několik těchto bloků, aniž by ho zajímal obsah datových bloků, má je po ruce bez velkého hledání. A programy pro kontrolu souborových systémů potřebují přesně tohle - stejně jako proces odstraňování souborů. Patch nedoprovázely žádné výsledky testů, ale zrychlení způsobené eliminací hledání by mělo být výrazné.
Andrew Morton přesto pochyboval o tom, jestli je takový patch potřeba. Měl obavy, jestli výhody převáží riziko spojené s úpravami zavedeného a široce používaného souborového systému:
V každém rozumném prostředí budou lidé kontrolovat své souborové systémy během plánovaného odstavení, takže přínos snížení tohoto odstavení ze šesti na dvě hodiny je pravděpodobně dost malý - když nedojde k přerušení služby.
Jiní však nesouhlasili a poukazovali na to, že o čas jde nejvíce při neplánovaných kontrolách. To zahrnuje ty nádherné případy, kdy se spustí kontrola při bootu po dosažení maximálního počtu připojení bez fsck. Obyčejně k nim dochází, když se člověk snaží co nejrychleji připravit, jelikož má například začít přednášet. Takže patch by nakonec mohl být přijat - nemělo by s ním být spojeno žádné velké riziko a není potřeba měnit formát na disku. Jde však o patch souborového systému, a proto se jej nikdo nebude snažit procpat do hlavního jádra, dokud se mu nedostane hodně testování a kontroly.
Naposledy jsme se na unionfs dívali téměř před rokem. Od té doby se toho s Unionfs příliš nedělo, ale ani nezmizel. Vývojáři teď přišli s vylepšenou verzí, kterou by rádi dostali do jádra 2.6.25.
Hlavní myšlenkou Unionfs je umožnit spojení několika nezávislých souborových systémů do jediného celku. Jako příklad si představte uživatele s distribučním instalačním DVD plným balíčků, malým diskem a nechutně pomalým připojením. Bylo by fajn si balíčky uložené na DVD ponechat po ruce pro pozdější instalace. Fajn je však také udržování adresáře plného aktualizací od distributora, které by byly používány namísto DVD verze. S pomocí Unionfs by mohl tento uživatel připojit read-only DVD a pak přes DVD připojit zapisovatelný souborový systém pro aktualizace. Aktualizované balíky se uloží na zapisovatelný souborový systém, ale všechny dostupné balíky budou viditelné pohromadě ve spojeném pohledu. Aby se předešlo zmatkům, mohl by uživatel zastaralé balíčky vymazat, aby v rámci Unionfs už nebyly vidět - i když z DVD samozřejmě nemohou být doopravdy vymazány. Takže Unionfs umožňuje vytvoření na pohled zapisovatelného souborového systému postaveného nad read-only základem. Nabízí se i řada jiných možností použití.
Pokud uživatel přepíše soubor, který je uložen na read-only "větvi" Unionfs, je reakce relativně přímočará: nově zapsaný soubor je uložen na zapisovatelné větvi, která má vyšší prioritu. Pokud žádná taková větev neexistuje, operace selže. Řešení výmazu z read-only větve je však ošemetnější. V takovém případě vytvoří Unionfs na zapisovatelné větvi "zabělení" [whiteout] ve formě speciálního souboru (jehož jméno začíná na .wh.). Některým vývojářům se tento přístup nelíbí, protože se po nějaké době vrchní větev těmito speciálními soubory zaplácá. Je však těžké přijít na jiný způsob, jak mazání řešit - zvláště když je jedním z cílů udržet změny jádra VFS na minimu.
To však neznamená, že se vývojáři Unionfs nesnažili. Připravili také verzi Unionfs, která si udržuje svůj vlastní malý oddíl (na zapisovatelném médiu). Metadata (především zabělení) jsou ukládána na tento specializovaný oddíl, takže už nezaneřáďují ostatní souborové systémy. Používání vyhrazeného oddílu má i další výhody, včetně možnosti začlenit jeden Unionfs jako větev v druhé "unii"; vizte tento dokument, kde je o alternativním přístupu více informací. Vývojáři doufají, že se jim jej podaří pomalu zavést do verze, kterou v tuto chvíli navrhují k začlenění do hlavního jádra.
Dalším problémem Unionfs je zvládání modifikací provedených přímo ve větvích, které nejdou přes unii. Verzi z ledna 2007 doprovázela zlověstná varování: přímé úpravy větví Unionfs mohly vést k pádu systému a ztrátě dat. Vzhledem k tomu, že souborové systémy zabalené do unie stále existují i nezávisle na ní, budou vždy představovat lákavý cíl pro úpravy, i kdyby nebyly nutné (například snaha uložit data na konkrétní součást složeného souborového systému). Takže implementace Unionfs, která si s takovými úpravami neporadí, je pastí na každého uživatele.
Vývojáři tvrdí, že v aktuální verzi je již problém vyřešen. Nyní téměř každý vstup do kódu Unionfs způsobí kontrolu času úpravy příslušného souboru ve všech vrstvách unie. Pokud se ukáže, že byl soubor změněn, Unionfs na něj zapomene a natáhne informace znovu od nuly, takže je uživateli ukázána nejčerstvější verze souboru (nebo adresáře). Tento přístup řeší problém poměrně účinně, s jednou výjimkou: Unionfs nepozná, když nějaký proces změní soubor, který si do svého adresního souboru namapoval pomocí mmap(). Takže v takovém případě nemusí být změny viditelné pro procesy, které k danému souboru přistupují přes Unionfs.
V obou případech by se vývojáři Unionfsfs raději dočkali lepší podpory od VFS. Některé operační systémy poskytují nativní podporu zabělení, ale Linux ne. Také neexistuje způsob, jak by mohl souborový systém ležící na spodku hromady jiných souborových systémů dát vyšším vrstvám vědět, že se něco změnilo. Opravení těchto nedostatků by vyžadovalo výrazné zásahy do VFS a změny by mohly postupně protéct až k jednotlivým implementacím souborových systémů. Nikdo tedy neočekává, že by k tomu mělo brzy dojít.
Další důležitou změnou v Unionfs je odstranění rozhraní ioctl() pro správu větví. Všechny změny vytvořeného Unionfs jsou nyní prováděny prostřednictvím volby remount příkazu mount. Ruší to potřebu samostatné utility pro konfiguraci Unionfs a umožňuje to atomické provádění komplexních změn.
Na základě toho všeho jsou hackeři Unionfs přesvědčeni, že nadešel čas pro zařazení kódu do jádra. Stal by se tak z něj druhý podporovaný "stackovací" souborový systém (první je eCryptfs) a pomohlo by to dlouhodobému cíli - vylepšení spolupráce VFS vrstvy se stackováním. Někteří lidé o tom mluví, jako kdyby začlenění do 2.6.25 byla hotová věc, ale to ještě není jisté. Christoph Hellwig, jehož názor v těchto záležitost hraje velkou roli, s myšlenkou Unionfs nesouhlasí:
Myslím, že jsme dali jasně najevo, že Unionfs není ten správný způsob a že na patche umožňující spojené připojování přijde řada, jakmile budou začleněny a stabilní patche pro neprivilegované připojování a pro read-only u jednotlivých přípojných bodů.
Unionfs hacker Erez Zadok odpověděl, že Unionfs funguje a je používán teď - zatímco přidání podpory unií do VFS je vzdálená věc. A proto navrhl:
Podle mě by bylo lepší začít s Unionfs (samostatný souborový systém, který se nedotýká zbytku jádra). A jak bude Linux podporovat víc a víc funkcí, které pomáhají uniím/stackování obecně, tak měnit Unionfs, aby je využíval (např. nativní podporu zabělení). Nakonec by mohla být přítomna základní podpora unií na úrovni VFS a zároveň souborový systém, který poskytuje extra funkce (např. persistenci).
Při pohledu na nedávnou verzi patche pro podporu spojeného připojování je těžké v nich vidět řešení, které by mohlo být připravené v brzké době. Jak říká autor (Bharata Rao), jde o práci v raném, průzkumném stádiu; je tam dost problémů, ke kterým není řešení vůbec v dohledu. Spojené připojování, které provádí většinu práce v rámci VFS vrstvy, je možná ten správný přístup z dlouhodobého hlediska, ale nijak brzy nebude ve takovém stavu, aby jej šlo nabídnout uživatelům.
Jde přeci jen o hodně těžkou záležitost a Unionfs má značný náskok. To samo o sobě však nestačí k tomu, aby měl Unionfs začlenění do 2.6.25 jisté, i když to velmi pomáhá. Kdokoliv se postaví proti začlenění, bude muset uživatelům Linuxu vysvětlit, proč by možnost spojovat souborové systémy neměli mít v roce 2008 k dispozici.
26.2.2008 07:35
Petr Tomášek | skóre: 39
| blog: Vejšplechty
26.2.2008 08:17
belisarivs | skóre: 22
| blog: Psychobláboly
29.2.2008 08:11
Petr Tomášek | skóre: 39
| blog: Vejšplechty
#./unionfs -o allow_other /data/multimedia/mm10/:/data/multimedia/mm12 /data/multimedia/mm #su - radek #ls /data/multimedia/mm -l total 0 #ls -l /data/multimedia/mm12 total 200A netusim proc. Prava jsou v poradku, zkousel jsem i ruzne dalsi volby jako
noauto_cache,readdir_ino,debug,allow_other,stats,umask=007,gid=3001v ruznych kombinacich a nic
26.2.2008 11:22
Petr (DotaZ) Jakubec | skóre: 5
26.2.2008 11:41
Honza Balák | skóre: 23
| blog: Jaxův linuxový zápisník
| Předklášteří
26.2.2008 14:21
Honza Balák | skóre: 23
| blog: Jaxův linuxový zápisník
| Předklášteří
dayvee@laptop:~$ uname -r 2.6.24-1-686 dayvee@laptop:~$ sudo -s root@laptop:~# apt-get update > /dev/null root@laptop:~# apt-get -t unstable install linux-image-2.6.2 linux-image-2.6.22-3-486 linux-image-2.6.22-3-vserver-k7 linux-image-2.6.22-3-686 linux-image-2.6.24-1-486 linux-image-2.6.22-3-686-bigmem linux-image-2.6.24-1-686 linux-image-2.6.22-3-amd64 linux-image-2.6.24-1-686-bigmem linux-image-2.6.22-3-k7 linux-image-2.6.24-1-amd64 linux-image-2.6.22-3-vserver-686 linux-image-2.6.24-1-xen-686 root@laptop:~# apt-get -t unstable install linux-image-2.6.2... mluvi za vse.
jen pro opravu preklepu hned v zacatku: ... a jeste odkaz na dlouhy changelog nefunguje...Dík, opraveno.
PS: uz aby 2.6.24 bylo na svete...Vždyť už je
. V prvním odstavci článku je odkaz na zprávičku.
26.2.2008 19:52
Nicky726 | skóre: 56
| blog: Nicky726
27.2.2008 07:57
michich | skóre: 51
| blog: ohrivane_parky
VirtualBox kernel module i NVidia modul prijatelne. Po upgradu na 2.6.24 nelze zadny z nich ani zkompilovatOba mi (s 2.6.24) fungují bez potíží. Nebude chyba jinde?
Tak napriklad s 2.6.22.9 funguje ACPI DSDT override patch, ATI driver, VirtualBox kernel module i NVidia modul prijatelne. Po upgradu na 2.6.24 nelze zadny z nich ani zkompilovat, nemluve o problemech s nekompatibilnim gcc a standardni c knihovnouZ těch čtyř používám VirtualBox modul a nVidia modul a žádný problém jsem při přechodu z 2.6.22 na 2.6.24 nezaznamenal. PEBKAC.
27.2.2008 22:56
michich | skóre: 51
| blog: ohrivane_parky
Zadny PEBKAC ty tunto, uvedom si ze Virtual Box i NV modul jsem nainstaloval pred vice nez pul rokem, kdy byl 2.6.22.9 nejaktualnejsi a upgradoval jsem na 2.6.24.2 pouze kvuli bezpecnostnim fixum, kernel > 2.6.22.9 je spinaPak kdo je tady ťunťa. Použiješ nové jádro, ale snažíš se k němu používat půl roku staré moduly, to je jako kdybys ve Vistách chtěl použít ovladače pro Windows 98... to taky nejde, ale z nějakého důvodu se tomu nikdo nediví. Brání ti něco zaktualizovat ty moduly? Navíc vývojáři jádra už několikrát jasně řekli, že na binární moduly se nebudou ohlížet; co je v jádře a přestane to fungovat, to někdo opraví během -rc; co je mimo jádro, za to si nese zodpovědnost autor a pokud nějaký binární krám přestane fungovat a po vydání nové verze není k dispozici aktuální modul, je to chyba toho, kdo musí svoje věci za každou cenu distribuovat jako uzavřený blob.
Vzhledem k tomu ze se pote Virtual Box module, NV module ani Acpi Override patch nezkompilovaly kvuli symbolum, ktere prestaly v system-wide kernel headrech byt musi snad kazdy pochopit ze se jedna o nefunkcnost z duvodu zamerneho odstraneni tech symboluTy symboly určitě nebyly odstraněny mezi -rc8 a vydáním verze, takže všichni měli dost času na napsání úprav. Stížnostmi na vývojáře jádra pláčeš na špatném hrobě. Proč jsou jádra 2.6.22.9 špína, to bych rád věděl...
No samozrejme ze ty moduly se snazim *ZKOMPILOVAT* ze zdrojovych koduZ půl roku starých zdrojových kódů. Když jsme u toho překladu a tvé stížnosti na gcc-4.2 - to taky používat nemusíš.
Napsal jsem ze kernel > 2.6.22.9 je spina, argumentovat mohu sloucenim x86 a x86_64 ktere prineslo stovky bugu,1) Aha, takže jsi chtěl napsat >= 2.6.23, 2) většina těch bugů byla opravena před vydáním
byl to nejvetsi patch v historii,No a? Velké změny - velký patch.
v neposledni rade je 2.6.23 psana i schvalovana z vice nez 80% enterprise sektorem, kde se to pise pro zisk a tudiz se na kvalitu a bezpecnost kasle.Tak to je blábol.
Nema smysl uz to dale rozvijet, prosim nereagovat na tento komentar...Ano, to nemá. Je čím dál tím víc zjevné, že se jedná o problém mezi židlí a klávesnicí na tvé straně.
A ještě ke všemu ne moc vynalézavý blábol... z čeho by měl ten enterprise sektor peníze, kdyby produkt nefungoval?v neposledni rade je 2.6.23 psana i schvalovana z vice nez 80% enterprise sektorem, kde se to pise pro zisk a tudiz se na kvalitu a bezpecnost kasle.Tak to je blábol.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
26.2.2008 14:49
27.2.2008 01:06