Jaderné noviny - 7. 7. 2015: Začleňovací okno 4.2 část 3.

1. 11. 2015 | Redakce

Články - Jaderné noviny - 7. 7. 2015: Začleňovací okno 4.2 část 3.  

Jaderné noviny: Stav vydání jádra. Citáty týdne. Začleňovací okno 4.2 část 3.

Stav vydání jádra

Současné vývojové jádro 4.2 bylo vydáno 5. července. Podle Linuse 4.2 možná nebude vývojovým cyklem s největším počtem commitů, ale stále se toho hodně děje. „Ovšem když spočítáte celkový počet všech řádků změněného kódu, zjistíte, že se, s milionem přidaných řádků (a čtvrt milionem smazaných řádků), skutečně jedná o největší rc, které jsme tu zatím měli. Čímž poráží předchozího šampiona (3.11-rc1), který byl velký hlavně vzhledem k tomu, že došlo k přidání Lustre do staging tree.“ Zdrojem největšího kusu nových řádků je grafický ovladač amdgpu.

Stabilní updaty: 3.14.47 a 3.10.83 byly vydány 6. července. Updaty 4.1.2, 4.0.8, 3.14.48 a 3.10.84 jsou v procesu revidování, k jejich vydání by mohlo dojít 10. července.

Citáty týdne

Mám za to, že jste nikdy neviděli démonickou zář v očích autora překladače pomýšlejícího na všechen ten kód, k jehož poškození může dojít,^W^W^W^W^W^W^W^W všechny ty optimalizace umožněné nedefinovaným chování při přetečení celých čísel se znaménkem?

-Paul McKenney

Nakonec skutečně dojde k nesmyslné konverzaci a Jens bude muset přiznat, že ještě *stále* neuvolnil svůj internetový obchod s akčními figurkami inspirovanými vývojáři jádra jako open source.

-Chris Mason

Správci mají tendence stát se správci, protože byli dobří v něčem jiném, ale ne dost dobří ve skrývání se před rolí správce. Je zde paradox, jelikož správce musí být dobrý v tom, říkat „Ne“, ale kdyby skutečně byl, nikdy by nesouhlasil s tím, že se stane správcem.

-Neil Brown

Kernel Summit 2015: Výzva k předkládání návrhů

Letošní Kernel Summit se bude konat ve dnech 26. až 28. října v Soulu. Výzva k návrhům pro diskuze je nyní otevřená. Teď je vhodná doba pro ty, kteří by se summitu rádi zúčastnili, aby přišli s dobrým tématem, který by mohl trochu rozproudit diskuzi. Výzva je otevřená do 31. července.

Začleňovací okno 4.2 část 3.

V době, kdy Linus vydal 4.2-rcl a 5. července uzavřel začleňovací okno, bylo do hlavního repozitáře začleněno celkem 12 092 neslučovacích sad změn. Čímž se, dle názoru vašeho editora (ale ne Linusova názoru, viz níže), 4.2 stala nejrušnějším začleňovacím oknem v historii projektu a porazila předchozího rekordmana, verzi 3.15, o 58 commitů. Ani tak si Linus nemyslí, že by se 4.2 mohla stát nejrušnějším vývojovým cyklem, a to z jednoho prostého důvodu: naučili jsme se lépe opravovat chyby v kódu předtím, než se dostanou do hlavního repozitáře, takže je zapotřebí méně oprav. Jestliže předpokládáme, že 3.15 měla vyšší počet oprav než 4.2, potom 4.2 nedosahuje na celkový počet 3.15.

Naštěstí se dají tyhle myšlenky celkem jednoduše ověřit pomocí čísel, takže zde můžete vidět historii několika posledních let, zobrazující celkový počet neslučovacích změn pro každé vydání jádra:

Vydání	Začleňovací okno	Celkem	% oprav
v3.0	7333	9153	19.9
v3.1	7202	8693	17.2
v3.2	10214	11881	14.0
v3.3	8899	10550	15.6
v3.4	9248	10899	15.1
v3.5	9534	10957	13.0
v3.6	8587	10247	16.2
v3.7	10409	11990	13.2
v3.8	10901	12394	12.0
v3.9	10265	11910	13.8
v3.10	11963	13637	12.3
v3.11	9494	10893	12.8
v3.12	9479	10927	13.3
v3.13	10518	12127	13.3
v3.14	10622	12311	13.7
v3.15	12034	13722	12.3
v3.16	11364	12804	11.2
v3.17	10872	12354	12.0
v3.18	9711	11379	14.7
v3.19	11408	12617	9.6
v4.0	8950	10346	13.5
v4.1	10659	11916	10.5
v4.2	12092	?	?

Od počátku řady 3.x se každé vydání jádra dočkalo v průměru 13,6 % oprav po uzavření začleňovacího okna. V době mezi vydáními 3.15 a 4.1 bylo začleněno 71 416 změn a z toho 8 452, tedy 11.8 %, po uzavření začleňovacího okna. Takže se můžeme domnívat, že se množství kódu, které se do mainline dostane po uzavření okna, oproti loňskému roku snížilo. V případě, že se podaří udržet 11,8% míru, bude 4.2 dokončena s celkovým počtem 13 709 změn, tedy o 13 méně, než jak tomu bylo u 3.15.

Takže je možné, že se 3.15 udrží coby nejrušnější vývojový cyklus, i když váš editor je toho názoru, že je stále předčasné dělat nějaké závěry.

Dlouhodobý trend je v každém případě jasný:

Celkově se komunita vyvíjející jádro při začleňování kódu, který nevyžaduje opravy později ve vývojovém cyklu, skutečně zlepšila.

Poslední změny ve 4.2

Od minulého týdne bylo do hlavního repozitáře přidáno dalších 1200 changesetů. Mezi nimi například:

• Velké x86 systémy nyní mohou odložit inicializaci většiny hlavní paměti, čímž dojde ke zrychlení bootu.
• Došlo k začlenění změn, které ovlivňují způsob nakládání s mounty sysfs a /proc. Podadresáře, které mají sloužit jako mountpoints (připojovací body)(např./sys/debug), jsou takto nyní označovány a mounty jsou omezeny na tyto adresáře. Kromě toho byla přidána nová pravidla, která mají zajistit, že nové mounty těchto souborových systémů (například v rámci kontejneru) respektují mount příznaky použité existujícími mounty. Kontroverzní prosazování příznaků noexec a nosuid bylo prozatím odstraněno.
• Procesory Synopsys DesignWare ARC HS38 jsou nyní podporovány. Další nový hardware zahrnuje přepínače režimu letadlo Dell, LED ovladače TI TLC59108, LED zábleskové ovladače Maxim max 77693, LED ovladače Skyworks AAT1290, LED ovladače Broadcom BCM6328 a BCM6358, zábleskové ovladače Kinetic Technologies KTD2692, programovací časové syntetizéry TI CDCE925, časovače Hisilicon Hi6220, LPC STMicroelectronics watchdog, Conexant Digicolor SoC watchdog, Dialog DA9062 watchdog a ovladače dotykových obrazovek Weida HiTech I2C.
• Implementace červeno-černého stromu nyní podporuje „uzamykací stromy“, ty uchovávají dvě kopie stromových struktur souběžně a upravují pouze jeden strom po druhém. Výsledkem je, že non-atomické modifikace se mohou dít současně s vyhledáváním, aniž by došlo k jejich záměně. Viz. tento commit o implementaci a tento commit o diskuzi o použité technice. Prvním využitím této techniky je zrychlení vyhledávání adresních modulů.

Pokud tempo vydrží (a Linus si nevezme další špatně načasované volno), bude finální verze vydání 4.2 k dispozici 23. srpna.

Dovětek

Někteří čtenáři by mohli přemýšlet o tom, proč tento článek tvrdí, že 4.2 je nejrušnějším vývojovým cyklem, když Linus řekl ve svém oznámení o vydání 4.2 něco jiného:

Ukázalo se, že vydání 3.15-rc1 mělo víc commitů než 4.2-rc1 (i když jen těsně) takže pokud si spočítáte počet commitů, ani tak se nejedná o největší rc1 vůbec.

Rozdíl je v tom, že Linus počítá začleňovací commity, zatímco váš editor nikoli. Jak bylo napsáno výše: Celkově bylo pro 4.2-rc1 získáno (pulled) 12 092 neslučovacích sad změn, toto číslo ovšem narostlo na 12 809 sad změn, když počítáme začlenění, čili jsme těsně za 12 826 pro 3.15-rc1. Úvaha editora o vynechání sloučení je taková, že se většinou jedná o přesuny patchů z jedné větve do druhé, čímž se skutečně liší od „skutečných“ vývojových přístupů. O tom, že někdo jiný bude mít jiný názor, není pochyb.

Diskuse k tomuto článku

