Jdou sehnat v CR za rozumnou cenu?
Portál AbcLinuxu, 12. května 2025 13:49
Ovladač pro softwarový RAID Intel (iswraid) půjde do 2.4. HOWTO pro přístup ke zdrojovým kódům jádra přes Subversion. Snížení velikosti jádra; Linusův hlavní systém už není x86. Ovladač pro sériové dotykové obrazovky Elo. Dokumentace k CPU scheduleru v 2.6.8.1.
28. led - 11. úno
Martins Krikis napsal:
Verze 0.1.5 ovladače pro softwarový RAID Intel (iswraid) je nyní k dispozici pro jádra řady 2.4 zde: /2.4.29-iswraid.patch.gz
Je to ataraid "subovladač", ale k nacházení RAID disků používá SCSI subsystém. Závisí na knihovně libata, především na ovladačích ata_piix a ahci, které u čipsetů ICH5/ICH6/ICH7 zajišťují možnosti Serial ATA. Další informace jsou na stránkách projektu: http://iswraid.sourceforge.net/.
Dokumentace k ovladači je v souboru Documentation/iswraid.txt, který je součástí patche. Licence GPL.
Zvažte prosím začlenění tohoto ovladače do jádra 2.4.
Jeffu Garzikovi se patch líbil, ale Arjan van de Ven řekl: Já to považuji za novou funkci a nové funkce nepovažuji za vhodné k začleňování do řady 2.4, která je již pouze udržovaná. Bartlomiej Zolnierkiewicz s Arjanem souhlasil, ale Jeff odpověděl:
To je docela otrava pro uživatele nového hardware. Typickou stížností bývá, že nemohou sdílet data mezi Windows a Linuxem v případech, kdy "prostě použijte dm" není řešením.
Bez mapovače zařízení (další nová funkce), který by umožnil použití dmraid, jsou tihle uživatelé prostě nahraní.
Já to nepovažuji za novou, ale za chybějící funkci, protože bez ní nemohou uživatelé přistupovat k datům v RAID.
Christoph Hellwig mínil, že tihle lidé by měli upgradovat na 2.6 a Arjan poukázal na to, že Jeffovy připomínky platí pro jakýkoliv nový hardware. Diskuze pokračovala, aniž by se něco dohodlo, až v jednu chvíli se vyjádřil Marcelo Tosatti:
Osobně jsem za současné situace proti začleňování jakýchkoliv nových ovladačů do 2.4 a upřímně vítám všechny argumenty proti iswraid. Ale nevadí mi, protože to vypadá jako dobrá výjimka, která - jak říká Jeff - umožňuje uživatelům ICH5/6 přistupovat ke svým RAID oddílům.
Kromě toho to je ovladač, který stejně zanikne spolu s 2.4, takže nezavádíme žádný potenciální problém s kompatibilitou.
Rozumím tedy argumentu pro začlenění do stromu: elegantně se to dělá pomocí dmraid.
Ale neberu to jako argument proti začlenění do odumírající stromu 2.4, jehož účelem je sloužit stávajícím uživatelům.
Nemáte pravdu, když říkáte "ale když může být začleněn tento ovladač, pak to vypadá, jako by mohl být každý ovladač z 2.6 přijat do 2.4".
Je to tedy na Jeffovi a ten s tím, zdá se, souhlasí...
2. úno - 11. úno
Stelian Pop napsal:
Poslední dobou jsem si hrál se Subversion a používal jsem to ke správě zdrojových kódů jádra pomocí bk2cvs od Larry McVoye a konverzního skriptu bkcvs2svn od Bena Collinse.
Protože je na webu málo informací o tom, jak založit SVN repozitář a používat ho ke sledování posledních verzí jaderného stromu, sepsal jsem krátké HOWTO (modelované podle BK Kernel HOWTO) pro případ, že by to bylo užitečné i pro další lidi.
Budu rád za vaše komentáře (ale nezačínejme nový BK flamewar nebo další kolo shazování SVN). Bude-li o to dostatečný zájem, pošlu patch, který to začlení do adresáře Documentation/.
Dal jsem to také na své stránky (společně s potřebnými skripty): http://popies.net/svn-kernel/
Bylo to velmi kladně přijato a Larry McVoy rychle reagoval na dotazy a požadavky ohledně BitKeeperu; přesto se diskuze brzy zvrhla na hádku mezi vývojáři jádra, kteří chtěli vědět o zpracování patchů více než je BitMover ochoten prozradit, a Larrym, který se snaží zabránit vytvoření konkurenčního software a ochránit to, co považuje za své intelektuální vlastnictví.
6. úno - 11. úno
Linus Torvalds napsal:
Díval jsem se na kód, který generujeme, a všiml jsem si, že máme takovou podivnou situaci, kdy x86 makra "get_user()" kvůli ověřování adresy generují out-of-line [ne "inline", tedy ne vkládaný] kód, ale makra "put_user()" to nedělají - všechno dělají inline.
Také jsem si všiml, že (pravděpodobně díky tomu) naše "put_user()" na starších i386 strojích neprovádí plně to zázračně manuální následování stránek [full magic manual page-following]. Což znamená, že copy-on-write nemusí kvůli nefunkčnímu stránkovacímu HW na původním 386 jádře správně fungovat.
To druhé jsem neopravil, ale aspoň je to teď možné, když jsou věci out-of-line. A změnit "put_user()" na out-of-line se zdálo docela proveditelné.
Můj hlavní stroj už není x86, takže ten patch je naprosto netestovaný. Zkompiloval jsem jej, abych viděl, jestli to vypadá rozumně, ale to moc neznamená. Pokud jsem zapomněl na nějaký registr nebo zmrvil něco jiného, bude výsledkem totálně nefunkční jádro. Ale říkal jsem si, že někdo jiný by mohl mít zájem se podívat, jestli to (a) funguje, (b) dokonce zmenšuje jádro a (c) umožní dělat, co je třeba s ohledem na ty nechutnosti s následováním tabulky stránek [page table following] (stará i386 jádra teď nejsou moc běžná, takže je to možná lidem jedno).
Ingo Molnar potvrdil, že Linusův patch bootuje bez problému a docela výrazně zmenší velikost jádra. Linus odpověděl: Fajn. Přikládám trošku čerstvější verzi. A dodal: Nebudu to dávat do 2.6.11, protože se bojím, jak by reagovaly kompilátory, ale čím více lidí to otestuje, tím lépe. Pavel Machek navrhl začlenění patche do -mm stromu Andrew Mortona. Linus se Andrewa zeptal, jestli by s tím souhlasil, a Andrew odpověděl: Vezmu patch od kohokoliv ;).. A Linus řekl: Takhle nepřežiješ. Jakmile si jednou uděláš jméno jako snadno přemluvitelný, bude se ti říkat Andrew "všem dá" Morton.
8. úno - 10. úno
Vojtěch Pavlík řekl:
Napsal jsem ovladač pro pravděpodobně nejběžnější druh dotykových obrazovek - sériové Elo touchscreeny.
Ovladač by si měl poradit se všemi generacemi sériových Elo, protože zvládá 10bajtový, 6bajtový, 4bajtový a 3bajtový protokol.
Dmitryi Torokhovi se patch líbil, i když přiznal, že nemá hardware na testování. Paulo Marques projevil velký zájem o podporu dotykových obrazovek: Pracuji pro firmu, která vyvíjí software pro restaurace, a linuxový port naší aplikace už 2 roky běží v několika restauracích na naší vlastní linuxové distribuci. Bylo potřeba podporovat několik druhů dotykových obrazovek, což jsme dělali přímo v aplikaci sledováním sériového portu a zpracováváním dat. Kdyby se tohle dostalo do jádra, musela by aplikace pouze číst vstupní zařízení a zpracovávat události bez ohledu na použitou obrazovku. To bylo skvělé zlepšení. Vojtěch byl takovým zájmem nadšený. O několik zpráv dále Paulo Marques navrhl:
Někdy si při pohledu na kód pro jednotlivé značky říkám, že bychom měli udělat obecný ovladač pro všechny dotykové obrazovky.
Zní to rozumně?
Ale Vojtěch řekl ne. Objem ušetřeného kódu by nevyvážil zmatky, které by to způsobilo. I tak se však rozpoutala živá diskuze o různých technických aspektech podpory dotykových obrazovek.
13. úno
Josh Aas řekl:
Napsal jsem úvod k implementaci CPU scheduleru [plánovač] v Linuxu 2.6.8.1. Dokument by měl být srozumitelnější než čtení kódu. Stáhnout jej můžete v PDF nebo LyX odsud:
http://josh.trancesoftware.com/linux/
Tento dokument nebude nikdy "hotový". Rád bych jej aktualizoval podle nových verzí jádra, budu-li mít čas. Máte-li připomínky, komentáře nebo opravy, pošlete mi je, prosím. Zvláště technické opravy jsou vítány. Doufám, že bude dokument co nejpřesnější a co nejužitečnější a bude pro další lidi inspirací k zájmu o linuxový scheduler.
Můj zaměstnavatel, SGI, mě o napsání tohoto dokumentu nepožádal. Vznikl jako součást školního projektu minulý semestr. I když SGI vlastní k dokumentu copyright, umožnili mi jej vydat s licencí GNU FDL.
V originálu Kernel Traffic 299 vyšla navíc ještě tato témata:
Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
11.3.2005 12:22