Jaderné noviny - 40/2007

9. 11. 2007 | Andrej Kruták | Jaderné noviny | 3063×

Wireless Project navrhuje používanie tagov "Zmeny-licencované-pod". 2.6.23-rc9, Vyhýbanie sa chybám "Brown Paper Bag". (Ne)správny spôsob použitia sched_yield. Plány začleňovania sieťových vecí do 2.6.24. Chyby v optimalizácii prekladačom a vláda nad svetom. Podpora pre viac oddielov. Definovanie tagu "Reviewed-by". Jadro 2.6.23, "Konečne".

• Wireless Project navrhuje používanie tagov "Zmeny-licencované-pod"
• 2.6.23-rc9, Vyhýbanie sa chybám "Brown Paper Bag"
• (Ne)správny spôsob použitia sched_yield
• Plány začleňovania sieťových vecí do 2.6.24
• Chyby v optimalizácii prekladačom a vláda nad svetom
• Podpora pre viac oddielov
• Definovanie tagu "Reviewed-by"
• Jadro 2.6.23, "Konečne"

Následující obsah je © KernelTrap.

Wireless Project navrhuje používanie tagov "Zmeny-licencované-pod"

28. sep, originál

S ohľadom na nové smernice zaslané SFLC v dokumente 'Udržiavanie súborov s voľnou licenciou v projekte s GPL licenciou: Smernice pre vývojárov', hlavne na 5. sekciu, zavádzame nový tag, ktorý sa bude používať s patchami, ktoré pracujú so súbormi licencovanými pod voľnými licenciami (BSD, ISC) v Linux wireless v našom väčšom GPL projekte, linuxovom jadre, vysvetlil Luis Rodriguez v emaili nazvanom "pre Linux-wireless sa zavádza nový tag 'Zmeny-licencované-pod'". Webové stránky linkované v emaili vyzerajú byť oficiálnou odpoveďou SFLC ohľadom nedávnych sporov medzi BSD a GPL, ktoré sa týkali bezdrôtového ovládača Atheros. Luis pokračoval:

Napriek tomu, že niektorí vývojári majú zvyk považovať ich patche za súbory s voľnou licenciou, ktorá sa riadi danou licenciou súboru, ktorý je patchovaný, a napriek tomu, že niektoré zmeny očividne nie je možné copyrightovať, chceme 'hrešiť opatrne', prijať radu od SFLC a zaviesť Zmeny-licencované-pod, aby sme umožnili BSD rodine tiež využívať výhody našich úprav pre súbory s týmito voľnými licenciami.

Na Luisov email prišlo len pár krátkych odpovedí. Stephen Hemminger navrhol jednoduchšie riešenie: nie, prosím, nechoďme cestou tejto právničiny. Môže tak dôjsť k prúserom ako napr. že ľudia budú posielať patche s dvomi licenciami do scheduleru, alebo čisto GPL patche pre ath5k alebo ACPI kód. Miesto toho radšej pridajte sekciu Documentation/SubmittingPatches, ktorá by vyslovene určovala, že všetky zmeny sú licencované pod rovnakou licenciou, ako má pôvodný súbor.. Krzystof Halasa pripomenul, že je to tak už aj teraz - uviedol riadok z "Vývojárov certifikát pôvodu", ktorý sa nachádza v súbore SubmittingPatches, a hovorí: úprava bola vytvorená mnou celá, alebo mám právo zaslať ju pod licenciou, ktorá je v danom súbore napísaná.

2.6.23-rc9, Vyhýbanie sa chybám "Brown Paper Bag"

2. okt, originál

Písal som, že dúfam, že -rc8 je posledná -rc; robím to nerád, ale od -rc8 bolo viac zmien ako ich bolo v -rc8. A aj keď je väčšina z nich vcelku triviálna, naozaj som nemal odvahu vydať 2.6.23 a riskovať, že si na hlavu budem musieť nasadiť hnedú papierovú tašku, povedal Linus Torvalds pri oznamovaní jadra 2.6.23-rc9. Dodal: takže už je vydaná posledná -rc a mojím zámerom je spraviť túto sériu naozaj krátkou a vydať 2.6.23 za pár dní. Takže to, prosím, dobre otestujte a oznámte všetky problémy, ktoré nájdete! Varoval vývojárov, že prvou vecou, ktorá sa plánuje pre 2.6.24 je zjednotenie architektúr x86:

