Citáty jsou dneska nemálo vypečené 
.
.
Portál AbcLinuxu, 8. května 2025 03:07
Aktuální verze jádra: 3.1-rc8. Citáty týdne: Glauber Costa, Linus Walleij, Brett Rudley. Stav kernel.org. Stěhování lesů. Nový přístup k oportunistickému uspávání.
Aktuální verze jádra je 3.1-rc8 vydaná 27. září. Diffstat je opravdu drobný, vyčnívají jen patche v coretemp a clock_ops spolu s drobnou aktualizací perf-tool, vše ostatní jsou v podstatě jen jedno nebo několikařádkové změny. A ani těch není mnoho. Samotné vydání 3.1 ještě tak týden potrvá kvůli problémům s kernel.org, ale jinak jádro vypadá, že je skoro připravené.
3.1-rc7 vyšlo 21. září, jen pár mikrosekund po vydání Jaderných novin. Linus k tomu řekl:
Začíná být jasné, že konečnou verzi 3.1 nevydám dřív než po mé dovolené začátkem října – jinak by příští začleňovací okno byl naprostý chaos. Začleňovací okno s kernel.org mimo provoz by prostě nešlo a vydávat verzi a na to hned mít chaotické začleňovací okno následované cestováním se zdá být šílené.
Mimo jiné to znamená, že se příští začleňovací okno může překrývat s Kernel Summitem, což by samo o sobě mohlo být šílené.
Stabilní aktualizace: během posledního týdne žádné nevyšly.
Protože už jsem kvůli tomu poslal RFC, tak teď posílám RFD. Pokud vás zajímá význam, tak by to mohl být „Request for Doctors“ [Žádost o doktory], neboť Peteru [Zijlstrovi] teď asi hrozí srdeční infarkt.
A B C D E F G H
+---+
8 | o | o o o o o o o
| |
7 | o | o o o o o o o
| |
6 | o | o o o o o o o
+---+---+
5 | o | o | o o o o o o
+---+---+ +---+
4 o o o o o o | o | o
| |
3 o o o o o o | o | o
| |
2 o o o o o o | o | o
+-------+-------+-------+---+---+
1 | o o | o o | o o | o | o |
+-------+-------+-------+---+---+
Toto není tetris. Z her bychom mohli uvažovat o šachách.
-- pinmuxoví pěšci Linuse Walleije
Strávili jsme rok snahou být dobrými linuxovými obyvateli, předvedli jsme počáteční plány, dodržovali jsme pravidla, pracovali jsme transparentně, brali jsme ohled na zpětnou vazbu, přede všemi jsme zasílali stovky patchů a teď se nás lidi ptají, co je naším plánem. Naším plánem je dostat brcmsmac a brcmfmac do hlavní řady a následně přicházet s novými funkcemi, novými čipy a neutuchající podporou.
-- Brett Rudley
Vývojáři pracující na obnově kernel.org zaslali krátkou zprávu o stavu věcí, především o správě gitových stromů. Tato nová infrastruktura už nebude nabízet shellový přístup ke gitovým repozitářům; namísto toho se bude používat git s webovým napojením gitolite. Gitolite používá pro push ssh klíče, takže začneme aktivním vývojářům, kteří předtím měli na kernel.org účet, posílat nové údaje pro ssh.
V době psaní tohoto textu je kernel.org stále offline, ačkoliv se doufá, že alespoň přístup k gitovým stromům bude brzo obnoven. V Linusových plánech se zdá být otevření začleňovacího okna před polovinou října; bez funkčního kernel.org to nepůjde zdaleka tak lehce, jak by si komunita přála. Tak či tak nelze některé věci uspěchat a je důležité, aby se kernel.org vrátilo v solidním a bezpečném stavu.
Mezitím si řada stromů našla nový domov. Zde je aktualizovaný seznam přestěhovaných stromů:
| ACPI | https://github.com/lenb/linux.git |
| ALSA | git://github.com/tiwai/sound.git |
| ALSA driver | git://github.com/tiwai/alsa-driver-build.git |
| ALSA SOC | git://opensource.wolfsonmicro.com/linux-2.6-asoc.git |
| amd64 EDAC | git://amd64.org/linux/bp.git |
| APM | git://twin.jikos.cz/jikos/apm |
| arm-soc | git://git.linaro.org/people/arnd/arm-soc.git |
| DRM | git://people.freedesktop.org/~airlied/linux |
| fbdev | https://github.com/schandinat/linux-2.6 |
| HID | git://twin.jikos.cz/jikos/hid |
| hwspinlock | git://github.com/ohadbc/hwspinlock-next.git |
| infiniband | https://github.com/rolandd/infiniband |
| input | https://github.com/dtor/input |
| ipvs | git://github.com/horms/ipvs.git |
| kbuild | http://repo.or.cz/w/linux-kbuild.git |
| kvm | git://github.com/avikivity/kvm.git |
| libata | git://github.com/jgarzik/libata-dev.git |
| linux-next | git://github.com/sfrothwell/linux-next.git |
| mainline | git://github.com/torvalds/linux.git |
| mmc | git://dev.laptop.org/users/cjb/mmc mmc-next |
| networking | git://github.com/davem330/net |
| pm | git://github.com/rjwysocki/linux-pm.git |
| regmap | git://opensource.wolfsonmicro.com/regmap.git |
| SCSI | git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6.git git://bedivere.hansenpartnership.com/git/scsi-misc-2.6.git |
| slab | git://github.com/penberg/linux.git |
| tip | git://tesla.tglx.de/git/linux-2.6-tip |
| tmem | git://oss.oracle.com/git/djm/tmem.git |
| trivial | git://twin.jikos.cz/jikos/trivial |
| utrace | git://github.com/utrace/linux.git |
| v9fs | git://github.com/ericvh/linux.git |
| wireless | git://git.infradead.org/users/linville/wireless.git git://git.infradead.org/users/linville/wireless-next.git git://git.infradead.org/users/linville/wireless-testing.git |
| xen | git://oss.oracle.com/git/kwilk/xen.git |
Tento seznam přesunutých stromů je dost velký, avšak, jak správce linux-next Stephen Rothwell poznamenal 27. září, stále zbývá 89 stromů, které jsou jen na kernel.org. Tyto stromy od výpadku kernel.org nezaznamenaly žádné aktualizace. Některé z nich jsou určitě nečinné nebo k tomu mají blízko; ne každý strom, který dodává obsah pro linux-next, má patche v každém vývojovém cyklu. Ale existence ostatních má jistě důvod; pokud se kernel.org nevrátí brzo, budou si muset najít nový domov.
Jedním významným stromem, který se zatím nepřesunul, je strom stabilních vydání; poslední stabilní aktualizace vyšla 29. srpna.
S trochou štěstí se kernel.org brzo vrátí a tento seznam bude nepotřebný. Ale až se kernel.org vrátí, může vypadat poněkud jinak. Už bylo oznámeno, že ke strojům s gitovými stromy nebude shellový přístup. Můžou být zavedena i jiná bezpečnostní opatření, některé z nich mohou znamenat změny pro to, jak vývojáři pracují. Udělání takových změn v čase, který zbývá do dalšího začleňovacího okna, může být obtížné. Jinými slovy, vývojový cyklus 3.2 může být o něco zajímavější a méně plynulý.
"Oportunistické uspávání" je technika správy výkonu používaná na zařízeních s Androidem. Namísto snahy uvést různé částí systému do režimu nízké spotřeby funguje oportunistické uspávání tak, že prostě uspí celé zařízení, jakmile je zjištěno, že se neděje nic zajímavého. Takto spravovat spotřebu energie je kontroverzní, ale skutečným problémem je detekce toho, zda je dobrý čas se uspat. Androidí mechanismus pro řízení oportunistického uspávání byl nazván „probouzecí zámky“ [wakelocks] nebo „blokátory uspání“ [suspend blockers]; tak či tak to vždycky znamenalo klikatou cestu, jakmile se objevily pokusy začlenit tuto věc do jádra. John Stultz navrhl alternativu k blokátorům uspání, která má stejné problémy jisté, ale je každopádně zajímavé se na to podívat.
Blokátory uspání jsou způsobem, jak jádro nebo uživatelský prostor řeknou systému, že není správný čas se uspat; použití blokátorů z uživatelského prostoru je privilegovaná operace. Aby to fungovalo správně, blokátory uspání musejí být podporovány každým zařízením, které může probudit systém. Ovladače pro taková zařízení vytvoří blokátor uspání, kdykoliv dojde k probuzení, a probudí jakýkoliv proces z uživatelského prostoru, který na událost čeká; jakmile proces přečte událost, blokátor bude uvolněn. Klíčem je to, že daný proces z uživatelského prostoru, pokud má dostatečná oprávnění, může získat svůj vlastní blokátor, než přečte událost, která jej probudila. Překryv mezi získáním blokátoru v uživatelském prostoru a uvolnění toho v jádře umožňuje spolehlivé probouzení systému, aniž by bylo riskováno uspání dříve, než je událost zpracována.
Jednou z věcí, které se Johnovi nelíbily na tomto mechanismu, bylo implicitní API blokátorů uspání mezi uživatelským prostorem a zařízeními, která mohou probouzet systém. Proto přišel s něčím trochu odlišným, i když jádro myšlenky zůstává stejné.
Celým smyslem blokátorů uspání je umožnit „důležitým“ procesům udržet zařízení probuzené, i když by si jinak mohlo vybrat, že se uspí. Proto se John zeptal, proč takové procesy prostě neoznačit? Jeho patch přidává do plánovače novou volbu:
sched_setscheduler(0, SCHED_STAYAWAKE, ¶m);
Jakmile je takto nějaký proces označen, jádro systém jednoduše neuspí. Toto platí, i když daný proces blokuje; jinak by disková I/O operace nebo výpadek stránky mohly stačit k uvedení do uspání v nevhodnou chvíli.
V životě to ale samozřejmě není tak snadné; existují situace, kdy je žádoucí systém uspat, i když existují nějaké „důležité“ procesy. Příkladem je situace, když důležitý proces blokuje na zařízení, které je samo o sobě schopno generovat probouzecí události. Umožnění uspání v takových situacích si žádá poladění relevantních ovladačů; v zásadě musí být podobný řádek:
sched_deboost_task_active_count(current);
přidán, aby byl odstraněn status „důležitosti“ aktuálního procesu dříve, než je dán povel k uspání. Jakmile toto zařízení probudí blokovaný proces, jeho speciální status mu je navrácen.
Jediným zbývajícím problém je opět to zabránit systému, aby se zase uspal, než proces získá svůj status zpět. Toto je ošetřeno přidáním volání __pm_stay_awake() a __pm_relax() kolem kódu, který probouzí blokované procesy. John také musel změnit kód uspávání tak, aby __pm_stay_awake() bylo o něco méně jako doporučení, než jak je to v současných jádrech. Jakmile to bylo hotové, tak už nehrozilo, že se zařízení uspí, než důležité procesy dostanou šanci získat zpátky svůj status.
V době psaní tohoto textu byla jedinou zpětnou vazbou na tuto sadu patchů reakce od správce plánovače Petera Zijlstry. Postačí říct, že se mu to nelíbilo. Podle Petra je oportunistické uspávání snahou zakrýt problém, který by měl být vyřešen v uživatelském prostoru; řekl, že nedůležité procesy by v první řadě neměly běžet vůbec. Tento pohled na druhou stranu asi nebude moc oblíbený mezi lidmi od Androidu. Takže ačkoliv Johnovo přístup zjednodušuje myšlenku probouzecích zámků, nezdá se být pravděpodobné, že by uzavřel debatu kolem tohoto přístupu ke správě výkonu.
.
11.10.2011 10:40
Kaacz | skóre: 10
| Praha 4
11.10.2011 10:40
Kaacz | skóre: 10
| Praha 4
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.