AbcLinuxu:/ Články / Jaderné noviny 247

Štítky: C, e-mail, emulace, glibc, HTML, kernel, komunikace, licence, Linux, patch, programování, SUSE, textové editory, udev, Unix, Vim, web

Jaderné noviny 247

28. 1. 2004 | Robert Krátký | Jaderné noviny | 4410×

Odmítnutí začlenit do jádra patentovaný kód. Stav podpory velkých souborových systémů (LFS). Larry se odhlásil z konference. Linus komentuje několik příkladů kódu, který SCO označilo za ukradený.

Odmítnutí začlenit do jádra patentovaný kód, 27 e-mailů

18. pro - 22. pro

Lennert Buytenhek se zeptal, jestli by nevadilo začlenění patentovaného algoritmu, který by zrychlil vyhledávání v routovací tabulce IPv4, do jádra 2.7. Linus Torvalds odpověděl: Neposílej to a najdi algoritmus nezatížený patentem. Pokud ovšem nepřiměješ držitele patentu udělit licenci (i to se stává).

Správcovství Real-Time aplikačního rozhraní, 13 e-mailů

18. pro - 21. pro

Karim Yaghmour poslal patch, který přidával Philippe Geruma coby správce Adeos, odstraňoval Victora Yodaikena coby správce RTLinuxu a přidával Paolo Mantegazza coby správce RTAI (Real-Time Application Interface). Zwane Mwaikambo navrhl vynechat Paola ze seznamu správců stejně jako Victora, protože ani jeden namá v kernelu žádný kód.

Karim odpověděl: RTLinux nikdy v kernelu žádný kód neměl, ale přesto byl zmíněn v souboru správců několik let. Myslím, že tyto záznamy jsou vodítkem pro ty, kteří se o tu oblast využití Linuxu zajímají. RTAI je jediným svobodným softwarovým real-time rozšířením Linuxu, a proto si tu zmínku zasluhuje. V současné době je rtlinux.org pouhým aliasem pro fsmlabs.com, což celou situaci pěkně vystihuje.

Zwane reagoval: Zapomínáš, k čemu soubor MAINTAINERS (správci) slouží. Prostě si myslím, že celý případ by šel vyřešit vymazáním obou z MAINTAINERS, protože ani jeden nemá v kernelu kód. Pokud někdo potřebuje real-time schopnosti Linuxu, může použít Google.

Karim odpověděl, že nejlepší by bylo nechat o patchi rozhodnout šéfy, ale Nick Piggin řekl, že také souhlasí se Zwanem: Soubor MAINTAINERS je nepřehledný už takový jak je teď. Využívat ho k vzájemnému poplácávání po zádech ho znehodnotí úplně. Jak řekl Zwane, ani jeden nemá v kernelu kód, takže nechápu jaký by pro to byl důvod...

A Karim uzavřel: Stejný důvod, kvůli kterému tam byla zmínka všechny ty roky. Ale jak jsem již řekl dříve, nejde o mě a nechci začínat debatu o využívání MAINTAINERS. Od toho jsou tu povolanější. V tu chvíli Victor řekl, že jednu dobu v kernelu kód měl, na což Karim odpověděl:

Chceš říct, že v kernelu je kód, který podléhá tvému patentu?

Pokud ano, pak by měl být určitě odstraněn. Kernel by se měl patentovanému kódu vyhýbat. Zrovna nedávno to Linus prohlásil: http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/0624.html.

Linus Torvalds odpověděl:

To není pravda.

V kernelu by neměl být žádný patentovaný kód BEZ LICENCE.

Email, který cituješ, výslovně říká "Pokud ovšem nepřiměješ držitele patentu udělit licenci". A patenty RTLinuxu byly licencovány pro použití GPL projekty.

Nechápu, proč si lidé neustále na patenty RTLinuxu stěžují. Vsadím se, že je to kvůli Victorovu charisma, které sdílí s Larry McVoyem. Ale i tak nevím, proč o tom lidé neustále šíří zjevné nepřesnosti.

