Jaderné noviny 287

3. 1. 2005 | Robert Krátký

Články - Jaderné noviny 287  

Stav OSS (Open Sound System). Nový a menší nástroj /sbin/hotplug. Dokumentování ioctl. Správcovství osiřelého kódu. Diskuze o rozšířeních kompilátoru. Hardwarové problémy kernel.org.

Do konference přišlo celkem 2099 emailů, nejvíce jich poslali Adrian Bunk, Andrew Morton a Greg KH.

Stav OSS (Open Sound System), 9 e-mailů

17. lis - 18. lis

John W. Linville poslal opravu pro OSS, kterou nestoudně ukradl z ALSA. Andrew Morton se zeptal, proč raději nepoužívá ALSA místo OSS, a Jeff Garzik odpověděl: Dokud OSS ovladače skutečně neodstraníme, bylo by hloupé je nechávat nefunkční. Jan Engelhardt reagoval: Stejně tako hloupé je opravovat něco, co stejně odstraníme. Alan Cox připomněl, že dost lidí OSS pořád používá, a Jeff připojil: Dokud není pryč, dali by současní uživatelé přednost funkčnímu před nefunkčním. Jan napsal, že by bylo lepší to ponechat nefunkční, aby to lidi přimělo přejít na ALSA, ale Jeff řekl: i810 v ALSA pořád tuhne... Lee Revell k tomu poznamenal: Opraveno v úterý v ALSA CVS. Tahle oprava by měla jít do 2.6.10.

Nový a menší nástroj /sbin/hotplug, 5 e-mailů

18. lis - 19. lis

Greg KH napsal:

Za posledních pár let si dost lidí stěžovalo, že /sbin/hotplug je shellový skript. Legrační je, že si stěžují lidi s velkými stroji a velikým počtem zařízení, ne ti, kteří používají embedded zařízení s omezenými zdroji (ironické, co).

V příloze najdete nový /sbin/hotplug napsaný v C. Kompilace s klibc dopadne takto:

$ size hotplug
   text    data     bss     dec     hex filename
   4149      28      20    4197    1065 hotplug
$ ls -l hotplug
-rwxr-xr-x  1 greg users 4636 Nov 18 15:08 hotplug

Což je na mých počítačích méně než /bin/true (A /bin/true je linkováno dynamicky, tohle je statická binárka. I linkované dynamicky by to bylo menší než /bin/true. GNU programy, co na to říct...)

Všechno to budu postupně dávat dohromady do balíku "hotplug-ng" - jak budu pomalu nahrazovat existující hotplug skripty novými, které budou založené na tom, co jsme se dozvěděli za poslední 4 roky, a zároveň bude vypouštěna podpora jádra 2.4 a starších kernelů.

Jo, vím, že je potřeba opravit chybku v tom, že když neexistuje /dev/null, měli bychom to sami vytvořit a pak pokračovat dál. To je další na seznamu.

Eugene Surovegin poznamenal, že si stěžovali uživatelé velkých strojů a ne embedded zařízení pravděpodobně proto, že v embeddech zařízeních se hotplug asi vůbec nepoužívá :). Pracoval jsem na tuctu různých PPC a MIPS strojích, ale nikdy jsem tuto funkci nepotřeboval. Robert Schwebel nesouhlasil: PTXdist má už nějakou chvíli podporu hotplug. A Chris Larson také řekl: Zajímá mě hlavně ARM a tahle funkce mi přijde velmi užitečná. Vím o dost lidech, kteří používají "diethotplug" od Erika Andersena (už dlouho na to nikdo nesáhl). Těším se na další vylepšení hotplug. Greg odpověděl:

Ano, diethotplug je založen na mém starším balíku, který se nazýval, překvapení, diethotplug - najdete jej zde:

http://www.kernel.org/pub/linux/utils/kernel/hotplug/

Dokumentování ioctl, 6 e-mailů

18. lis - 19. lis

Edward Falk napsal:

Ahoj vespolek; dovolte mi se představit: jsem ten člověk, který se stará o IDE v Google.

Připravuji se na zdokumentování IDE ioctl. Nejspíše Documentation/hdio.txt nebo něco podobného. Než s tím začnu, dělá to už někdo?

Jim Nelson napsal, že neví o nikom, kdo by ioctl dokumentoval:

Když jsem si prošel věci, které už v dokumentaci jsou, pohrával jsem si s myšlenkou, že bych zkusil ioctl zdokumentovat, ale došlo mi, že už takhle toho mám na práci dost.

Nejspíše bych udělal podadresář - tj. Documentation/ioctl/hdio.txt - aby se to odlišilo od ostatních dokumentů a také aby se správcům usnadnilo přidávání vlastních věcí ;). Jestli se nemýlím, tak v balíku jádra nikde žádná dokumentace k ioctl není.

Správcovství osiřelého kódu, 5 e-mailů

19. lis - 20. lis

