Vrstva tty je jedním z velmi mála kousků jádra, který mě děsí :-)Portál AbcLinuxu, 25. prosince 2025 14:23
Aktuální verze jádra: 2.6.31-rc4. Citáty týdne: Andrew Morton, Dan Carpenter, Linus Torvalds. V krátkosti: Časové značky pro FAT; Mapování UID pro ext2/3; Fanotify; ABUSE; Chystá se nová kniha. Dynamické sondy s ftrace. Hledání přetečení bufferu pomocí Parfait. Bouře ve sklenici votty.
Současné vývojové jádro je 2.6.31-rc4 vydané 22. července. Ok, to byl veselý týden. Měli jsme chybu v binutils, chybu v ccache a chybu v překladači. Všechno to byly chyby mimo jádro, ale vedly na chybný překlad. Krom toho se z většiny jedná o hromadu oprav, mnoho z nich jsou nově objevené problémy s NULLovým ukazatelem; všechny detaily vizte v kompletním changelogu.
Současné stabilní jádro 2.6 je 2.6.30.3 vydané (společně s 2.6.27.28) 24. července. Jedná se o aktualizaci s jedinou opravou, která obchází problém překladače, jež postihuje 2.6.30.2 a 2.6.27.27
Aktualizace 2.6.30.4 a 2.6.27.29 se v současnosti revidují. Tato jádra (každé obsahuje dlouhý seznam nejrůznějších oprav) budou pravděpodobně vydána někdy okolo 30. července.
Pro uživatele 2.4: 26. července vyšla aktualizace 2.4.37.4. Mezi jinými věcmi obsahuje bezpečnostní opravu spojenou s personalitami; správce 2.4 Willy Tarreau by ocenil, kdyby se na kód podívalo více lidí, aby pomohli s tím opravit ji pořádně.
-- Dan Carpenter přichází s další ubohou výmluvou
Souborový systém FAT má mnoho nedostatků. Fakt, že nedokáže zaznamenávat časové značky pro kořenový adresář souborového systému, asi není na vrcholu seznamu většiny lidí, ale Jorg Schummer dal dohromady patch, který tyto značky poskytuje. Patch je hack, který značku ukládá do popisku VFAT svazku, čímž ji v podstatě schovává před jakýmkoliv systémem, který ji nehledá. Není to nový přístup, Mac OS X dělá totéž. Tato vlastnost nevzbuzuje příliš jásotu, ale je volitelná, implementace je přímočará a ve výchozím nastavení je to vypnuté. Je tudíž jenom málo důvodů ji nechat mimo.
Další chyba FAT je neschopnost uložit informace o tom, který uživatel a skupina vlastní soubor. Někdo by možná tuto „funkci“ nechtěl portovat na vyspělejší souborové systémy, ale Ludwig Nussel si všiml problému: Uživatel, který stěhuje souborový systém ext3 z jednoho stroje na jiný, bude mít problémy s přístupem k souborům na něm, pokud bude mít účet daného uživatele na každém stroji jiné UID. Řešením je přidat do ext2 a ext3 připojovací volbu uid=; souborový systém by potom mapoval dané uživatelské ID (na běžícím systému) na nulu (na souborovém systému).
Ani tento patch nevzbuzuje příliš jásotu; používání souborových systému ext3, které se přesouvají mezi stroji, je pravděpodobně relativně vzácné. I tak Andreas Dilger naznačil, že tato vlastnost by mohla mít své využití, ale že by byly vítány změny. Možnost vytvářet rootem vlastněné soubory se setuid musí zmizet a bylo by hezké mít obecnou schopnost „mapuj UID1 na UID2“ místo pouhého mapování na a z rootovského ID. Andreas také požadoval ext4 verzi patche.
Eric Paris zaslal popis nového API fanotify k okomentování s tím, že skutečné patche přijdou brzy. API se od té doby, co zde bylo naposledy popsáno začátkem července, významně změnilo; podivné použití getsockopt() pro vybírání upozornění je pryč. Místo toho se vytváří relativně normální socket, kde se pro čtení událostí používá read(). Objevilo se mnoho návrhů a komentářů, ale konsenzus je, zdá se, takový, že věci míří správným směrem.
Máme FUSE, které umožňuje implementaci souborového systému v uživatelském prostoru, a CUSE, které dělá to samé pro znaková zařízení. Proč tedy nemít totéž pro bloková zařízení? S patchem ABUSE, který vytvořil Zachary Amsden, je to nyní možné. Zachary říká: Nejde tu o výkonnost, ale o rozšíření hranic jádra až k téměř nepravděpodobnému. Komentář ke kódu říká, že tato vlastnost může být „neuvěřitelně užitečná“, ale momentálně není jasné, jaké využití je zamýšleno.
ABUSE velmi pravděpodobně začleněno nebude z jednoduchého důvodu, že to, co dělá, lze již nyní udělat s ovladačem síťového blokového zařízení [network block device, NBD]. Zachary plánuje přejít na NBD, ať už má na mysli cokoliv. Toto cokoliv zjevně musí mít přístup k oddílům, takže FUSE využít nelze.
Téma o oddílech vedlo k malé postranní diskuzi, kde Alan Cox naznačil, že podpora pro oddíly by z jádra měla být úplně odstraněna. K implementaci oddílů by se místo toho měl použít device mapper. Z použití device mapperu by plynulo mnoho výhod – hlavně flexibilita při správě – ale jsou uživatelé včetně Linuse, kteří nemají zájem o to, aby ho museli použít. Jaderný kód pro oddíly tedy pravděpodobně v nejbližší době nikam nezmizí.
Když správce manuálových stránek Michael Kerrisk psal o nedávném vydání, poznamenal, že pokročil v psaní nové knihy, která rozsáhle dokumentuje API pro uživatelský prostor linuxového jádra. Nebude to čtení na dobrou noc; vypadá to, že nakonec bude mít 1500 stránek. Pro zvědavé Michael zaslal obecný popis knihy a obsah. Vydání se očekává někdy v první polovině roku 2010.
Sledovací infrastruktura ftrace je v hlavní řadě teprve od 2.6.27 – méně než rok. Za tu dobu se ftrace dočkalo významného vývoje a získalo několik nových schopností. Nyní poskytuje mnoho vlastností, které jsou dodávány v mnohem těžkotonážnějších nástrojích, jako je SystemTap, společně s nějakými, které jsou pro ftrace unikátní. „Skutečné“ sledovací nástroje nicméně mají schopnosti, které ftrace nemá. Jedním z nejvýznamnějších omezení je chybějící dynamické sledování; ftrace může jednoduše sledovat volání funkcí nebo použít statické sledovací body umístěné do zdrojového kódu, ale nemůže za běhu přidávat své vlastní sledovací body. To by se nicméně mohlo změnit, pokud se patch pro sledovač událostí založený na ksondách od Masamiho Hiramatsu dostane do hlavní řady.
Mechanismus ksond [kprobe] je součástí jádra již dlouho; na LWN se na něj dívali již roku 2005. KSondy jsou samozřejmě dynamické sledovací body; patchováním kódu za běhu může jádro zaháčkovat jakýkoliv svůj vlastní kód na libovolném místě. Ksondy využívají k implementaci dynamického sledování nástroje jako SystemTap. U SystemTapu jsou nicméně tyto sondy vkládány zavedením zvláštního jaderného modulu, který je vygenerován za běhu – což je trochu zrádné rozhraní. Masamiho patch míří k tomu, aby vkládání dynamických sond změnil na něco, co se víc blíží operaci na příkazové řádce.
Patch vytváří v debugfs nový soubor /sys/kernel/debug/tracing/kprobe_events. Nová sonda se vytváří přidáním řádku do tohoto souboru; tato řádka má poněkud složitý formát:
p[:EVENT] SYMBOL[+offset|-offset]|MEMADDR [FETCHARGS] r[:EVENT] SYMBOL[+0] [FETCHARGS]
První varianta nastaví sondu s volitelným jménem EVENT (pokud není jméno dodáno, kód si nějaké vymyslí). Sonda bude umístěna na místo v daném SYMBOL posunuté o volitelný offset; pro umístění sondy lze také využít absolutní adresu (MEMADDR). FETCHARGS určuje, jaká data zjistit a odeslat, když se na sondu narazí; syntaxe umožňuje specifikovat různé datové typy včetně obsahu registrů, posunů [offset] na zásobníku, absolutních adres, jaderných symbolů, argumentů funkcí a dalších. Co kód v současnosti neumí, je sofistikovaněji formátovat data; ta přicházejí v přímém hexadecimálním formátu.
Druhá řádka uvedená výše vkládá „návratovou sondu“ [retprobe]. Návratové sondy reagují, když se daná funkce (která je specifikovaná SYMBOLem) vrací k volajícímu; lze jimi zachytit návratovou hodnotu funkce a adresu, na kterou se vrací.
V zaslání patche jsou příklady pár sond, které jsou vloženy do do_sys_open(); vloží se těmito příkazy:
echo p:myprobe do_sys_open a0 a1 a2 a3 > /sys/kernel/debug/tracing/kprobe_events echo r:myretprobe do_sys_open rv ra >> /sys/kernel/debug/tracing/kprobe_events
Jedna ze dvou vkládaných sond se jmenuje myprobe, reaguje při vstupu do do_sys_open() a vrací hodnoty čtyř argumentů, které jsou této funkci předány. Druhá, myretprobe, zareaguje při návratu z do_sys_open(), zachytí návratovou hodnotu a návratovou adresu.
Výstup z těchto sledovacích bodů lze získat čtením /sys/kernel/debug/tracing/trace:
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
<…>-1447 [001] 1038282.286885: do_sys_open+0x0/0xd6: 0xffffff9c 0x40413c 0x8000 0x1b6
<…>-1447 [001] 1038282.286915: sys_open+0x1b/0x1d <- do_sys_open: 0x3 0xffffffff81367a3a
Zde vidíme volání do_sys_open() se čtyřmi parametry: popisovačem adresáře (0xffffff9c), ukazatele na jméno souboru (0x40413c), příznaků (0x8000) a režimu (0xb16). Pro zvídavé – podivná hodnota popisovače souboru je kouzelná hodnota AT_FDCWD, která znamená, že hledání souboru má začít v současném pracovním adresáři. Také je zde řádka návratu (naznačená šipkou <-), která ukazuje, že se volání vrátilo do sys_open() a otevřelo popisovač souboru 3.
Tento patch také poskytuje mechanismus pro zapínání a vypínání jednotlivých sond, filtrování jejich výstupu a správu profilů zásahů sond.
Sledování vstupu a výstupu do/z funkce, které je ukázáno výše, je užitečná vlastnost, ale to již zvládne existující sledovač funkcí ve ftrace. Zjevná hodnota tohoto nového patche je možnost vkládat sledovací body na místa jiná, než je vstupní a výstupní bod funkce. To ale vede k zajímavé otázce, jak se uživateli podaří vložit sledovací bod na správné místo? Hádání posunu ze symbolů funkcí není nic jiného než cesta do potíží, obzvláště vzhledem k tomu, že umístění sledovacího bodu doprostřed instrukce jenom těžko povede k příjemným výsledkům.
Řešení této obavy je, jak se ukazuje, úkolem hlavní části kódu v Masamiho patchi. Vkládání sond je relativně jednoduché – kód, který to dělá, již v jádře je. Zajištění, že bude sonda umístěna na správné místo, ale vyžaduje přidání modulu pro dekódování instrukcí x86. Když je požadována sonda uvnitř funkce, zapojí se do práce dekodér instrukcí; začne na začátku funkce a dekóduje instrukce, dokud nenarazí na místo, kam má být vložena sonda. Pokud je sonda vkládána mezi instrukce, je všechno v pořádku; v opačném případě je umístění sondy zakázáno.
Skutečné vygenerování správného posunu je pravděpodobně úkolem pro software v uživatelském prostoru, který může projít ladící informace a mapovat čísla řádek na offsety. Nástroje jako například SystemTap nebo debugger. Ve skutečnosti lze uvážit, že by nástroje jako SystemTap mohly přejít na tento mechanismus, až bude začleněn; to by SystemTapu umožnilo sdílet většinu nízkoúrovňové sledovací instalatéřiny a přiblížit se k tomu, aby fungoval s nepatchovanými jádry.
To ale příliš předbíháme; nejprve je potřeba sledovací kód založený na ksondách začlenit. Proti tomu se nezdá být nějaká skutečná opozice – ale kód již tu nějakou dobu je a toto je jeho 13. revize. Hodnota vložení podpory pro dynamické sondy do jádra je nicméně evidentní; očekávejme, že se tato vlastnost dostane dovnitř.
Pozn. překl. – Parfait je druh dezertu.
Nedávno Roel Kluin začal zasílat patche, které opravují mnoho přetečení bufferu v jádře, některé z nich připisoval nástroji Parfait. To je nástroj pro statickou kontrolu zdrojového kódu, který vznikl v laboratořích firmy Sun v Austrálii. Projekt hlásil 54 přetečení bufferu v mailové konferenci linux-security začátkem července a Roel je od té doby prochází a opravuje.
Přetečení bufferu je nejlepší považovat za potenciální bezpečnostní slabiny, i když může být obtížné nebo nemožné je zneužít – u mnoha takových chyb se ale myslelo, že není možné je zneužít, načež se to někomu podařilo; opatrnost je tedy zjevně na místě. Kompletní seznam byl zaslán na neveřejný alias lidí zabývajících se bezpečností jádra a následně předán Roelovi a Andrewu Mortonovi. Roel nyní zasílá patche do linux-kernel a také do mailové konference netdev, aby chyby na tomto seznamu opravil. Mnoho z těchto oprav už bylo převzato správci subsystémů a některé se dostaly do hlavní řady.
Nástroj sám o sobě je relativně nový, prvně byl předveden jako alfa verze loni v říjnu; používá vícevrstvý přístup pomocí „sboru“ technik statické analýzy. Proto to jméno. Jedním z cílů je od začátku vytvořit něco, co by bylo schopné analyzovat obrovskou základnu kódu – například jádro Open Solarisu nebo Linuxu – řádově během minut a ne hodin a dnů, které potřebují jiné nástroje.
Podle části pojednání [PDF], které bylo prezentováno na Kernel Conference Australia v polovině července, vývojáři Parfait ohlásili, že otestování 5,7 milionů řádek kódu v jádře 2.6.29 a vyhledávání přetečení bufferu trvalo 13 minut. Časy pro OpenSolaris a OpenBSD byly podobné, když se uváží úměra s počtem testovaných řádek.
Nepřekvapí, že u všech třech jader byla většina přetečení bufferu nalezena v kódu ovladačů. U 2.6.29 Parfait nalezl 12 přetečení bufferu ve vnitřní části Linuxu [Linux core] a 85 v ovladačích (které představují 71 % kódové základny). Některé z nich byly hlášeny chybně, ale pojednání neříká, kolik. Vzhledem k tomu, že do linux-security bylo zasláno 54 hlášení, zdálo by se, že chybných hlášení byla skoro polovina.
Roel poskytl příklad výstupu z Parfaitu
Bug type: Buffer overflow
File: /usr/src/linux-2.6.29/security/smack/smackfs.c
Line: 777
Function: smk_write_netlbladdr
Code snippet:
0772: if (count < SMK_NETLBLADDRMIN || count > SMK_NETLBLADDRMAX)
0773: return -EINVAL;
0774: if (copy_from_user(data, buf, count) != 0)
0775: return -EFAULT;
0776:
0777: data[count] = '\0';
0778:
0779: rc = sscanf(data, "%hhd.%hhd.%hhd.%hhd/%d %s",
0780: &host[0], &host[1], &host[2], &host[3], &m, smack);
0781: if (rc != 6) {
0782: rc = sscanf(data, "%hhd.%hhd.%hhd.%hhd %s",
Parfait report:
Error: Buffer overflow at
/usr/src/linux-2.6.29/security/smack/smackfs.c:777 in function
'smk_write_netlbladdr' [Symbolic analysis]
In array dereference of data[count] with index 'count'
Array size is 42 bytes, count >= 9 and count <= 42
Comments:
Off-by-one when adding the trailing null on line 777 – data is
declared with size
SMK_NETLBLADDRMAX, and count is allowed to equal SMK_NETLBLADDRMAX
Výpis ukazuje přetečení bufferu, které již bylo v jádře opraveno před hlášením od Parfait. Pojednání také popisuje nástroj s GUI, které shromáždí kód a deklarace, kvůli kterým si Parfait myslí, že existuje problém; to vývojářům může pomoci určit, jestli problém opravdu existuje, nebo ne.
V současnosti není Parfait k dispozici nikomu mimo Sun, ale plánuje se vydání binárky. Podle hlavní vývojářky Cristiny Cifuentes by měla být na webu k dispozici během měsíce nebo dvou. Odhaduji, že za námi bude konec srpna (abych byla optimistická), než bude binárka vydána. Pesimističtější odhad je konec září. Vydání bude k dispozici pro použití na nekomerční bázi. Sun zvažuje vydání jako open source, ale ještě nebylo rozhodnuto.
V interview na webové stránce Sun Labs Cristina poskytuje širší pohled na to, co je cílem Parfait – více než vyhledávání přetečení bufferu:
V mnoha ohledech je Parfait podobný analytickému nástroji Coverity, který byl používán jak na jádro, tak na další svobodný software. V obou případech, alespoň nyní, může analýzu udělat jenom firma, která nástroj vlastní, nebo ti, kdo si v případě Coverity pořídili licenci. Nástroj pro analýzu jako svobodný software, který by dělal tyto testy – a nezávisel na dobré vůli různých firem – by byl skutečným přínosem. Se štěstím možná Parfait jednoho dne tuto roli naplní.
Tyto nástroje pro analýzu zdrojových kódů rozhodně nalézají skutečné chyby, nicméně jsou zde důkazy, že hlášení o chybách vycházející z těchto hledání se nevyužívají tak, jak by to bylo možné. Vyhledávač Coverity našel problém s dereferencováním NULLového ukazatele v tun.c dlouho předtím, než byl problém v jádře opraven, ale hlášení si buď nikdo nevšiml, nebo (chybně, jak se ukázalo) ho nepovažoval za vážný problém. Více analýzy zdrojového kódu – tedy pokud není zaneseno příliš mnoha chybnými hlášeními – může být jenom dobré, ale nalezené problémy musí někdo řešit, jinak tato snaha nikam nepovede. Také bylo by moc hezké mít svobodné verze těchto nástrojů.
Alane, ty jsi skutečný kouzelník Vrstva tty je jedním z velmi mála kousků jádra, který mě děsí :-)
-- Ingo Molnár, červenec 2007
V jádře jsou temné oblasti, kam se odváží vkročit jenom nejodvážnější vývojáři. Místa, kde je kód zamotaný, požadavky složité a všechno závisí na pradávném kódu, který během let viděl jenom málo změn, protože i ti nejkvalifikovanější vývojáři mají obavy z následků. Pravděpodobně žádná jiná část kódu není temnější a děsivější než kód sériového terminálu (TTY). V nedávné době se tomuto kódu dostávalo tolik potřebných aktualizací, ale nyní se zdá, že neshoda v komunitě tuto práci zastaví a TTY přehodí zpět do sloupečku „bez správce“ – právě v době, kdy má tento kód v jádře 2.6.31-rc regrese.
Na první pohled se vrstva TTY nezdá být tak složitá. Je to konec konců jednoduché znakové rozhraní, které má za úkol přenášet znakově orientované toky dat mezi dvěma dobře definovanými body. Problém je ale složitější, než vypadá. Mnoho z kódu TTY má kořeny v pradávném hardwaru implementujícím standard RS-232 – jeden z nejvolnějších a nejvíc proměnlivých standardů, které existují. Ovladače TTY také musí monitorovat proud dat a vytahovat z něj informace; tato povinnost může zahrnovat řízení toku ^S/^Q, kontrolu parity a detekci řídících znaků. Řídící znaky se mohou změnit na informace mimo přenosové pásmo, které musí být sděleny uživatelskému prostoru; ^D může být koncem souboru, když aplikace čte z odpovídajícího bodu v datovém proudu, zatímco jiné znaky se mapují na signály. Kód TTY se tedy musí potýkat i se složitým doručováním signálů – což nikdy není cesta k jednoduché kódové základně. Musí být zvládáno opakování dat odesílateli – s možností je během toho měnit. S přidáním pseudoterminálů (PTY) se kód TTY stal také určitým druhem mechanismu pro meziprocesovou komunikaci s tím, že divná sémantika TTY byla zachována. TTY kód také potřebuje podporovat síťové protokoly, jako je PPP, bez vytváření úzkých hrdel pro výkonnost.
Ve shrnutí se jedná o komplikovanou záležitost. Je to také záležitost, která zajímá jenom relativně málo vývojářů. Na začátku souboru drivers/char/tty_io.c se stále dočteme „Copyright (C) 1991, 1992, Linus Torvalds“. Velká část kódu stále závisí na velkém jaderném zámku. Je potřeba najít deadlocky a souběhy. Téměř nikdo se toho nechce dotknout, ale většinou to funguje.
Nedávno se nicméně objevil energický správce TTY: Alan Cox. Bylo skoro možné slyšet, jak si lidé na síti oddechli, když k tomu došlo; pokud někdo měl na to vyčistit tenhle kousek Augiášova chléva, rozhodně to byl Alan, který měl jak technické schopnosti, tak pozornost vzhledem k detailům, která je zapotřebí, když se chceme vyhnout rozbití věcí. Během minulého roku bylo jasné, že opravování TTY kódu napínalo i Alanovy schopnosti; postup byl pomalý a zjevně pracný. Také ale došlo k úspěchu, kód TTY se dostával do lepšího stavu a stále sloužil jako funkční subsystém.
Tak tomu bylo do 2.6.31, kde kombinace několika významných změn a několika ladění na poslední chvíli vedla k regresím. Uživatelé začali hlásit, že aplikace kdesu přestala fungovat. Překládací režim emacsu začal ztrácet výstup. A tak dál. Ukázalo se, že šlo o oddělené chyby, z nichž ne všechny byly v tty vrstvě:
Problém s kdesu je pravděpodobně chybou ve KDE; aplikace čte příliš mnoho dat a pak se diví, proč další čtení neobsahuje, co chtěla. Kód fungoval se starším kódem TTY, ale v 2.6.31 přestal. Pravděpodobně není možné to opravit, aniž by se do jádra přidal kód pro udržování kompatibility s podivnou dávnou chybou – což je něco, čehož je v TTY vrstvě už teď moc.
Problém v emacsu je jiný. V tomto případě proces překladu dokončí svou práci (zapíše svůj poslední výstup na PTY) a ukončí se. Emacs se poté pokusí poslední výstup číst, ale dostane chybu při čtení, protože od procesu překladu, který se ukončil, dostane signál SIGCHLD. Toto selhání je neočekávané a způsobí, že emacs data zahodí. Emacs v podstatě očekává, že v době, kdy proces překladu dokončí své close() na popisovači PTY, budou data na tomto popisovači již přenesena na druhý konec a budou k dispozici pro čtení. Změny v 2.6.31 tento předpoklad narušily.
Druhý problém vychází ze složité povahy zpracování dat v TTY. Není to jenom sériový proud dat; uprostřed je také zpracování řízení linky [line discipline]. Když je volání close() dovoleno se dokončit, jsou v 2.6.31 data uložena ve frontě pro zpracování vrstvou řízení linky, ale není nijak zaručeno, že kód řízení linky v té době již proběhl a data předal na druhou stranu. Signál SIGCHLD tedy může data předběhnout a dorazit první.
Alan si myslí, že toto chování je rozumné; vyhovuje aplikovatelným standardům a lze ho implementovat relativně přímočaře. Kdyby mělo close() v PTY blokovat, dokud druhý konec neobdrží data, možná bude emacs fungovat lépe, ale také se riskuje deadlock, pokud obě strany zapíší data a uzavřou své popisovače souboru zároveň. I tak ale Alan zaslal ve „všech špatných směrech elegantní“ patch, který problém opravil, ale také dal jasně najevo, že podle něj je chyba v emacsu a skutečná oprava má přijít tam.
Linus začlenil verzi patche, ale nebyl z toho šťastný. Věří, že předpoklady emacsu jsou správné a rád by viděl lepší opravu, která poskytuje jasné a deterministické řazení událostí. Svou nespokojenost dal najevo:
V tomto okamžiku byl ve vyjádření nespokojenosti na řadě Alan. A zpátky se nedržel:
Tato zpráva obsahovala patch, který odstranil Alana jako správce TTY vrstvy ze seznamu správců.
Tak věci v době psaní tohoto článku stojí. Kód TTY opět není spravován, slibné přepracování se zastavilo na půl cesty a osoba, která je nejkvalifikovanější pro opravování problémů, rozhodila rukama a odešla z budovy (i když je třeba poznamenat, že se účastní diskuze o tom, jak by příští správce, ať už to bude kdokoliv, mohl věci opravit). Vývoj jádra bude pokračovat, ale vývoj v této oblasti půjde poněkud pomaleji; TTY vrstva si připsala další oběť.
mam pocit, že by se Linus měl občas krotit... Je mi jasný, že je blbý nutit userspace vývojáře opravovat svuj SW, když to jde v jádře obejít, ale pokud TTY bylo až tak rozbitý, tak se nedá nic dělat, ne? Nebo tomu někdo rozumí a mohl by mi to líp vysvětlit?
politika je uz mnoho let takova, ze binarka prelozena na treba jadru 0.1.128 pojede i na poslednim jadru. Toto tento koncept narusuje. A tato politika nas take odlisuje od spolecnosti jako treba M$
Myslim, ze binarky vyuzivajici chyb jadra by do teto politiky zahrnuty byt nemely. Prijde mi, ze by tak Linux musel podporovat i stare rootkity.
a co kdyz pujde o uzitecny program ktery na svete nema obdoby a jehoz tvurce zahynul/firma zkrachovala? Kdo rozhodne ktery program je dobre dal podporovat a ktery ne? Typicky pripad ruznych mericich softu...
Tak napriklad commit d20894a23708c2af75966534f8e4dedb46d48db2 tohle porusuje. Mohou existovat binarky, ktere na jadru obsahujicim tenhle commit proste nebudou fungovat, i kdyz predtim fungovaly.
27.8.2009 19:43
hajma | skóre: 27
| blog: hajma
| Říčany
moje zkusenosti jsou spis opacne
Priznam se, ze mam ext3 na 8GB prstu Kingston s petiletou zarukou (snad neco vydrzi). Nainstaloval jsem si na to Ubuntu a vyuzivam to hlavne na notesu, kde jinak je z ruznych duvodu Windows. Nekdy ho ale pripojim i desktopu s Linuxem, abych si pretahnul nejaky dokument, a pak by se nejaka takova volba jako zminovane uid hodila.
Trochu me mrzi, jak je ta flashka pomala. Proto /tmp a /var/log mam v ramdisku. S tim se pak uz da i pracovat. Ale stejne, jake distro ci nastaveni by bylo nejlepsi pro takovyhle system (tedy na flashce a notesu), aby to trochu bezelo a zaroven nezralo moc elektriky?
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
27.8.2009 11:58
27.8.2009 12:01