Nejsem zastáncem softwarových patentů, ale ačkoliv je nemám rád, není to nic proti tomu, jak nemám rád nečestné lidi.

Stav podpory velkých souborových systémů (LFS), 5 e-mailů

20. pro - 22. pro

Dale Amon řekl: Narazil jsem na starší diskuze o patchi, který řešil problém s 2TB velikostí filesystémů. Je to standard v jádrech 2.6? Jaké jsou v současné době limity na velikosti filesystémů a souborů? Jose Luis Domingo Lopez odpověděl:

V 2.6.x kernelech jsi také limitován 2 TiB omezením na velikosti blokových zařízení. Ten limit lze zvětšit kompilací kernelu 2.6.x s podporou "Large Block Device" (menu "Device Drivers" -> "Block devices", na konci).

Také budeš potřebovat filesystémy, které takové velikosti podporují a dokáží na nich ukládat velké soubory. Na této adrese najdeš více informací: http://www.suse.de/~aj/linux_lfs.html

Dale stránky pročetl a zjistil, že jsou dost staré. Zeptal se, jestli existují aktuání knihovny, které by s LFS fungovaly, ale později si sám odpověděl: Už to mám. glibc 2.1.3 má plné API; glibc 2.2 má plnou podporu; teď používám glibc 2.3.2ds1, takže pokud tu LFS volbu zapnu, mělo by to všechno vesele fungovat se spoustu terabajtíků. Peter Chubb připojil:

Ano. Většina glibc je distribuována se zakompilovanou podporou _LARGEFILE64.

Viz také http://www.gelato.unsw.edu.au/IA64wiki/LargeBlockDevices. Ještě jsem se nedostal k tomu, abych to aktualizoval podle verze 2.6, ale i ty poznámky o 2.5 by měly platit.

Larry se odhlásil z konference, 1 e-mail

23. pro

V pokračování tématu z JN 246 To je celý Larry Larry McVoy z BitMoveru řekl: Odhlásil jsem se z této konference. Tohle je dobrý příklad, proč jsem to udělal. Bez smyslu pro humor si stěžuješ na licenci u 200 řádkového kousku kódu. Každý lepší programátor by to napsal znovu rychleji než ty ten mail.

Linus komentuje několik příkladů kódu, který SCO označilo za ukradený, 5 e-mailů

22. pro - 22. pro

John Dee napsal: Vím, že už jste to patrně četli. Říkal jsem si, že bych se o to podělil s třídou a nechal velký kluky, ať to roztrhají na kousky. http://lwn.net/Articles/64052/. Linus Torvalds odpověděl:

Strávil jsem půl hodiny tím, že jsem to trhal na kousky pro pár novinářů. Nemohu zaručit stoprocentní přesnost následujícího textu - především proto, že nemám žádný "originální UNIX", který bych mohl použít pro srovnání - ale soubory, které jsem kontroloval (ctype.[ch]), rozhodně nepocházejí z žádného UNIXu.

To ostatní jsou povětšinou errno.h/signal.h/ioctl.h (a zjevně verze z 2.4.x - před tím než jsme některé společné konstanty přesunuli do "asm-generic/errno.h") a ačkoliv jsem neprováděl žádnou analýzu, vím určitě, že:

původní errno.h používal jiná čísla chyb než "originální UNIX"