Adrian Bunk napsal: Nejsem si jist, jestli má smysl uvádět předchozí správce opuštěného kódu, ale obsahují-li takové záznamy neplatné mailové adresy, je podle na čase je prostě odstranit. Poslal patch k odstranění Micheala H. Warfielda coby správce opuštěného ovladače karty Computone Intelliport Multiport. Andrew Morton řekl, že uvedená adresa je i nadále platná. Adrian odpověděl, že ta mailová konference zjevně zanikla. Jim Nelson napsal:

Kdyby měl někdo chuť se toho ovladače ujmout, bylo by lepší mít kontaktní informace o starém správci dostupné na jednom místě. Navíc kdokoliv, kdo ovladač vyzkouší a zjistí, že nefunguje, se může podívat do souboru MAINTAINERS a přečíst si, že jej nikdo neopravuje - místo toho, aby to byl jeden z těch ovladačů, které nemají určeného správce (na pár jsem narazil).

Konec konců, musíme být ohledně nespravovaných ovladačů upřímní - místo zatajování nefunkčního kódu. Skutečně je lepší napsat, kdo je za daný kód zodpovědný - i kdyby už nefungoval.

Adrian poukázal na to, že kontaktní informace jsou i nadále dostupné v dokumentaci k ovladači, a že:

MAINTAINERS nepokrývá všechny ovladače. Nejde o upřímnost nebo zatajování nefunkčního kódu. Přidání dejme tomu padesáti položek pro nespravované ovladače nemá žádný praktický význam.

Já alespoň v MAINTAINERS hledám lidi, kterým mohu dnes posílat patche, ne lidi, kteří na ovladači někdo dříve pracovali. Přidávání informací o osiřelých ovladačích do tohoto souboru jen ztěžuje zjišťování, jestli existují platné záznamy o daném ovladači.

Nic bych neměl proti tomu, kdyby se někdo přihlásil a spravoval dokument o stavu ovladačů. Ale to by znamenalo pořádný kus práce - ne jen doplnění pár osiřelých ovladačů do MAINTAINERS.

Diskuze o rozšířeních kompilátoru, 17 e-mailů

20. lis - 23. lis

Během diskuze poznamenal Russell King, že céčková konstrukce "int tickadj = 500/HZ ? : 1" v kernel/ptrace.c je dost divná. Někdo jiný připojil, že část podmínky 'true' je prázdná a standard C v takovém případě nedefinuje výchozí hodnotu. Takže nedává smysl, že je C kompilátor schopen si s takovou konstrukcí poradit. Linus Torvalds k tomu napsal:

Ve skutečnosti je to zdokumentovaná vlastnost GCC, kdy je chybějící 'true' podmínka nahrazena hodnotou podmínky.

Takže uvedený příklad nastaví "tickadj" na 500/HZ - kromě případu, kdy podteče na nulu - pak dostane tickadj hodnotu 1.

Jinými slovy, je to stejné jako:

int tickadj = 500/HZ ? 500/HZ : 1;

až na to, že kratší zápis je nejen kratší, ale i neobyčejně šikovný pro makra apod., protože hodnotu zkoumá pouze jednou, takže můžete udělat:

int tickadj = *ptr++ ? : 1;

a chová se to pěkně, protože ten pointer je navýšen pouze jednou.

Jan Engelhardt protestoval: Dělá to jen GCC. To likviduje snahy o kompilaci jádra pomocí ICC :) Linus odpověděl:

Ááále, vývojáři intelského kompilátoru jsou mazaní a mohou ICC dělat tak, aby bylo kompatibilní s dobrými rozšířeními GCC (a pokud vím, už to udělali).

A jak všichni víme, definice "dobrého rozšíření GCC" zní: "jádro ho používá". (Některé z těch dobrých se objevily v C99 a již tím pádem nejsou rozšířeními - GCC samozřejmě nebyl jediný kompilátor, který je implementoval.)

Dobrá rozšíření GCC:

• inline asm syntaxe (mohlo by to být lepší, ale co - syntaxe GCC taky určitě není ta nejhorší)
• statement výrazy (ale kruci, mělo by to pro vrácení hodnoty používat "return")
• krátké kondicionály
• atributy symbolů (sekce, "použitý", pojmenování asm, atd.)
• lokální labely a počítané goto
• case range
• typeof a alignof.
• void * arithmetic

ŠPATNÁ rozšíření GCC:

• vnořené funkce (grrr)
• rozšířená lvalue (casty, kondicionály a čárkové operátory coby lvalue. Jsou prostě příliš matoucí.)
• transparentní unie (kruci, to se dá udělat s overloading).

Jana Engelhardta se dotklo, že Linus vytvořil kategorii špatných rozšíření GCC: Nemusíš je používat... Ale Linus odpověděl:

Taky je většinou nepoužíváne. Ale jsou špatná, i když je nepoužíváš. Protože někdy jsou kvůli nim běžné chyby v syntaxi těžko debugovatelné.

Například ty "vnořené funkce" způsobují, že něco tak jednoduchého jako zapomenutá koncová závorka je pak hlášeno naprosto špatně. GCC se rozhodne "hele, je to OK, ty další deklarace funkcí jsou jen vnořené funkce uvnitř jiné funkce". Takže dostaneš něco jako:

