Jaderné noviny - 27. 9. 2006

16. 10. 2006 | Robert Krátký

Články - Jaderné noviny - 27. 9. 2006  

Aktuální verze jádra: 2.6.18. Citáty týdne: Linus Torvalds, Bruce Perens. Začíná vývojový cyklus 2.6.19. Změny ovladačového API v 2.6.19. Postoj vývojářů jádra k GPLv3.

Aktuální verze jádra: 2.6.18

Aktuální verze jádra je i nadále 2.6.18. Období pro začleňování novinek do 2.6.19 už začalo a v okamžiku, kdy vzniká tento text, je už v hlavním git repozitáři přes 2000 patchů - shrnutí najdete v přehledu níže.

Aktuální verze -mm stromu je 2.6.18-mm1. Mezi nedávné změny patří ovladač xpad dance pad, nová verze bezpečnostního modulu SLIM a množství oprav. -mm se rychle zmenšuje, protože patche putují do hlavního stromu.

Adrian Bunk vydal první předverzi 2.6.16.30. Kromě běžných oprav přidává tento patch také několik nových ovladačů, což vyprovokovalo dotazy ohledně kritérií pro přijímání patchů pro dlouhodobě spravovaný strom 2.6.16. Vypadá to, že do budoucna bude 2.6.16 trochu otevřenější k novému kódu než strom -stable.

Citáty týdne: Linus Torvalds, Bruce Perens

Nezaručuji, že změním názor pokaždé. Ale mohu slíbit, že pokud mi většina lidí, kterým důvěřuji, řekne, že jsem pitomec, alespoň zběžně se nad tím zamyslím.

[ Sbor: "Linusi, jsi pitomec." ]

-- Linus Torvalds

Nakonec si budeme muset přiznat, že Linux je 15 let staré jádro, a že jak půjde vývoj dál, něco jej nahradí. Nedokážu říci, co to bude, ale myslím, že nejlepším způsobem, jak k tomu přivést lidi, je použít GPL 3.

-- Bruce Perens

Začíná vývojový cyklus 2.6.19

Záplava čekajících patchů byla vpuštěna do hlavního stromu. Těch 2000 patchů, které byly dosud začleněny, bude pravděpodobně na počet ještě přebito těmi zbývajícími. Následuje seznam věcí, které si už do jádra cestu našly. Začínáme změnami viditelnými pro uživatele:

• Souborový systém OCFS2 už není označen jako "experimentální."
• Aktualizace InfiniBand, včetně lepší podpory RDMA a ovladačů pro několik nových adaptérů.
• Podpora směrování podle pravidel v IPv6 [policy routing] - a mechanismus pro vytváření více IPv6 směrovacích tabulek pro tato pravidla.
• Sada patchů s ovladači paralelního ATA.
• Sada patchů s labeled networking [značené síťování], která implementuje Commercial IP Security Option.
• Podpora architektury Atmel AVR32.
• Super-H podpora pro Titan, SH7710VoIPGW a I-O DATA Landisk desky.
• Velké aktualizace architektur PowerPC a S/390. S/390 má teď - kromě jiného - podporu KProbes.
• Nové ovladače pro externí flash na deskách ATSTK1000, sběrnice TI OMAP1/2 i2c, zařízení ESI Miditerminal 4140, RAID řadiče Areca, SCSI řadiče SuperTrak EX8350/8300/16350/16300, síťová rozhraní QLogic QLA3xxx, ethernetové adaptéry IBM eHEA a ethernetový řadič na deskách Cirrus Logic ep93xx. Začleněn byl také kontroverzní ovladač aic94xx, který napsal původně Luben Tuikov a od té doby byl upraven mnoha dalšími.

Změny viditelné vývojáři jádra:

• Hodnota CHECKSUM_HW byla v síťovacím subsystému dlouho využívána pro podporu hardwarové kontroly součty. Nyní je nahrazena hodnotou CHECKSUM_PARTIAL (určena pro odchozí pakety, u nichž musí práci dokončit hardware) a CHECKSUM_COMPLETE (pro příchozí pakety, které už byly hardwarem kompletně zkontrolovány).
• Množství změn v oblasti správy paměti, včetně sledování nečistých stránek v mapováních sdílené paměti, volitelnosti zón DMA32 a HIGHMEM a mechanismus pro sledování rozsahů paměti (a mezer mezi nimi) nezávislý na architektuře.
• Makra pud_page() a pgd_page() teď vrací ukazatel struct page místo virtuální jaderné adresy. Kód, který potřebuje původní funkci, by měl používat pud_page_vaddr() nebo pgd_page_vaddr().
• Množství změn v ovladačovém API, včetně paralelního hledání zařízení a vylepšení procesu uspání/probuzení.
• Nyní je k dispozici oznamovací řetěz pro situace, kdy je nedostatek paměti; smyslem je připravit funkce, které budou v případě potřeby schopné uvolnit nějakou paměť.
• Trochu se změnila sémantika API kmap(): na architekturách s komplikovanými problémy spojitosti paměti by kmap() a kunmap() měly spravovat spojitost mapovaných stránek, což by odstranilo nutnost explicitního vyprázdňování stránek z keše.
• PCI vrstva teď podporuje PCI Express Advanced Error Reporting [pokročilé hlášení chyb].
• Struktura inode doznala několika změn, které měly za cíl ji zmenšit.
• Byla přidána operace s adresním prostorem no_pfn().

Pokud vás zajímá, co ještě bude pravděpodobně začleněno, podívejte se na dokument od Andrew Mortona. Zajímavá je například další sada paměťových patchů (přičemž pokračuje debata o tom, jestli dává smysl mít ZONE_DMA volitelné), přepracování kódu protokolu síťového času, sada patchů s vektorovaným AIO (možná), dlouhá řada vylepšení NFS, eCryptfs (i když někteří jsou proti), různá vylepšení mapovače zařízení a RAID a množství změn obecné IRQ vrstvy.

Kromě toho Andrew plánuje začlenit pár patchů týkajících se kontejnerů: virtualizace jmenných prostorů utsname a IPC. Řekl k tomu:

Samo o sobě to nedává smysl, takže hraji na důvěru - zakládá se to na předpokladu, že Linux bude jednou mít kompletní virtualizaci jmenných prostorů s dostatečným pokrytím na to, aby to bylo uživatelskému prostoru k něčemu platné.

Normálně bych všechny takové funkce prostě podržel v -mm, dokud by nebyly něčím užitečné. Ale v tomto případě by šlo o spoustu příliš dlouho držených patchů. Takže začnu podobné menší kousky přesouvat do hlavního stromu.

Jednou z věcí, které nebudou začleněny, je Reiser4, který stále vyžaduje různé opravy. Vypadá to, že bude muset počkat na další vývojový cyklus.

Změny ovladačového API v 2.6.19

Linuxové ovladačové jádro se i nadále rychle vyvíjí. Sada patchů pro 2.6.19 v tomto procesu pokračuje několika vylepšeními - a také změnami API. Tentokrát to však vypadá, že změny spíše přidávají, takže by nemělo docházet k problémům se stávajícími ovladači.

Citlivou otázkou je doba trvání bootu Linuxu - není moc uživatelů, kteří by si přáli, aby jejich systémy nabíhaly pomaleji. Během bootu se děje mnoho věcí a existuje také mnoho způsobů, jak proces urychlit. Většina příležitostí k urychlení je na straně uživatelského prostoru, ale jádru může dlouho trvat hledání zařízení. Každé musí být nalezeno, inicializováno a připojeno k systému; součástí takové procedury může být čekání na boot periferních zařízení, natažení firmwarů nebo dokonce fyzické akce jako roztočení disků. V důsledku toho stráví jádro spoustu času nečinností - čekáním, až si své odbude samo zařízení.

Jako jeden ze zjevných způsobů urychlení tohoto procesu se jeví paralelní hledání zařízení. Jádro by tak mohlo v okamžiku čekání na odpověď jednoho zařízení nastavovat jiné. Zároveň by se naplno využily víceprocesorové systémy. Ovladačové jádro v 2.6.19 bude mít konečně možnost provozu v takovém režimu. První změnou je přidání parametru (multithread_probe) do struktury device_driver. Bude-li mít ovladač tento parametr nastaven, přesune se v okamžiku hledání vlastní nastavování daného zařízení do samostatného vlákna, které bude moci běžet souběžně s ostatními. Na konci inicializačního procesu jádro počká na ukončení všech nedokončených vláken a pak teprve připojí kořenový oddíl a spustí uživatelský prostor.

Na jednoprocesorových systémech vede tato změna k relativně malému snížení doby bootu. Ovladače obyčejně procesor během procesu hledání nepustí, takže k paralelnímu běhu není moc příležitostí - ani ve chvílích, kdy musí jádro chvíli počkat. Na víceprocesorových systémech však může být účinek o dost zřetelnější - každý procesor může zařízení hledat paralelně s ostatními. Tato změna bude tedy nejvíce užitečná na velkých systémech s mnoha připojenými zařízeními.

Přesněji: bude užitečná, až bude zapnuta; tato funkce je totiž v současné době označena jako "experimentální" a je s ní spojena řada varování. I když je povolena, týká se pouze PCI zařízení. Ne všechny ovladače byly napsány s ohledem na paralelní hledání, takže například nemají správné zamykání. Problémy mohou nastat i s odběrem elektřiny - současné zapnutí příliš mnoha zařízení může způsobit přetížení - pokud odběr přesáhne možnosti zdroje; výsledný požár by mohl boot dost výrazně zpomalit. Pořadí číslování zařízení bude pravděpodobně méně deterministické. A tak dále. Každopádně by však tato funkce měla časem vést ke zrychlení bootu - především u systémů, kde je dobře známý a stálý hardware (například u embedded aplikací).

Z jiného soudku: API, které se stará o uspávání a probouzení, bylo trošku zaplněno. Mechanismus tříd má teď své vlastní háčky [hooks] v struct class:

    int (*suspend)(struct device *dev, pm_message_t state);
    int (*resume)(struct device *dev);

Nová metoda suspend() je volána poměrně brzy v rámci uspávacího procesu a měla by se postarat o úkoly týkající se tříd. Mezi ně může patřit utišení zařízení a zastavení zpracovávání na vyšší úrovni. Metoda resume() je volána ke konci probouzení a měla by dokončit přípravu zařízení v třídě k provozu.

Většinu suspend/resume [uspávání/probouzení] však stále zajišťuje sběrnicový subsystém. Ta část API dostala tři nové metody struct bus_type:

    int (*suspend_prepare)(struct device *dev, pm_message_t state);
    int (*suspend_late)(struct device *dev, pm_message_t state);
    int (*resume_early)(struct device *dev);

Všechny tyto metody jen přidávají další místa, na která se kód sběrnice může zaháknout a provést, co potřebuje provést. Takže suspend_prepare() je volána brzy, dokud je systém pořád ještě v provozním stavu. Metoda suspend() se oproti předchozím jádrům neliší: je volána po zmrazení úloh a může spát, je-li to nutné. Nová metoda suspend_late() je naopak volána velmi pozdě, když už jsou vypnuta přerušení a běží jediný procesor. Při probouzení je resume_early() také volána při ještě vypnutých přerušeních a SMP a stará metoda resume() je volána později.

PCI subsystém tyto nové funkce zpřístupňuje prostřednictvím tří nových metod ve struktuře pci_driver:

    int  (*suspend_prepare) (struct pci_dev *dev, pm_message_t state);
    int  (*suspend_late) (struct pci_dev *dev, pm_message_t state);
    int  (*resume_early) (struct pci_dev *dev);

