10.1.2005 01:57
Josef Kufner | skóre: 70
Rozbalit Rozbalit vše swsusp2
Portál AbcLinuxu, 12. května 2025 16:42
Dostane se souborový systém FUSE do oficiálního jádra? Stav softwarového uspání [Software Suspend]. Vyřazování nefunkčních a duplicitních ovladačů. Návrh na uživatelskou knihovnu pro architekturovou přenositelnost.
Do konference přišlo celkem 2130 emailů, nejvíce jich poslali Nigel Cunningham, Pavel Machek a Adrian Bunk.
15. lis - 3. pro
Miklos Szeredi se zeptal, jestli by mohl být userspace [v uživatelském prostoru] souborový systém FUSE přidán do hlavních zdrojů jádra. Ale Linus Torvalds odpověděl:
Abych pravdu řekl, myslím, že je příliš zaneřáděný.
FUSE by se mi líbil daleko více, kdyby dělal pouze to obecné čtení keše stránek. Ale vypadá to, že toho dělá o hodně víc - většina z toho nefunguje.
Jinými slovy, myslím, že je od základu chybné nemít speciální "fuse_file_read". Pokud to není jen "generic_file_read()" (možná dohromady s revalidačním zpětným voláním, ale i to je na debatu), tak s tím podle mě něco není v pořádku.
Kód vypadá, jakoby se na něm začalo, ještě než byla keš stránek úplně dokončená. A nikdo ho nikdy nevyčistil, aby využíval plnou sílu VFS - nebo se ten někdo z nějakého podezřelého důvodu rozhodl, že chce podporovat bláznivé filesystémy.
Kdyby někdo společně s odstraněním 2.4 kódu poslal skutečně pročištěný patch, možná bych to zvážil znovu.
Miklos odpověděl, že poslední patch už tyhle otázky řeší, a 2.4 kód už je také pryč. Potvrdil, že v patchi je trochu nadbytečného kódu, ale ten byl začleněn kvůli výkonnosti, ne kvůli špatné správě.
Na patch se několik lidí vrhlo s komentáři a kritikou. Především Greg KH pomohl objasnit některé věci okolo /dev, /proc a SysFS.
Na jiném místě se Pavel Machek zeptal, jaké výhody má FUSE oproti CODA. Miklos řekl, že jsou vlastně velmi rozdílné; a pustili se s Pavlem do porovnávání back-endů. Linus chvíli diskuzi sledoval z povzdálí a občas připojil pár zajímavých komentářů o obecnějších věcech. Jednou o postupu posílání patchů:
Z pohledu začleňování nového kódu je lepší jednoduchost. I pokud jednoho dne budete opravdu moc chtít použít nějaké exotické funkce jako "přímý IO" a zapisovatelná mapování, je lepší se na to dívat takhle: je jednodušší začlenit něco, kde nejsou žádné nejisté záležitosti. Ty mohou být doplněny později, místo abyste se snažili to vše začlenit hned na začátku.
Já jsem potvora. Zeptejte se kohokoliv. Přijmu naprosto stejný patch, který jsem dříve odmítl, stačí, když to provedete správně. Jsem přesvědčený, že někteří lidi to dělají jen kvůli tomu pobavení ("Hele, už to udělal zase. To je ale trouba!").
24. lis - 3. pro
Nigel Cunningham poslal 51 samostatných patchů, které měly řádně začlenit Suspend 2. Pavel Machek s ním diskutoval o několika z nich. Vypadalo to, že některé části Nigelova kódu zcela odstraňují kód swsusp (Software Suspend), na kterém pracoval Pavel. Christoph Hellwig mu připomněl: Nezapomeň, že jak swsusp, tak swsusp2 by měly exportovat stejné rozhraní. Pokud možno to staré, ale kdyby ti to hrozně moc nevyhovovalo, pošli nejdříve patch, který by starý kód přehodil na nové rozhraní.
Po většinu času probíhala diskuze o tomto ožehavém tématu poklidně. Soudě podle reakcí většiny lidí, kteří se zabývají touto oblastí (včetně Nigelových), je nepravděpodobné, že by byly všechny Nigelovy patche přijaty beze změn. Hlavně Christoph dával najevo potřebu výrazných změn, aby byly vyřešeny problémy, které - jak říkal - existují v kódu již dlouhou dobu (v jednu chvíli Nigela obvinil, že znovu beze změn posílá již jednou odmítnutý kód -- a Nigel potvrdil, že v některých případech je to pravda). Dost lidí mělo hodně zajímavých komentářů, ale vypadá to, že nakonec bude Nigelova práce přeci jen přijata. Dokonce i Pavel souhlasil s tím, aby Suspend2 nahradilo swsusp, které napsal on. Pavel i Christoph navrhli, že nejlepším způsobem, jak patche posílat, by bylo postupně swsusp přeměnit na Suspend2. Ale Nigel oponoval:
Tohle nedělám záměrně. Suspend2 není jen balík postupných změn swsusp. Bylo to navrženo úplně od začátku a já bych musel swsusp rozebrat na kousky a pak zpátky složit, aby to dělalo totéž. Ve stejné zprávě ještě dodal: Nechme Pavla a ostatní dospět k tomu, kdy řeknou "OK, jsme spokojeni s tím, že suspend2 umí všechno, co umí swsusp a ještě více a dělá to lépe." Pak můžeme swsusp odstranit. O takovém plánu jsme s Pavlem a Andrewem mluvili už dávno. Ostatní ale trvali na postupné přeměně -- i když Pavel poznamenal: OK, teď bych chápal, kdyby sis dal moji fotku jako texturu na nějakou příšeru z Dooma 3 a pak mě rozstřílel... Suspend2 dalo hodně práce, ale stejně tak swsusp1...
2. pro
Jeff Garzik napsal:
Chtěl bych eliminovat několik příšerně nefunkčních/duplicitních ovladačů. Protože 2.6 je pořád v pohybu, chtěl bych dát "velkou blikající ceduli" o tom, že ty ovladače brzy zmizí - radši než je oddělat rovnou a pak poslouchat ten řev.
Ovladač IPhase nefunguje a je opuštěný. Xirtulip nefunguje, je duplicitní a ještě opuštěný. To jsou dva hlavní kandidáti na můj preferovaný způsob řešení takových případů: CONFIG_DEPRECATED.
Jim Nelson navrhl: Přidej si, prosím, na seznam digiboard - duplicitní+opuštěný.
4. pro - 6. pro
Paul Mackerras napsal:
Některé naše jaderné hlavičkové soubory implementují obecně užitečné abstrakce na všech podporovaných architekturách. Rád bych vytvořil knihovnu pro "architekturovou přenositelnost" založenou na hlavičkách jádra, ale coby samostatný projekt. Určený pro použití v uživatelském prostoru.
Chtěl bych použít následující hlavičky:
Je ještě pár dalších, které by se mohly hodit: cache.h, checksum.h, io.h, xor.h.
Je jasné, že bych to mohl udělat pod GPL. Jenže si myslím, že by bylo užitečnější mít tu knihovnu licencovanou LGPL. To však vyžaduje získat svolení autorů souborů v jádře, nebo je všechny od začátku přepsat.
Linusi (a další držitelé copyrightu v jádře) - byl bys pro tento účel ochotný přelicencovat na LGPL ty z těch zmíněných souborů, ke kterým držíš copyright?
Hledám dobrovolníky, kteří by pomohli s portováním a testováním na různých architekturách. Můžu udělat x86, ppc a ppc64 a znám assembler na sparc{,64} a m68k, ale se zbytkem bych potřeboval pomoct.
Doufám, že distribuce by to mohly použít k náhradě některých hlavičkových souborů v /usr/include/asm, a odradit tak aplikace od nutkání začleňovat hlavičky jádra.
Několika lidem se ten nápad moc zamlouval. Robert Love dal svolení k přelicencování svých příspěvků v jádře a řekl:
Myslím, že je to úžasný nápad. Být tebou, tak zkontroluji, jestli by se to nekrylo s některými existujícími glibc knihovnami. Například předpokládám, že glibc implementuje alespoň některé atomické operace (ale zároveň mám za to, že mít k dispozici plnou sadu atomických operací by bylo užitečné).
H. Peter Anvin se také připojil, i když on by dal přednost BSD licenci, aby mohl výsledek přidat ke klibc.
V originálu Kernel Traffic 289 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.