Vím to, protože jsem si za to později nadával, protože to znamenalo pro věci typu binární emulace překládat chybová čísla.
totéž platí pro "signal.h": i když mnoho standardních signálů je dobře zdokumentováno (tj. "SIGKILL je 9"), v minulosti jsme měli dost zmatků. (např. mám pocit, že "skutečný UNIX" má SIGBUS na 10, ale Linux původně neměl SIGBUS žádný a později jsme to dali na 7, což bylo SIGUNUSED.

Takže se mi zdá, že

ano, Linux pochopitelně má stejná jména signálů a chybových čísel jako UNIX (takže ty soubory mají mnoho společného),
ale podobně zřejmé je, že ze žádného "skutečného UNIXu" zkopírovány nebyly.

(Později se jiné architektury než x86 více snažily o binární kompatibilitu se svými protějšky ze světa "skutečných UNIXů", a proto máme u různých architektur různé errno hlavičkové soubory - a na těch jiných architekturách budou ta čísla většinou shodná s tradičně unixovskými).

Například když grepnete SIGBUS ze zdrojáků kernelu, ukáže se, že většina architektur má SIGBUS 7 (původní linuxová hodnota), ale alpha, sparc, parisc a mips to mají 10 (aby se shodovalo se "skutečným UNIXem").

Z toho je vidět, že původní kód nepochází z UNIXu, ale některé architektury byly později udělány tak, aby měly v zájmu binární kompatibility hodnoty stejné jako UNIX (vím, že to tak je například u alphy: kompatibilita s OSF/1 byla u tohoto portu jedním z mých prvních cílů).

Jinými slovy, myslím, že můžeme tvrzení o zkopírování těchto 65 souborů úplně rozsekat. Je zjevné, že zkopírovány nebyly.

Což asi většinu nijak nepřekvapí. Ale líbí se mi, jak jasně můžeme ukázat, že SCO - pro změnu - vůbec nemá pravdu.

Linus

Linus pokračoval ještě rozborem, ve kterém zmínil, že kdyby nebylo této situace, nikdy by nepřiznal, že původní linuxový soubor ctype.h napsal on sám - ten kód je tak amatérský, že by se styděl to prohlásit za vlastní práci.

dm-crypt bude v jádře 2.6 místo cryptoloop, 23 e-mailů

22. pro - 23. pro

Christophe Saout navrhl nahradit problémový loop ovladač novým mapovačem zařízení.

V 2.6 máme device-mapper, který dělá totéž ale mnohem obecněji. Už jsem mluvil s několika lidmi, kteří pracují na loop a cryptoloop (včetně Clemense Fruhwirtha, správce cryptoloop), a všichni souhlasí s tím, že device-mapper je nejlepší cesta, kterou se dát, a byli by radši, kdyby byl loop ovladač používán pouze pro soubory.

Andrew Morton odpověděl, že on sám cryptoloop nepoužívá, takže nedokáže posoudit, jestli by device-mapper mohl být adekvátní náhradou. Pokud jsou však ti, kteří se v tom vyznají, přesvědčeni, že to bude změna k lepšímu, není důvod tomu bránit, protože loop ovladač je známý svou chybovostí. Upozornil však na problémy, které pravděpodobně nastanou při migraci, a dodal, že by bylo nejlepší prozatím cryptoloop udržovat funkční a plánovat jeho odstranění až do doby 2.8.

Fruhwirth Clemens k tomu řekl:

Ačkoliv jsem správcem cryptoloop, okamžitě jsem poznal, že dm-crypt je o moc lepší, když s tím Christophe poprvé přišel. Důvody:

Netrpí problémy, které přináší loop.c (je jich dost, nemá to žádného správce).
dm-crypt není závislý na speciálním uživatelském nástroji (util-linux).
dm-crypt používá mempool, což jej ve srovnání s cryptoloop činí stabilním jako skála.

Z provozního hlediska bylo patchování util-linux vždycky noční můrou. Na netu se pohybuje spousta nekompatibilních patchů a poslední vydání cryptoloop poskytuje pouze nefunkční a IMHO nebezpečný způsob nastavování šifrovacích klíčů.

A dodal: Měli bychom cryptoloop i nadále podporovat. Žádné nové funkce, ale udržovat to funkční. Zároveň bychom to však měli prohlásit za zastaralé a nabídnout dm-crypt jako alternativu. Rád poskytnu dokumentaci pro migraci.

V originálu Kernel Traffic 247 vyšla navíc ještě tato témata: