Jaderné noviny – 14. 8. 2014: Další návrhy na řešení problému roku 2038

3. 9. 2014 | Luboš Doležel | Jaderné noviny | 5694×

Aktuální verze jádra. Citáty týdne: Dave Airlie, Alan Cox. Stultz: O řešení problému s rokem 2038. Začleňovací okno 3.17, část druhá.

Obsah

• Aktuální verze jádra
• Citáty týdne: Dave Airlie, Alan Cox
• Stultz: O řešení problému s rokem 2038
• Začleňovací okno 3.17, část druhá

Aktuální verze jádra

Začleňovací okno 3.17 je v době psaní tohoto textu stále otevřené, takže není žádné vývojové jádro.

Stabilní aktualizace: aktualizace 3.15.9, 3.14.16, 3.10.52 a 3.4.102 vyšly 7. srpna. Greg varuje, že řada 3.15 se už dočká jen jediné aktualizace, proto by její uživatelé měli uvažovat o přechodu na jinou řadu.

Citáty týdne: Dave Airlie, Alan Cox

Jako všechny dobré žádosti o přetažení, i tato končí vrácením změn, takže jsme to nepochybně otestovali.

-- Dave Airlie

Lhaní aplikacím obvykle dopadá jako když děti lžou rodičům – udržování lži se stává čím dál složitějším, než se to celé zhroutí.

-- Alan Cox

Stultz: O řešení problému s rokem 2038

Pro ty z vás, které zajímá problém roku 2038, je tu zajímavý příspěvek od Johna Stultze. Popisuje podstatu problému, kroky, které jsme zatím učinili, a naše možnosti do budoucna.

[...] Agresivnější verzi předchozího návrhu říkám „Nová virtuální architektura“, v podstatě se verzování rozšiřuje od linkeru až do jádra. Šlo by o přidání nové „virtuální architektury“ do jádra, tolik by se to nelišilo od podpory x32 na x86_64. Vytvořili bychom úplně nové ABI a název architektury v jádře (mám na mysli něco jako „armllt“ nebo „i386llt“). Kompatibilita se staršími aplikacemi by byla zachována přes personalities („osobnosti“), což je mechanismus podobný podpoře 32bitových aplikací na 64bitových jádrech. V tomto případě bychom do jádra nezaváděli nová 64bitová volání, jelikož stávající rozhraní by zkrátka měla správné typy pro naší novou virtuální architekturu, mělo bychom ale duplicitní rozhraní pro systémová rozhraní přes rozhraní compat.

Složitost navíc by pak představovalo to, že bychom museli na 64bitových systémech podporovat nové 32bitové prostředí pro kompatibilitu. Uživatelský prostor by bylo nutné kompletně překompilovat, aby byla nová architektura -llt podporována, a podpora pro staré aplikace by byla zajištěna pomocí stejného principu „multiarch“, který se teď dělá kvůli spouštění 32bitových aplikací na 64bitových systémech.

Výhodou pro tuto situaci by bylo to, že by bylo velmi jednoduché ověřit, že aplikace přešly na nové 64bitové ABI pro time_t. Jelikož navíc v jádře víme, o jaký typ aplikace jde, bylo by snazší pracovat s problematickými oblastmi jako IOCTL s využitím příznaku ve struktuře úlohy (task).

Nevýhod je celá řada. Distribucím se tento nápad bude asi hodně příčit, jelikož vyžaduje rekompilaci všeho a udržování další legacy architektury. Nejsem si také zcela jist, jak moc robustní je při 3 až 4 architekturách používání multi-arch balíčků. Z hlediska jádra jde o další zesložiťování, kdy musíme do 64bitových systémů přidávat přidávat další komplexní vrstvu pro kompatibilitu kvůli podpoře všech možných 32bitových aplikací. [...]

Začleňovací okno 3.17, část druhá

V době přípravy článku Linus do jaderného repozitáře přetáhl již 9894 neslučovacích sad změn pro vývojový cyklus 3.17; to znamená 3750 změn od souhrnu z minulého týdne. V posledních dnech se nárůst zpomalil; Linus zjevně cestuje a nakonec dorazí na Jaderný sumit 2014, který začíná 18. srpna.

Mezi zajímavější změny viditelné uživatelům přetažené od minulého týdne patří:

• Patche pro memfd a zapečetění souborů byly začleněny. „memfd“ je oblast paměti identifikovaná popisovačem souboru, který je možné předávat mezi procesy. Zapečetění souborů umožňuje procesům zmrazit obsah memfd a zabránit tak dalším úpravám. Tyto funkce mají hrát klíčovou roli v blížícím se subsystému kdbus.
• K dispozici je nové systémové volání kexec_file_load(). Umožňuje jádru provádět kontrolu podpisu nového jádra, než do něj systém nabootuje. To by mělo nervózním distributorům umožnit povolit funkčnost kexec na systémech běžících v prostředí UEFI Secure Boot.
• Do subsystému SCSI přibyla počáteční podpora vícero front (multiqueue). To by mělo přinést vyšší výkon a škálovatelnost. V tomto vydání se kód považuje za experimentální a je ve výchozím stavu vypnutý; pro zapnutí je třeba použít parametr modulu use_blk_mq.
• Virtualizace KVM nyní funguje na big-endian systémech architektury ARM.
• „Vykreslovací uzly“ DRM, které poskytují přístup k vykreslovacímu hardwaru v grafických procesorech nezávisle na displeji, jsou nyní standardně zapnuté.
• Z jádra byla odstraněna podpora starých architektur POWER3 a rs64. Tyto architektury byly po několik vydání evidentně rozbité a nikdo si toho nevšiml. Byla také odstraněna podpora pro systémy Samsung S5P6440, S5P6450 a S5PC100.
• Podpora nového hardwaru.

Mezi změny viditelné vývojářům jádra patří:

• Hlavní kód pro ovladače ALSA nyní dokáže pracovat v situacích, kdy je k jedinému rozhraní pro digitální zvuk připojeno vícero kodeků.

Za obvyklých podmínek by začleňovací okno 3.17 bylo uzavřeno 17. srpna. Linus ale řekl, že by okno mohlo zůstat otevřené déle, aby tak vynahradil čas, který stráví cestováním, což by mu mohlo umožnit dokončit začleňování při volných chvílích na Jaderném sumitu. Nezávisle na tom, jak to vlastně dopadne, bude v příštím vydání Jaderných novin přehled posledních začleněných patchů.

       

Komentáře

[dvcasxcasdc]

misto, aby se reklo, ze od verze xyz uz je jadro opravene s ohledem na velikost casovych typu. a ze od te chvile se musi distra prizpusobit a prekompilovat, tak se to furt nejak obchazi. co kdyby se ted reklo, ze za 5 let, musi byt vsecko pripraveno, jadro i user-space.

[ebik]

A co s binarkami programu dodavanych napriklad k ruznym dnes jiz nevyrabenym zarizenim? Vetsinou je tomu sumak jestli to ma spravny cas, ale pouziva to treba stat() na soubory. Takovymto rozhodnutim by tyto programy prestaly fungovat a s nimi moznost ovladat prislusna zarizeni z (noveho) linuxu. Tyto binarky jsou casto staticky linkovane, aby si vyrobce usetril problemy s instalaci, zavislostmi a drobnou nekompatibiltou mezi verzemi knihoven. Je mozne ze to nakonec dopadne tak jak pisete a podpora pro takove programy bude zahozena. Ale take je mozne, ze tyto binarky pujde spustit v nejakem legacy rezimu, treba s posunutou epochou. A o tom to rozhodovani je.

[Jendа]

LD_PRELOAD jako když se shitware nedokázal srovnat s tím, že se změnila major verze jádra. A příště se vyhnout závislosti na blobware.

Tyto binarky jsou casto staticky linkovane

V krajním případě jaderný wrapper. Furt lepší než zdvojnásobit počet 32b architektur.

[Jendа]

Viděl bych problém v tom ostrém přechodu, že s novým jádrem potřebuju úplně nový userspace a není to vůbec zpětně ani dopředně kompatibilní (jako že když se něco rozbije, tak už nenabootuju).

[mankind_boost]

Nestacilo by pridat nove syscally pro vsechno, co se tyce casu a v glibc udelat soucasné nazvy fci jako presmerovavaci makro na tyto nove fce? Rekompilovane programy by pouzivaly tyto nove fce/syscally, stare by stale fungovaly (38kou by trpeli porad, ale to nijak rozumne vyresit nejde). Tot muj naivni napad.

[Jose]

+1

[ajtacka]

Ono to možno je už opravené, len na nejakej vesmírnej stanici, na Marse alebo kde to môže fungovať tie intervaly trocha inak. Prečo sa musí počítať neustále nejaká (mili?)sekunda a to pomaly od počiatku dejín, teda od roku 1970 či kedy :D

Čiže keď niekto chce počítať, v akom stave je ročné obdobie pre poľnohospodárov, pomôžu tieto zázraky 1970 niečo rozumné dopočítať?