Toto je dobré miesto, ktde vás môžem varovať, že čoskoro budeme zjednocovať x86 (niečo na spôsob ďalšieho, alebo poďalšieho dna) hneď ako bude vydaná 2.6.23 - takže ak máte nejaké patche pre ďalšiu sériu, ktoré sa nejak týkajú arch/i386 alebo x86-64, mali by ste sa spojiť s Thomasom Gleixnerom a Ingom Molnarom, ktorí spravujú merge skripty, a pomôžu vám pripraviť sa...

To, že to spravíme hneď ako to bude možné v sérii 2.6.24-rc4 (v podstate to spravím ako prvú vec), bude znamenať, že budeme mať maximum času na vyriešenie všetkých problémov - a ide o to, že Thomas a Ingo už majú pripravený strom, takže ľudia si proti nemu môžu svoju prácu skontrolovať. Nemusia tak rozmýšľať o tom, že až to zasiahne *môj* strom, bude potrebné robiť nejaké opravy. Bolo by fakt skvelé, keby na to boli všetci pripravení, miesto aby boli prekvapení.

(Ne)správny spôsob použitia sched_yield

2. okt, originál

Naozaj som nikdy nevidel _jedinú_ mainstreamovú aplikáciu, kde by bolo použitie sched_yield() správnym rozhodnutím, uviedol Ingo Molnar počas pokračujúcej diskusie o CFS. Položil otázku, či niekto môže uviesť konkrétny kód, ktorý by ilustroval správne použitie sched_yield(). V odpovedi na teóriu, ako by to potenciálne mohlo zlepšiť zamykanie na strane užívateľského kódu, Ingo vyzval: to sú všeobecné vyhlásenia, ale čo ma zaujíma _naozaj_, sú konkrétne veci. Ozajstný, špecifický kód, na ktorý sa môžem pozrieť. Typická linuxová distribúcia obsahuje viac ako 500 miliónov riadkov kódu, v desiatkach tisícov aplikácií, takže niekde musí existovať nejaké dobré, validné a 'správne' použitie sched_yield() - v nejakej mainstreamovej aplikáci, nie? (pretože, ako ste si mohli všimnúť, v predchádzajúcej dekáde existencie sched_yield() som _videl_ už nejakú kôpku užívateľského kódu, ktorý používa sched_yield() - a zatiaľ nie som tými ukážkami práve očarený.). Ingo ďalej vysvetľoval:

sched_yield() tu je už asi dekádu (asi trikrát dlhšie ako tu sú futexy), takže ak je to užitočné volanie, určite by už mala byť hotová nejaká aplikácia, nejaký 'kráľovský drahokam', ktorá ho používa a ukazuje jeho výhody, v porovnaní s inými prístupmi k zamykaniu, nie?

Ak by ste sa ma, napríklad, opýtali, či sú rúry (pipes) najlepšou vecou pre niektoré aplikácie, okamžite by som vám mohol ukázať tony príkladov, kedy sú. To isté pre sockety. Alebo RT priority. Alebo nice levely. Alebo futexy. Alebo hociaký iný základný koncept jadra alebo API. Tvoj názor, že ukázať dobrý príklad pre API by bolo 'ťažké', pretože je ťažké určiť 'rozumné' použitie, je podľa mňa neobhájiteľný a nevyvracia primeraným spôsobom moje vcelku zrejmé tvrdenie - 'neexistuje'.

Plány začleňovania sieťových vecí do 2.6.24

3. okt, originál

Po tom, čo som vyšetroval problémy s výkonom TCP (ktoré sa ukázali byť problémami špecifického hardvéru), som trochu pozadu. Je to trošku sklamanie, myslel som, že v TCP mohol byť nejaký cool bug na opravenie :-), vysvetlil David Miller pri zasielaní plánov začleňovania sieťového kódu do nadchádzajúceho jadra 2.6.24. Poznamenal: Začlenil som Jeffove Garzikove a Johnove Linvillove posledné (úpravy) a aktuálny strom beží na mojej pracovnej stanici väčšinu dnešného dna so zatiaľ dobrými výsledkami. David potom dodal: Mám v pláne commitnúť môj ovládač Neptune v stave, ako je teraz, a to je posledná novinka, čo sa dostane dnu.