V hlavním jádře zatím nejsou žádné ovladače, které by tyto nové metody používaly.

A nakonec: subsystém tříd pokračuje v migraci k definitivnímu odstranění struktury class_device. Kvůli tomu se v struct class objevily další dvě metody:

    int (*dev_uevent)(struct device *dev, char **envp, int num_envp,
		      char *buffer, int buffer_size);
    void (*dev_release)(struct device *dev);

Poskytují podobné funkce jako metody uevent() a release v struct class_device.

V rámci této migrace byly také přidány dvě nové pomocné funkce:

    int device_create_bin_file(struct device *dev, 
                               struct bin_attribute *attr);
    void device_remove_bin_file(struct device *dev, 
                                struct bin_attribute *attr);

Tyto metody ovladačům umožní v sysfs vytvářet binární atributy aniž by musely pracovat přímo s kódem sysfs.

---

Následující obsah je © KernelTrap

Postoj vývojářů jádra k GPLv3

25. zář,

James Bottomley poslal do LKML text pojmenovaný "Nebezpečí a problémy GPLv3", který sestavilo deset nejaktivnějších vývojářů jádra. Text začíná zkoumáním podílu GPLv2 na úspěchu linuxového jádra a pak pokračuje poukázáním na některé potenciální nedostatky chystané GPLv3. Konkrétně se mluví o DRM ustanoveních: Přestože považujeme používání DRM mediálními společnostmi při pokusech o ovládání obsahu v zařízeních uživatelů za velmi znepokojující, brání nám víra v základní svobody definované v části 3 v přijetí licence, která by obsahovala omezení koncových uživatelů. Ustanovení o dodatečných omezeních: Část o dodatečných omezeních v současné verzi návrhu dělá z GPLv3 guláš možných omezení, která se budou tvůrcům distribucí velmi těžko právně postihovat. A ustanovení o patentech: Ze současného návrhu to vypadá, že by mohlo být potenciálně ohroženo celé patentové portfolio firmy jen kvůli umístění GPLv3 programu na jejich webovou stránku. Dokument uzavírá: Tři klíčové stížnosti popsané v části 5 jsou pro nás samostatně i dohromady dostatečným důvodem k odmítnutí současného návrhu licence. Rovněž však podotýkáme, že bez těchto nepřijatelných ustanovení představuje současný návrh přinejlepším jen velmi malou přidanou hodnotu oproti ověřené GPLv2.

Následná diskuze obsahuje mnohá objasnění od Linuse Torvaldse. Když se objevil názor, že si měl výslovně ponechat právo na úpravu licence celého jádra, poukázal na to, že to lépe funguje při současném modelu, kdy nemá pevnou kontrolu nikdo: Nezapomínejte, že perfektní je nepřítelem dobrého. Když chceš věci, které jsou "teoreticky" perfektní, většinou dopadnou "v praxi" hrozně. Takže když nemáme žádného šéfa, mohlo by to _teoreticky_ působit problémy. Ale _v praxi_ je to o dost lepší, než mít někoho, s kým je potřeba si dělat starosti. Také zdůraznil, že linuxové jádro není projekt FSF: Vždycky jsem to říkal velmi jasně: Linux je "open source". Nikdy nešlo o projekt FSF a vždycky bylo hlavní dávat zdrojový kód zpět a udržovat ho otevřený - nic jiného. A ještě upřesnil: Celé to přejmenovávání na "Open Source" proběhlo _právě_ proto, že se lidi chtěli od FSF distancovat. Skutečnost, že FSF a její stoupenci odmítli akceptovat název "Open Source" a dál nazývají Linux "Free Software", to není naše chyba.

Diskuse k tomuto článku

[Prcek]

výsledný požár by mohl boot dost výrazně zpomalit
Tak za tuhle vetu bych se nestydel dat smajlika

[thingie]

To by zkazilo ten efekt.

Já tleskám za dnešní druhý citát a líbí se mi i ten poslední odstavec.