[Jendа]

Má nějakou výhodu mít ovladače pro triviální zařízení jako různé teploměry nebo třeba to TLC59108 jako driver v kernelu? Mně přišlo naprosto přirozené, aby do toho I2C data posílal userspace démon.

[sdfdf]

Mne napadaju vyhody ako ze programatori to nemusia (znovu) programovat a nevyzaduje to dalsieho demona, co moze byt vyhoda na jednocipoch. Inak uplne suhlasim a do kernelu by som to necpal.

[pc2005]

No bylo by zajímavý rozdělit vývoj kernelu na hlavní část a externí drivery (nebyly by to drivery mimo kernel, ale jen mimo věci jako plánovač apod.). Otázka je zda by se ten vývoj dokázal udržet a pokud ne, tak by to stejně skončilo v kernelu .

BTW některý teploměry exportujou stav pro hwmon. I na blbou GPIO ledku můžeš navázat třeba led heartbeat (nebo jinou leds aktivitu).

[Harvie.CZ]

podle me je uplne jedno, jestli to bude v kernelu nebo v systemd ja osobne sem teda proti tomu aby to bylo v userspacu, pac pak mame miliony demonu, kazdej ma jiny api, jinak reseny prava pro komunikaci se zarizenim a je v tom bordel. navic takovy veci jako userpace demon kterej podle teploty procesoru nastavuje otacky vetracku mi pripadaj fakt psycho. co kdyz userspace zamrzne kvuli bugu, spatne nastavenymu nice, nebo pac vsechen vykon sezerou chrome s flashem? pocitac shori nebo minimalne spadne.

[pc2005]

Ono jde o monolitičnost kernelu, ty drivery by klidně mohly být mimo samotné jádro. To by se pak mohlo vzpamatovat z pádu třeba driveru těch ledek. API by klidně mohlo být stabilní.

[Jendа]

API potřebuješ do userspace stejně jako do kernelu.

Z mého pohledu jde o to, že userspace umím debugovat od té doby, co mi ukázali, jaká písmenka mám náhodně mačkat v gdb, dokud to nezačne fungovat. Kernel je pro mě pořád něco tajemného. Možná je to jenom pocit a také je to jednoduché…

[R]

Kernel sa debuguje pridavanim printk, na tom nie je nic tajomne :D

[Michal Kubeček]

A když se nezadaří, pořád je tu ještě crash.

[Pali]

Kernel je pro mě pořád něco tajemného.

A to je možno dobré, najpr treba jazyku porozumieť a až potom skúšať čo spraví ten kód s cudzým HW... Ľudia, čo robia v Jave alebo C# sú čiastočne od vývoja kernelu oddelný, lebo si na to len tak netrúfnu.

[TT]

Co takhle přepínání kontextu a s tím spojená režie? Myslím, že tohle se diskutovalo už několikrát jenom teď nemůžu najít odkaz. Nepamatujete někdo?

[R]

Pri nejakom blbom teplomeri na pomalej I2C zbernici je to uplne jedno.

[tom]

Má nějakou výhodu mít ovladače pro triviální zařízení jako různé teploměry nebo třeba to TLC59108 jako driver v kernelu? Mně přišlo naprosto přirozené, aby do toho I2C data posílal userspace démon.

LEDky se pouzivaj pro debugovani, takze ty by byly v kernelu stejne a navic kernel ma nad I2C/SPI abstraktni rozhrani, takze implementace v kernelu spociva vpodstate v definovani adres. Navic by se musel udelat novej interface, protoze stavajici interface je spartanskej a nenabizi zadna omezeni v pristupu k jednotlivym zarizenim, takze chyba v userspace demonu by mohla rozbit celej system. Proste to nestoji za to.

[Atom321]

No, mít driver teploměru (nebo TLC59108) v jádře je jednodušší. On ten driver celkem nic moc nedělá, jen zformátuje zprávu (dotaz na I2C), předá ji driveru I2C řadiče, pak parsuje odpověď a získané číslo vystaví přes virtuální souborový systém. Driver I2C řadiče i VFS jsou v jádře, vkládat mezi ně komunikaci s userspace démonem je zbytečná komplikace.

[HonzaRez]

Pro lékaře je výhodné, když měří teplotu v kernelu...

[pc2005]

Procesory Synopsys DesignWare ARC HS38 jsou nyní podporovány.

Hmm takže si můžu na Intel čipset (AMT/MEI) nainstalovat linux? Cool!