file.c: lastline: parse error at end of input

ačkoliv skutečná chyba by mohla být přesně vyhmátnuta, kdyby GCC nemělo své totálně dementní vnořené funkce. Jinými slovy, to rozšíření působí problémy, i když ho nepoužíváš.

Linus ještě probral další případy, kdy jsou podle něj rozšíření spíš ke škodě než k užitku.

Hardwarové problémy kernel.org, 1 e-mail

24. lis

H. Peter Anvin vysvětlil: Pokud se někdo podivoval nad nedávnou pomalostí kernel.org... po vydání Fedora 3 jsme měli zatím nejvyšší zátěž a pořád se to ještě zcela nezklidnilo. Kromě toho se na hardwaru začíná projevovat jeho věk. Aktivně sháníme nový hardware a doufáme, že během prosince nebo ledna už bychom měli mít nasazeného něco nového.

---

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

• Linux 2.6.10-rc1-mm4 Released
• Out-Of-Memory Killer: Hunting For The Proper Layer
• Linux 2.6.10-rc2 Released
• Linux 2.6.10-rc2-mm1 Released
• Linux 2.4.28 Released
• Xen 2.0 Updates
• Linux 2.6.10-rc2-mm2 Released
• Kprobes Wrapper To Define jprobe.entry
• LKST 2.2.0 For Linux 2.6.9 Released
• Linux 2.6.9-ac10 Released
• Intel Thermal Monitor For x86_64 Updated
• Possible GPL Violation By Silicon Laboratories

Tento článek vychází ze seriálu Kernel Traffic (www.kerneltraffic.org) a je zveřejněn pod licencí GPL verze 2.

Diskuse k tomuto článku

[none]

haha... mám první komentář

[Jan Grmela]

Za chvili to tu bude uz jak na Zive

[Leoš Literák]

pekne ubohe, hamba ti.

[Hynek (Pichi) Vychodil]

Aaaaa, neeee, chyba! Vůbec nereagovat! Zkrátka ani slovo, žádné nadávky, žádné pochvaly ani neutrální reakce. Zkrátka vůbec nic. To je jediná cesta!

[Leoš Literák]

mame vyuzit adminovskych prav a takoveto ubohosti rovnou mazat?

[David Jež]

Rozhodne. Nebo zcenzurovat jakoze blbost a zmrazit thread, i kdyz zase zacnes mazat ve velkem a lide te budou nenavidet...
-djz

[Hynek (Pichi) Vychodil]

Těžko říct. Vymazáním by jsi mohl vyvolat záplavu podobných zpráv a nadávky, že jsi cenzor. Když to budeš cenzurovat jako blbost, tak je problém najít tu hranici. Úplná ignorace vyžaduje ukázněnost i od uživatelů. To je fak těžká rada.

[none]

a teď tady vyvstala ta otázka: Kdo víc zaspamoval tohle fórum? sorry, já chtěl ten příspěvek pak smazat, ale nejde to, takže to klidně smažte...

[Leoš Literák]

To je pravda. Ale naivne se snazim uzivatele vychovat. Doufam, ze kdyz ostatni uvidi (nejen) moji reakci, pochopi trapnost hlasek "jsem prvni".

A za druhe, treba tu najdeme konsensus, jak s nimi nakladat. Zda je cenzurovat, mazat ci nechat tak.

[koubik@centrum.cz]

Off topic: co takhle se venovat tematu </flame>

[Petr Jakubec]

Jednoznacne nemazat!

Hledat hranice co smazat je velmi nevdecne a ma to neblahy vliv na rozhodujiciho i ostatni. Je tu vsak jeste moznost predstavit nam toho "anonyma" v pripade ze mate jeho udaje (samo ze ty ktere lze zverejnovat, treba IP, ISP apod) - to zajima mne (ctenare), vzdy kdyz se ptam: "co je to zas za deb...!?!", kdyz to ctu.
Tito hlupaci, maji totiz pocit ze jsou kryti anonymitou (nechapu jak prisli na to, ze by mohli byt anonymni). A pokud se Ty jako spravce "seknes" a zverejnis vice informaci nez je obvykle o cloveku, ktery korektne napsal neco do diskuze (alespon takhle se to bude jevit nekomu jinemu), nestane se vlastne nic tak strasneho. Urcite Ti pak nikdo nemuze nadat do censoru. Censura je vec vesmes odporna. PJ

[Honza Houštěk]

Nějak to nechápu. K čemu bude zveřejnění IP adresy? Neni v tom žádný problém, osobně bych nebyl ani proti možnosti zveřejňovat IP u všech příspěvků, ale jak s tím údajem čtenáři naloží, to vážně netuším.

[Taif]

To jako ze by jsi na toho, kdo napise blbou zpravu, pustil DOS/DDOS?? :o). At si rika, kdo chce co chce a at si kdo chce reaguje na co chce - to je panecku cestina.