Portál AbcLinuxu, 8. května 2025 13:41
Situace kolem IDE-SCSI. Maximální velikost oddílů v 2.4 a 2.5. Stav podpory e-Galax USB dotykové obrazovky v 2.4. Aktualizace experimentálních síťových ovladačů. Několik oprav chyb v ACPI pro 2.6. Nová verze ovladače forcedeth.
Do konference přišlo celkem 1076 emailů, nejvíce jich poslali Prakash K. Cheemplavam, Linus Torvalds a Jens Axboe.
3. lis - 17. lis
Prakash K. Cheemplavam hlásil: Používám k3b 0.10.1 a ať vyberu pro pálení v DAO režimu cdrdao nebo cdrecord, vzniknou neidentické kopie, zatímco v TAO (alespoň na mé 10x CD-RW) se kopie zdaří. Později dodal, že data ve skutečnosti nejsou poškozena, ale v DAO režimu zkrácena: Když načtu image v CD-RW mechanice, ke konci chybí přibližně 5 kB (vždy stejné množství). Podivné je, že když ten disk načtu v DVD-ROM, tak je image kompletní. O několik zpráv dále objasnil: Data jsou na disku, protože moje DVD-ROM dokáže obnovit kompletní image (md5sum souhlasí), ale CD-RW to nedokáže.
Bill Davidsen odpověděl: S ide-scsi je v 2.6 problém, ale místo opravy někdo přišel s patchem pro cdrecord, který tomu programu umožňuje pracovat, a dokonce možná fungovat lépe. Protože se zdá, že ten problém s ide-scsi u dalších aplikací přetrvává, budeš to pravděpodobně muset řešit přepínačem -pad pro cdrecord (pro TAO je to myslím standardní) nebo používáním ovladače ide-cd.
A Linus Torvalds odpověděl:
Chyba.
Ten "někdo" měl silný pocit, že ide-scsi není jen nehezké, ale přímo špatné, a že syntaxe a použití cdrecordu jsou úplně stupidní.
Ten někdo jsem byl já.
ide-scsi nikdy pořádně nefungovalo. Neměli byste to používat a co víc, nikdy ani nebyl pořádný důvod pro jeho existenci. Ale kvůli kvůli špatnému rozhraní chtěl cdrecord přistupovat pouze k SCSI zařízením. Ergo, hloupá emulační vrstva, která vůbec nestála za to.
Fakt, že se nikdo neobtěžoval ide-scsi tak dlouho opravit, se zdá být důsledkem toho, že to nikdo nechce opravit.
Takže to nepoužívejte. A nebo, pokud to používáte, pošlete mi opravy.
John Bradford napsal:
Hmmm, ale ide-scsi se dnes používá pro mnohem víc věcí než jen vypalovačky. Alan v dubnu zmiňoval "bláznivá" SATA zařízení.
(Ne, že bych chtěl naznačovat, že by to bylo zrovna chytré řešit přístup k tiskárně připojené přes SATA pomocí vydávání jí za SCSI zařízení, ale není mi jasné, jak by mohlo být ide-scsi v současné době úspěšně odstraněno 
).
A Bill odpověděl: A já nevidím žádný prospěch, který by z toho plynul. Pokud někdo nechce napsat nové verze veškerého SCSI softwaru, který se používá, bude to znamenat ztrátu mnoha funkcí. Z dlouhodobého hlediska by možná bylo lepší prostě opravit nebo přepsat ide-scsi a přestat používat IDE rozhraní, protože výrobci disků určitě nepřestanou vyrábět SCSI a je potřeba ho podporovat tak jako tak. Hádám, že Doug Gilbert teď dělá jiné věci, protože bych od něj čekal alespoň jeho názor 
. Také řekl: Zmiňoval jsem IDE pásky a ZIP mechaniky. Linus neříká, co potom s nimi.
Na což Linus odpověděl:
Věc se má tak, že non-ide-scsi rozhraní by opravdu měla fungovat. SG_IO ("pošli SCSI příkaz") prostě funguje.
Nicméně, v současnosti ty příkazy využívá pouze CD-ROM ovladač. Proč? Protože nikdo se zjevně nezajímal o ty teoretické IDE pásky a ZIP mechaniky.
Jinými slovy, zdá se, že "existují" ve stejném smyslu jako "existují" uživatelé SoundBlaster CD-ROM. Teoreticky ano, ale ve skutečnosti jsou zjevně užitečné právě pro teoretické dohadování.
Podpora SCSI příkazů není složitá: přidáš
ret = scsi_cmd_ioctl(dev, cmd, arg);
do své ioctl rutiny. Samozřejmě, vzhledem k tomu, že to vypadá jako by nikoho nezajímalo nic než vypalování CD, tak to ani není testované pro nic jiného.
Bill suše odpověděl:
Předpokládám, že když ani ty ani správce IDE nějaké zařízení nepoužíváte, tak nebude v budoucnu podporované? Na ZIP mechanikách a ATAPI páskách není nic teoretického. Můžeš si je objednat nebo koupit na každém počítačovém veletrhu. A ide-scsi z 2.4 je podporuje bezvadně nebo aspoň použitelně, což je pravděpodobně důvod toho, že si nikdo nestěžoval.
Uznávám, že nechápu, proč 2.6 podporuje síťové karty a základní desky, které se nevyrábí už pět let, a pak úmyslně přestane podporovat zařízení, která fungovala a jsou dnes dostupná v počítačových obchodech.
Linus řekl:
Ta jiná zařízení mají lidi, kteří je se o ně STARAJÍ!
Co je na tom tak těžkého k pochopení? Brečíš na špatném hrobě.
Znovu, říkám ti to ještě jednou:
Už to chápeš?
Takže se ozvi až najdeš někoho, komu záleží na těch zařízeních, o nichž tvrdíš, že existují, natolik, aby s tím něco udělal.
Bill trval na tom, že je mnoho uživatelů, kteří ten hardware používají. Dohadovali se Linusem tam a zpět. Bill říkal, že uživatelů je mnoho a Linus, že někdo musí poslat patche, aby byl ten hardware podporovaný. Nakonec Linus zařval:
NIKDO MI NEPOSÍLÁ PATCHE.
Které části z "open source" nerozumíš?
SATA zařízení fungují dobře. Pracuje pro ně celá SCSI infrastruktura. Budou "prostě fungovat", ačkoliv pevně doufám, že je budeme moci později přesunout do vrstvy blokových zařízení, aby fungovaly efektivněji.
Co se týče těch tvých zařízení, která chtějí ide-scsi, pošli patche do konference a možná je někdo otestuje. Já je testovat nemohu.
Prostě chci říct, že BREČÍŠ NA ŠPATNÉM HROBĚ. Když si mi stěžuješ, tak ničemu nepomůžeš - protože já ani nemám hardware, se kterým bych něco mohl testovat. Opravil jsem ten problém s vypalováním CD. Na to hardware mám a věděl jsem, jak to správně opravit.
Teď jsi na řadě ty. Místo abys plýtval mým časem svými stížnostmi, proč se buď nesmíříš nebo nemlčíš? Ukaž mi kód. PAK ho pošli. Dokud to neuděláš, nemají tvé maily smysl.
10. lis - 14. lis
Joseph Shamash se zeptal, jestli je možné (a jestli ano, jak) vytvořit v Linuxu 2 terabajtový oddíl. Peter Chubb odpověděl:
Ano, je to možné.
Potřebuješ 2.6 kernel. A bude lepší použít něco jíného než MSDOS formát oddílů - doporučuji použít parted a vytvořit GPT tabulku oddílů (což znamená zkompilovat kernel tak, aby tomu rozuměl).
Nezmínil jsi architekturu, na které to běží. Jestli je to 64 bitový systém, nemusíš dělat nic dalšího. Jestli je 32 bitový, tak při kompilaci zapni CONFIG_LBD.
Joseph se také zeptal na maximílní velikost oddílů s kernelem 2.4; Mike Fedyk odpověděl, že si myslí, že maximum je 16 terabajtů na blokové zařízení s 2.6 nebo patchovaným 2.4. Ale Peter řekl:
To platí ro 32 bitové systémy s 4k stránkami. U 64 bitových systémů je limit přes 8 exabajtů.
Nezapomeň, že softwarový RAID má nižší limity, stejně tak LVM. Také ty 2.4 patche byly daleko méně testovány než 2.6 (možná kromě SGI Altix).
18. lis - 19. lis
James Lamanna se zeptal, jestli e-Galax USB dotykové obrazovky fungují v Linuxu 2.4; modul na stránkách firmy vypadá nefunkčně. Jakub Bogusz odpověděl, Před časem jsem měl terminál s eGalax obrazovkou a fungoval. Ale pro nové USB jádro (Linux 2.4.20+) to potřebovalo patch (bez patche fungoval ovladač s 2.4.18, ale způsoboval oopsy s 2.4.20): http://cvs.pld-linux.org/SOURCES/touchkit-2.4.20.patch.
19. lis - 19. lis
Jeff Garzik oznámil:
Ok, Al Virova práce na refcounting net ovladače už je skoro hotová a shemminger/ogawa NAPI konverzace 8139too je také začleněna.
Dejte tomu, prosím, co proto. Nenechte se zmást označením "experimentální"... ty změny by měly být stabilní a půjdou k Linusovi/Andrewovi po znovuotevření 2.6.0 stromu.
Nezapomeňte poslat kopii všech zpráv do netdev@oss.sgi.com.
Alexander Viro odpověděl: Houby [hotové]. A pokračoval:
Už jsme vyřešili hodně, ale stále mám podivné alokátory (už jsem jich udělal většinu, pošlu v další dávce) a pořád tu je struct net_device začleněné jako pole dalších struktur v několika ovladačích.
Není to ta zdaleka tak mohutné jako starší řada zkoušek, ale bude to alespoň 10 - 20 patchů. Nejméně.
19. lis
Len Brown napsal:
Linusi, prosím tě, proveď
bk pull http://linux-acpi.bkbits.net/linux-acpi-release-2.6.0
Svět se bude točit dál, i kdyby tyhle počkaly do 2.6.1, ale podpora 2.6.0 by byla snazší, kdyby byly začleněny.
Běžný patch je k dispozici na: ../acpi-20031002-2.6.0-test9.diff.gz
19. lis
Carl-Daniel Hailfinger oznámil:
Verze 0.18 forcedeth pro Linux 2.4 a 2.6 je na ../forcedeth/. Je také začleněna do 2.6.0-test9-mm4.
Opravy v této verzi oproti 0.17:
Problémy:
Testujte prosím.
V originálu Kernel Traffic 242 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.