V diskusii minulý mesiac v Linux netdev mailing liste David popísal, koľko zmien bolo v jeho net-2.6.24 git strome: zašlo to až tak ďaleko, že každá jedna oprava vložená do Linusovho stromu spôsobuje merge konflikt s net-2.6.24; skrátka meníme fakt veľa vecí :-) Dodal: V net-2.6.24 sme toho zmenili toľko, že by sme to celé mali skontrolovať a opraviť chyby, ktoré pribudli. Ak sa nudíte a hľadáte nejakú prácu, vyberte si náhodný ovládač NAPI a skontrolujte ho v strome net-2.6.24.

Chyby v optimalizácii prekladačom a vláda nad svetom

5. okt, originál

Hlásenie chyby vyplnené Ingom Molnarom ohľadom pádu procfs v nedávno vydanom jadre 2.6.23-rc9 boli Linusom Torvaldsom rýchlo odhalené ako chyby prekladača. Pôvod chyby bol jednoznačne priznaný optimalizácii staršou verziou kompilátora GCC. Spočiatku bol Ingo skeptický: je to 4.0.2. Nie je najnovší a najlepší, ale používam ho už 2 roky - a toto by bol prvý prípad z desiatok tisícov bootov, kedy zle skompiluje 32bitové jadro. Linus odpovedal: Som si istý na 100 %. Môžem sa pozrieť na disassemblovaný kód a ukázať, že tvoje Oops nastáva v kóde, ktorý je jednoducho úplne odveci. Pokračoval poskytnutím zaujímavého popisu pádu, kde riadok za riadkom vysvetľoval, čo sa malo vygenerovať vs. čo sa v skutočnosti vygenerovalo a spôsobilo pád. Na konci Ingo prešiel na distribučné GCC 4.1.2 a potvrdil, že pád zmizol - takže máš úplnú pravdu, je to chyba prekladača 4.0.2.

Počas vlákna Linus naznačil, že optimalizácia produkovaná prekladačom nie je 'legálna', na čo Alan Cox odvetil: Formálne: validné. Skoro ľubovoľné optimalizácie sú prípustné, nik ešte nenapísal zákony o prekladačoch. Ospravedlňujem sa, ale vkuse musím opravovať slovo 'nelegálny' (illegal) vo volaniach printk, dokumentácii a iných podobných miestach - a už je to naozaj trochu otravné. Linus zažartoval: hehe. Až budem vládca sveta, *bude* to nelegálne. Trochu sa predbieham. Keď padla otázka, kedy očakáva, že sa tým vládcom stane, Linus dodal: Pracujem na tom, pracujem. Trápi ma to tak isto ako vás. Ale ukazuje sa, že to nebude až také triviálne.

Podpora pre viac oddielov

8. okt, originál

15 oddielov (aspoň pre zariadenia sd_mod) je primálo, uviedol Jan Engelhard spolu so svojim patchom, ktorý sa pokúša umožniť mountovanie neobmedzeného počtu oddielov (a darí sa mu to). H. Peter Anvin navrhol alternatívu: teraz, keď už máme 20bitové minory, nemôžeme jednoducho zrecyklovať niektoré vyššie bity pre dodatočné oddiely? 63 oddielov vyzerá byť dostatočný počet; teda, zatiaľ som nepočul o nikom, kto by sa za posledných 15 rokov sťažoval.

Alan Cox vysvetlil: tento návrh padol už pred vekmi. Al Viro vetoval roztrúsené minory a už to tak odvtedy ostalo. Ak máte viac ako 15 oddielov, použite na to mapovač zariadení (device mapper). Chcel by som, aby sa to opravilo - ale je možné dobre argumentovať to, že mapovač zariadení je správnym spôsobom, ako sprístupniť 'partitioning' užívateľom.

Definovanie tagu "Reviewed-by"

8. okt, originál

Na kernel summite minulý mesiac sa diskutovalo o zavedení Reviewed-by (skontrolované(-od)) tagov na patche, aby sa zdokumentovala kontrola, ktorá na nich prebehla pri ceste do hlavného stromu, začal Jonathan Corbet pri pokuse definovať význam nedávno zavedeného tagu reviewed-by. Pokračoval: ten tag sa už odvtedy párkrát vyskytol, ale doteraz neprebehla diskusia, čo to vlastne znamená. Takže to zatiaľ do procesu príliš veľa nepridalo...