[Petr (DotaZ) Jakubec]

taky myslim ze by to pak tak nevyniklo.

Zboznuju tenhle druh humoru v "profi" textu. kolikrat mi lidi neveri, ale takoveto perlicky jsou i v manualovych strankach. (pry i v kodu, ale tomu uz fakt nerozumimm tam by mi to asi uniklo).

[Robert Krátký]

takoveto perlicky jsou i v manualovych strankach

Běží, dokud nespadne

[Michal Ludvig]

ale takoveto perlicky jsou i v manualovych strankach.

man espdiff(1) z balicku patchutils:

You may find it useful to cross your fingers while the 
program performs its task, or to  screw  your eyes tight 
shut while imagining it doing the right thing.

Nebo:

OPTIONS
--deep-brainwave-mode
    Probes your brain deeply in a manner that takes longer, but 
    produces better extra sensory re-sults.


--recurse
    Recurses neural pathways throughout all parts of the brain, 
    in some  cases  determining  code changes  you  might make 
    far off in the future. You may feel a gentle tickling 
    sensation when using this option.

Nebo:

LIMITATIONS
Do not use this program while sleep-walking, or before your first cup of coffee.

[Prcek]

Ja si vzpominam jen na jednu vec - kdysi jsem kompiloval nejaky programek a pri ./configure to v jedne fazi vyhodilo "Warning: There is not enough beer in the refrigerator, please fix it" (nebo tak nejak, presne zneni si nepamatuju).

[Marián Kyral]

checking for intelligent life... not found

Gimp 1.2, configure script

[trekker.dk]

Páni, Gimp má integrované SETI...

[aubi]

Au, dostal mě SIGSEGV, umírám...

Aptitude neměl dost paměti

[Jirka]

Autor zrejme nepovazuje ctenare za blbce, kteri nepochopi vtip. A diky mu za to! V dnesni dobe, kdy na Internet pise kdekdo, to zacina byt dost vzacne.

[fissie]

Ja tedy nevim, ale podle me je tedy podpora routovacich pravidel pro IPv6 v kernelu uz davno, skoro bych rekl, ze od prvniho kernelu, kde se objevila podpora IPv6 . Routovacim pravidlem se rozumi jakykoli zaznam v routovaci tabulce a soudim, ze bez toho by IPv6 prilis uzitecny nebyl. Az anglicka verze me presvedcila o tom, ze se jedna o 'policy routing rules'...

Trochu me udivuje, ze slovo jako routing, ktere ma celkem i rozumny cesky preklad, nechavate byt, a prekladate slova jako capabilities, a to dosti bolestivym zpusobem.

Ale abych neustale nerypal, je skvele, ze Jaderne noviny vznikaji a rozhodne je uzitecne najit novinky z vyvoje kernelu pravidelne shrnute na jednom miste.

[Robert Krátký]

anglicka verze me presvedcila o tom, ze se jedna o 'policy routing rules'...

Chybka z nepozornosti podpořená jen matným povědomím o popisovaném tématu... omlouvám se.

Trochu me udivuje, ze slovo jako routing, ktere ma celkem i rozumny cesky preklad

Není to záměr. Prostě mi to nedošlo.

a prekladate slova jako capabilities, a to dosti bolestivym zpusobem.

Tam to záměr byl, protože pro neangličtináře je myslím těžké porozumět takovému nepřeloženému výrazu. Z možných variant překladu jsem se snažil vybrat tu nejvhodnější. U "routování" jsem se nechal zmást tím, že to všude čtu i slyším takto počeštěné -- místo abych se zamyslel nad tím, jestli neexistuje rovnou překlad.

[Boris Dušek]

Následuje seznam věcí, který si už do jádra našly cestu.

Překlep, mělo by být které. Anebo taky seznam, který si už do jádra našel cestu.

[thingie]

To jsou věci, který mi tu neřešíme Furt jenom spisovně, koho by to bavilo.

[Robert Krátký]

Dík.