V pokračujúcej diskusii padla požiadavka, aby sa definovali všetky commit tagy, spolu so žiadosťou na Jonathana, aby aktualizoval jeho dokumentáciu tak, aby obsahovala Signed-off-by (podpísané od), Acked-by (schválené od), Cc a Tested-by spolu s dokumentáciou pre Reviewed-by. Pre nový tag Reviewed-by navrhol nasledujúcu definíciu:

Tento patch bol skontrolovaný a uznaný akceptovateľným s ohľadom na stanovisko hodnotiaceho, ktoré je možné nájsť na konci tohoto súboru. Tag Reviewed-by je uvedením názoru, že patch je vhodnou úpravou jadra bez akýchkoľvek nevyriešených závažných problémov. Pre patch môže ponúknuť Reviewed-by tag hociktorý zainteresovaný hodnotiaci (ktorý na tom pracoval).

Jadro 2.6.23, "Konečne"

9. okt, originál

Konečne. Áno, oneskorilo sa to - nie kvôli nejakým väčším problémom, ale kvôli rôznym opravám chybičiek, ktoré natiekli dnu a celý čas spôsobovali resetovanie mojich 'hodín na vydanie'. Ale teraz už je von a vďaka čakaniu snáď aj lepšie, napísal Linus Torvalds pri oznamovaní jadra 2.6.23. Spomenul pár zmien oproti predchádzajúcej -rc verzii: oproti -rc9 tých zmien nie je veľa, aj keď je tam pár aktualizácií pre mips, sparc64 a blackfin. Ak tieto aktualizácie pre architektúry odignorujeme, sú to všetko viac-menej jednoriadkové zmeny (hlavne v ovládačoch, ale vyskytli sa aj opravy sieťovania a VFS/VM). Zmeny na úrovni zdrojových kódov je možné vidieť cez rozhranie gitweb. Pekný prehľad všetkých zmien sa dá nájsť na Kernel Newbies. Linus popísal svoj ďalší plán postupu:

Chcem, aby sa ľudia na toto pozerali ďalších pár dní, ale potom očakávajte, že dôjde k zjednoteniu x86. Zatiaľ všetky indikátory smerujú k tomu, že by to mohlo byť bezbolestné, ale čo si budeme - tie indikátory to asi tvrdia vždy, a ľudia si všimnú problémy, až keď nastanú ;)

       

Komentáře

[Filip Jirsák]

Dnes budu mít k pravopisu jenom drobnost – dvojitá čárka v poslední kapitolce:

Ale teraz už je von a vďaka čakaniu snáď aj lepšie,,

[Andy]

a hned za tim je spatne napsano

Linus Toravlds

jinak musim i zde podekovat za vydavani JN

[Robert Krátký]

Díky, opraveno.

[Andrej Herceg]

Chýbajúce sa v texte:

Ak by ste sa ma, napríklad, opýtali, či sú rúry...

[Peppa1]

pro ty mladší: dnu = dovnitř

[Field]

V sekci "Chyby v optimalizaci" je spatny prvni link.

Mimochodem, vazne byste prelozili "I'm a bit ahead of myself" jako "prave prekracujem svoj tien"? Tahle fraze ma v cestine ponekud jiny vyznam.. Cesky bych to napsal asi jako "trochu se predbiham". Jak je to ve slovenstine?

[andree]

problem bol v tom, ze som tu frazu videl prvykrat... tvoj preklad je samozrejme lepsi/spravnejsi, snad to Robert opravi ("Trochu sa predbieham", po slovensky)

[Robert Krátký]

Hotovo.

[altaran]

kvalitni clanek, jako JN vzdy :) jsem zvedav jestli se sloucenim x86 a x86-64 ukaze nakej skaredej kostlivec ve skrini :)

[hajma]

kvalitni clanek, jako JN vzdy :) jsem zvedav jestli se sloucenim x86 a x86-64 ukaze nakej skaredej kostlivec ve skrini :)

asi jsi chtěl říct "jsem zvedav kolik kostlivcu se sloucenim x86 a x86-64 ukaze" ...

[altaran]

v jednotnem cisle to zni optimisticteji ;) kazdopadne tak jako tak, prepsanim spatneho(neuniverzalniho, "nezakoneho") kodu, muze odstranit nekolik, treba i stovek, bezpricinnych bugu..