Jaderné noviny - 3. 9. 2008

17. 10. 2008 | Jirka Bourek

Články - Jaderné noviny - 3. 9. 2008  

Aktuální verze jádra: 2.6.27-rc5. Citáty týdne: Linus Torvalds, Alan Cox, Daniel Phillips. Linux 3.0? Časovače s vysokým - (ale ne příliš) - rozlišením. SCHED_FIFO a přiškrcování v reálném čase.

Obsah

• Aktuální verze jádra: 2.6.27-rc5
• Citáty týdne: Linus Torvalds, Alan Cox, Daniel Phillips
• Linux 3.0?
• Časovače s vysokým - (ale ne příliš) - rozlišením
• SCHED_FIFO a přiškrcování v reálném čase

Aktuální verze jádra: 2.6.27-rc5

Současné vývojové jádro je 2.6.27-rc5 vydané 28. srpna. Nejvíc vzrušující (no, aspoň pro mě osobně - můj život je zjevně pěkně nudný) bylo to, jak jsme odchytili nějaká přetečení zásobníku, která totálně poškodila některé základní datové struktury vláken. Vzrušující je to proto, že tohle se nám už dlouho nestalo. Příčinou se ukázalo být poněkud příliš optimistické zvýšení maximální hodnoty NR_CPUS, ale také jsme se díky tomu podívali na spotřebu zásobníku obecně. Více vzrušení lze nalézt v kompletním changelogu.

Do repozitáře hlavní řady dál proudí opravy; předpatch 2.6.27-rc6 lze očekávat brzy.

Během minulého týdne nebyly vydány žádné stabilní verze. Aktualizace stabilních jader 2.6.25.17 a 2.6.26.4 jsou revidovány v době psaní tohoto článku; lze je očekávat 6. září nebo později.

Citáty týdne: Linus Torvalds, Alan Cox, Daniel Phillips

Zcela upřímně - většina programátorů není "pravděpodobně špatná". A jestliže si myslíš, že striktně-RT programátoři "praví muži" nejsou špatní, skutečně k tomu nemám co říct.

-- Linus Torvalds

Programátoři "praví muži" zírají na kód v zenovém rozjímání a ladí vypnutím a zapnutím - to je věc, kterou ani striktní RT procesy nepřekonají.

-- Alan Cox

Poslední dávka začlenění dostala Tux3 do bodu, kde se nepopiratelně chová jako souborový systém: lze do něj zapsat soubory, odejít, později se vrátit a číst je podle jména. Již můžeme vidět, jak se objevují některé jeho přitažlivé stránky: Tux3 zjevně škáluje od velmi malých po velmi velké. Máme exabytový soubor s velikosti bloku 4k a můžeme vytvořit 64petabytové soubory používající 256bytové bloky. To je skvělé, že? Interní fragmentace s 256bytovými bloky nemá moc šanci.

-- Daniel Phillips

Linux 3.0?

Tento měsíc se koná Linux kernel summit, takže do mailové konference Ksummit-2008-discuss jsou vhazována různá témata. Alan Cox navrhl jako téma k diskuzi vydání Linuxu, které by "vyhodilo" naakumulovaný a neudržovaný zastaralý kód. Byl by při tom rád, aby toto vydání bylo dobře propagováno a označeno novým číslem vydání, takže záměr dané verze by byl jasný. I když budou neshody o tom, které ovladače a subsystémy mohou být odstraněny, diskutující ve vlákně se zdáli být tomuto nápadu nakloněni - tedy alespoň tak, že se o něm má diskutovat.

Již teď je ustanoven proces pro označení zastaralých [deprecated] částí jádra a jejich pozdějšího odstranění, ale ten je používán poněkud namátkově. Alan navrhuje:

Někdy brzy přidáme staré ISA ovladače (s výjimkou těch divných, které se objevují v embedded čipových sadách na LPC sběrnici) do seznamu vlastností k odstranění [feature-removal] a vyhlásíme sváteční den 'smrti ISA', ve který vydáme 2.8 nebo 3.0 nebo něco, aby každý věděl, že jsme ho jednorázově pročistili 'vyhozením' starého smetí.

Také by to byla šance na vyhození celé hromady dalších "přestárlých" věcí jako ipt_tos, symlinky na bzImage, prastaré volby SCTP, prastarou podporu lmsensor, záležitosti okolo ovladačů pouze pro V4L1 atd.

Alanův seznam zažehl okamžité protesty proti některým věcem, které na něm jsou, ale nápad obecně byl přijat dobře. V jádře jsou rozhodně části, obzvláště týkající se staršího hardwaru, které nejsou spravovány a pravděpodobně vůbec nefungují. Nezdá se, že by měl kdokoliv zájem na tom nést tyhle věci dál, ale bez snahy identifikovat a odstranit takový kód je pravděpodobné, že zůstanou. Alan navrhl jeden způsob, jak to zajistit; diskuze na jaderném summitu by jeho nápad mohla pročistit nebo přijít s něčím úplně jiným.

Částečným důvodem pro to, že nespravovaný kód má tendence se v jádře držet, spočívá v tom, že jaderní hackeři se značně zlepšili v upravování veškerého kódu postiženého tím, že dělají nějakou změnu v API. I když je to rozhodně změna k lepšímu, vedlejším efektem je zároveň schovávání kódu, který už může být připraven k odstranění. V dřívějších dobách by mrtvý kód po jedné nebo dvou změnách API nešel přeložit, takže by buď zakročil správce, nebo by kód byl odstraněn.

Potřeba "velkého" vydání jádra s odpovídající změnou velkého nebo malého čísla verze je, zdá se, největší otázka, kterou jaderní vývojáři mají. Greg Kroah-Hartman se ptá:

Nemůžeme všechno uvedené výše udělat při zachování současného modelu? Nebo je skok na 3.0 jenom marketingová záležitost? Jestliže ano, můžeme prostě vybrat vydání a říct "2.6.31 je poslední jádro 2.6 a další tři měsíce budeme jenom trhat věci ven a tvořit 3.0"?

Alanův návrh obsahuje prvek "marketingu". Propagace velkého vydání společně se záměrem zbavit se "přestárlého" kódu umožní zainteresovaným společnostem zakročit a začít spravovat kousky, které nechtějí vidět na smetišti. Jak to řekl Alan:

Myslím si, že by mohlo být užitečné stanovit nějaké definitivní hranice, takže bychom se skutečně mohli dostat k vyhazování věcí místo toho, abychom je nechávali navždy hnít. Zároveň, pokud svoje úmysly sdělíme dobře, dáme lidem šanci upravit to, kudy ta čára vede a - ano - mezi jinými jde i o marketingovou záležitost, kde definujeme čáru tak, aby ji pochopil i tisk, netechnici atd.

Navíc to vyhovuje mému pojetí způsobu, jak open source dělá věci jinak - velké vydání, které se zbavuje starých krámů místo přidávání dalších nových šíleností, které lidi nepotřebují 8)

Arjan van de Ven si myslí, že vytváření seznamu věcí k odstranění je dobré cvičení:

Líbí se mi myšlenka o tom alespoň diskutovat s tím, že hromada lidí vytvoří dlouhý seznam věcí, které by odešly. Podle celého tohoto seznamu vznikne hodnotná diskuze/rozhodnutí; jestli je toho dost, aby se to vyplatilo.

Když byl seznam shromážděn a prodiskutován, Arjan poznamenal, že by to šlo udělat se současným vývojovým modelem bez velkého vydání. Nicméně udělejme to jako cvičení. Má cenu jednou za čas ověřit model, který máme ;)

Nemusí jít o jedinou diskuzi o číslech verzí jádra, která se na summitu odehraje. V červenci Linus Torvalds zmínil projekt natírání kůlny, který plánuje předložit. Zdá se, že Linus není zcela spokojen s tím, jak velké je malé [minor] číslo jádra; rád by viděl čísla, která mají větší smysl, možná založená na datu:

Jediná věc, o které vím, že s ní souhlasím, je, že "velká bezvýznamná čísla" jsou špatná. "26" je již docela velké. A jak upozorňuješ, série 2.4.x mají ještě větší čísla.

A ano, něco jako "2008" je zjevně číselně větší, ale má to přímý význam a je to možná lepší, než něco libovolně zvoleného a nepopisného jako "26".

Čísla verzí nejsou sama o sobě tak důležitá, ale mít konzistentní a dobře pochopitelné schéma číslování rozhodně je. Současný systém je na místě okolo čtyř let a nebylo příliš potřeba ho měnit. To stále může platit, ale nápady o jeho změně přicházejí z několika směrů, takže změna již může být na cestě.

Pro jaderné hackery je zisk malý - možná kromě prevence otrávenosti z neustále se zvětšujících čísel - nicméně číslování verzí poskytuje mechanismus pro komunikaci s "vnějším světem". Uživatelé očekávají občasné velké vydání s nějakým významných kusem změn, ale současné inkrementální vydávání jádra to číselně neposkytuje; místo toho velké změny přicházejí téměř v každém vydání jádra. Zviditelnit jedno konkrétní vydání může mít svou cenu, ať už jako prostředek jak jádro pročistit, či jak přejít na jiné schéma číslování verzí - možná obojí naráz.

Časovače s vysokým - (ale ne příliš) - rozlišením

Linux poskytuje mnoho systémových volání, která aplikaci umožňují čekat na to, až bude popisovač souboru připraven na I/O; zahrnují select(), pselect(), poll(), ppoll a epoll_wait(). Každé z těchto rozhraní umožňuje specifikovat časový limit, který určí horní hranici doby, po jakou bude aplikace zablokována. Jak je typické, podoba tohoto limitu se značně mění. poll() a epoll_wait() přebírají celé číslo udávající počet milisekund; select() přebírá struct timeval s rozlišením na mikrosekundy a ppoll() a pselect() očekávají struct timespec s rozlišením na nanosekundy.

Všechny jsou ale stejné v tom, že hodnotu tohoto limitu konvertují na jiffies, které mají maximální rozlišení mezi jednou a deseti milisekundami. Programátor může naprogramovat volání pselect() s časovým limitem 10 nanosekund, ale toto volání se nevrátí dřív než o 10 milisekund později, i když se nesoupeří o CPU. Chyba šesti řádů se zdá být poněkud velká, obzvlášť vzhledem k tomu, že současný hardware může snadno podporovat mnohem přesnější časování.

Arjan van de Ven se nedávno vynořil se sadou patchů, která má tento problém řešit. Jádro jeho nápadu je jednoduché: změnit kód implementující poll() a select() tak, aby použil časovače s vysokým rozlišením místo konverze časového limitu na jiffies s nízkým rozlišením. Tato implementace spoléhá na novou funkci, která časový limit poskytne:

long schedule_hrtimeout(struct timespec *time, int mode);

time je zde doba časového limitu interpretovaná podle mode (který je buď HRTIMER_MODE_ABS, nebo HRTIMER_MODE_REL).

Časovače s vysokým rozlišením jsou hezká vlastnost, ale lze si okamžitě představit problém: časové limity s vyšším rozlišením se pravděpodobně nebudou krýt s ostatními událostmi, které probouzejí procesor. Důsledkem bude víc probuzení a větší spotřeba energie. Věc se má tak, že je jenom málo vývojářů, kteří si toho jsou vědomi více než Arjan, který udělal poměrně dost práce zaměřené na to, aby byl procesor udržován ve spánku tak moc, jak je to jen možné. Jeho řešením tohoto problému je použít časové limity s vysokým rozlišením jenom v případě, že je čas kratší než jedna vteřina. Pro delší čekání se použije starý na jiffies založený mechanismus, který se používal již předtím.

Linusovi se toto řešení nelíbilo, protože ho považuje za "ošklivé". Místo toho preferuje, aby schedule_hrtimeout() aplikovala vhodné množství rozostření na všechny hodnoty časových limitů; čím delší doba, tím menší rozlišení by bylo poskytnuto. Alan Cox navrhl, že lepším mechanismem by bylo, kdyby volající poskytl požadovanou přesnost časové hodnoty. Problém tohoto nápadu, jak upozornil Linus, spočívá v tom, že současná rozhraní systémových volání neposkytují aplikaci žádný způsob, jak tuto hodnotu předat. Dalo by se uvažovat o vytvoření dalších systémových volání typu poll() - jako by jich už nebylo dost - s parametrem přesnosti, ale vytvoření nestandardního rozhraní, které by se obtěžovalo použít jenom málo programátorů, se zdá být zbytečně problematické.

Jiné řešení přišlo ve formě Arjanovy sady patchů časovačů s rozsahem [range-capable timer]. Patch rozšiřuje HR časovače tak, aby přijímaly dvě hodnoty časového limitu nazvané "měkký" a "tvrdý" limit. Měkká hodnota - ta menší - je nejkratší doba, za kterou může limit vypršet; jádro se bude co nejvíce snažit, aby časovač nevypršel později, než udává tvrdá hodnota. Mezi těmito dvěma může v jádře časovač vypršet v jakémkoliv vhodném čase.

Je to užitečná změna, ale přichází za cenu významných změn API. Pro začátek mizí pole expires ze struktury struct hrtimer. Místo toho, aby s expires jádro manipulovalo přímo, musí kód použít jednu z nových přístupových funkcí:

void hrtimer_set_expires(struct hrtimer *timer, ktime_t time);
void hrtimer_set_expires_tv64(struct hrtimer *timer, s64 tv64);
void hrtimer_add_expires(struct hrtimer *timer, ktime_t time);
void hrtimer_add_expires_ns(struct hrtimer *timer, unsigned long ns);
ktime_t hrtimer_get_expires(const struct hrtimer *timer);
s64 hrtimer_get_expires_tv64(const struct hrtimer *timer);
s64 hrtimer_get_expires_ns(const struct hrtimer *timer);
ktime_t hrtimer_expires_remaining(const struct hrtimer *timer);

Jakmile je to hotovo, jsou do HR časovačů přidány HR rozsahy. Ve výchozím nastavení jsou měkký a tvrdý čas vypršení stejné; kód, který si je přeje nastavit nezávisle, může použít nové funkce:

void hrtimer_set_expires_range(struct hrtimer *timer, ktime_t time, 
                               ktime_t delta);
void hrtimer_set_expires_range_ns(struct hrtimer *timer, ktime_t time,
                                  unsigned long delta);
ktime_t hrtimer_get_softexpires(const struct hrtimer *timer);
s64 hrtimer_get_softexpires_tv64(const struct hrtimer *timer)

V nových "set" funkcích je specifikovaný time měkký časový limit a time+delta poskytuje tvrdý limit. Také se mění podoba schedule_timeout():

int schedule_hrtimeout_range(ktime_t *expires, unsigned long delta,
                                                 const enum hrtimer_mode mode);

S touto infrastrukturou mohou být poll() a přátelům předány přibližné časové limity; jedinou zbývající otázkou je, jak široké by měly být jejich rozsahy. V Arjanově patchi tento rozsah pochází ze dvou zdrojů. První je nové pole v struktuře úlohy nazvané timer_slack_ns; jak by se dalo očekávat, specifikuje maximální očekávanou přesnost časovače v nanosekundách. Tuto hodnotu lze nastavit systémovým volání prctl(). Výchozí hodnota je nastavena na 50 nanosekund - v určitém ohledu je to stále nepřesné, ale i tak mnohem přesnější než časové limity v současných jádrech.

Kromě toho je zde také heuristická funkce, která poskytuje hodnotu přesnosti závisející na době požadovaného limitu. V případě obzvláště dlouhých limitů - delších než 10 sekund - je přesnost nastavena na 100ms; jak se limit zkracuje, přijatelná chyba klesá na minimum 10ns pro velmi krátké limity. poll() a spol. budou obvykle používat hodnotu vrácenou heuristikou, ale s tím rozdílem, že nepřesnost nikdy nepřekročí hodnotu timer_slack_ns.

Konečným výsledkem je zajištění přesnějších časových limitů pro dotazovací [polling] funkce při zachování možnosti zkombinovat jejich vypršení s ostatními systémovými událostmi.

SCHED_FIFO a přiškrcování v reálném čase

Plánovací třída SCHED_FIFO je dlouho existující realtime vlastnost specifikovaná normou POSIX. Procesům v této třídě je CPU dáno na tak dlouhou dobu, jakou chtějí, vzdát se ho musí pouze ve prospěch realtime procesů s vyšší prioritou. Pokud o procesor soupeří dva SCHED_FIFO procesy se stejnou prioritou, proces, který v danou chvíli běží, poběží tak dlouho, dokud se nerozhodne se procesoru vzdát. SCHED_FIFO je tudíž užitečná pro aplikace v reálném čase, kde chce člověk s velkou jistotou vědět, že proces s nejvyšší prioritou bude mít v systému přístup k procesoru tak dlouho, jak ho bude potřebovat.

Jednou z mnoha vlastností začleněných v cyklu 2.6.25 bylo skupinové plánování v reálném čase [realtime group scheduling]. Skupinový plánovač zavedl koncept "propustnosti v reálném čase" či rt_bandwidth, protože musí vyvažovat využívání CPU mezi soupeřícími skupinami procesů, z nichž každá může obsahovat úlohy v reálném čase. Tato propustnost sestává z páru hodnot: doby účtování času CPU a množství času CPU, které je skupině - při realtime prioritě - v daném čase dovoleno užít. Jakmile úloha SCHED_FIFO způsobí, že skupina překročí své rt_bandwidth, bude proces z CPU odstraněn, ať chce, nebo ne.

Tato vlastnost je zapotřebí, pokud chceme dovolit několika skupinám rozdělit si výpočetní výkon pro zpracování v reálném čase. Nicméně se také ukazuje, že má svoje využití i ve výchozí situaci, ve které jsou všechny procesy v systému obsaženy v jedné výchozí skupině. Jádra dodávaná od 2.6.25 mají pro výchozí skupinu hodnotu rt_bandwidth nastavenou na 0,95 z každé vteřiny. Jinými slovy skupinový plánovač ve výchozím nastavení rezervuje 5 % výpočetního času pro ne-SCHED_FIFO úlohy.

Zdá se, že tohoto stavu si nikdo nevšiml do poloviny srpna, kdy Peter Zijlstra zaslal patch, který výchozí hodnotu nastavuje na "neomezeně". V té chvíli se ukázalo, že někteří vývojáři mají jiný názor na to, jak by se tento druh politiky měl nastavit, než jiní.

Ingo Molnár s patchem nesouhlasil a řekl:

Věc spočívá v tom, že jsem dostal mnohem více hlášení o chybách se zaseknutými RT úlohami, kde byl zásek neúmyslný, než skutečných hlášení o komkoliv, kdo by měl v úmyslu nechat zadřít celý stroj, protože si RT úloha s vysokou prioritou přivlastnila CPU.

Ingo navrhl zvýšit limit na 10 sekund času CPU. Jak upozornil (a nejen on): jestliže nějaká SCHED_FIFO aplikace potřebuje mít procesor pro sebe po tak dlouho, pak má vážné problémy a je potřeba ji opravit.

S možností nechat SCHED_FIFO procesy běžet nekonečně dlouho jsou spojeny skutečné problémy. Pokud se takový proces rozhodne nikdy se CPU nevzdat, systém se navždy zastaví; administrátor nemá žádnou možnost prostrčit tam příkaz kill. Takový proces navíc zablokuje důležité věci jako jaderná vlákna; i když procesor po deseti vteřinách uvolní, vážně narušil fungování zbytku systému. I na multiprocesorovém systému budou typicky procesy svázané s tím CPU, kde proces se SCHED_FIFO běží; nebude možné tyto procesy obnovit bez narušení jejich afinity k CPU, což je krok, který nechce nikdo udělat.

Je tedy argumentováno, že limit rt_bandwidth je důležitá záchranná brzda. Když je na místě, ani splašené SCHED_FIFO nebrání administrátorovi (nakonec) získat zpět kontrolu nad systémem a zjistit, co se děje. Výměnou za tuto bezpečnost tato vlastnost obere SCHED_FIFO úlohy pouze o malé množství času CPU - což je ekvivalentem spuštění dané aplikace na o něco pomalejším procesoru.

Ti, kteří oponovali výchozímu limitu rt_bandwidth, citují dva hlavní body: je to změna API pro uživatelský prostor (která navíc narušuje splnění normy POSIX) a reprezentuje vnucení politiky jádrem. Co se prvního bodu týče, Nick Piggin má obavy, že tato změna by mohla vést k nefungujícím programům:

Nedává smysl tohle měnit. Bylo by zcela možné vytvořit proces v reálném čase, který špičkově používá 90 % CPU s 10% rezervou pro bezpečnost a další služby. Ty nyní mají jenom 5 %.

Aplikace v reálném čase také rozhodně může používat CPU adaptivně až do 100 %, ale přesto nemusí být schopna tolerovat neočekávanou preempci.

Co může tento problém zhoršit, je možnost, že se přiškrcení nemusí projevit během testování; místo toho může čekat, až se na produkčním systému stane něco neočekávaného. Není třeba říkat, že to je představa, která je pro lidi vytvářející a dodávající takové systémy děsivá.

Argument "politika v jádře" byl z větší části sestřelen Linusem, který upozornil na to, že jádro určuje mnoho politik, obzvláště když jde o výchozí nastavení laditelných parametrů. Řekl:

A výchozí politika by obecně měla být taková, aby dávala smysl většině lidí. Zcela upřímně, jestliže je to záležitost, kde by se od všech běžných dister očekávalo, že nastaví nějakou hodnotu, pak by ta hodnota měla být výchozí politikou a žádné běžné distro by se o ni nemuselo starat.

Linus se opatrně vyhnul zaujetí stanoviska k tomu, které nastavení dává pro většinu lidí smysl. Dalo by se rozhodně argumentovat, že zajistit odolnost systému proti převzetí splašeným realtime procesem je smysluplnější nastavení, obzvlášť když vezmeme v úvahu, že je určitý zájem na tom provozovat děsivé programy typu PulseAudio s realtime prioritou. Na druhou stranu lze věc chápat tak, že splnění standardu (a očekávání) sémantiky SCHED_FIFO je jediná volba, která vůbec dává smysl.

Objevily se různé zvěsti o vytvoření nové plánovací třídy pro reálný čas, u které by bylo přiškrcování explicitní součástí jeho sémantiky; tato třída by mohla být s příhodně nízkým limitem dána k dispozici i neprivilegovaným procesům. Mezitím v době psaní tohoto článku zůstává limit 0,95 sekund - ta volba, která se zjevně nikomu nelíbí - nezměněn. Téměř určitě bude zvýšen; na zjištění o kolik si budeme muset počkat.

Diskuse k tomuto článku

[YYY]

Cislovani verzi jadra by imho bylo nejlepsi ponechat tak, jak je. Celkem mi, u pro mne klicovych veci, nedela problemy pamatovat si, od jake verze kernelu je to podporovano.

[kavol]

problém je, když si člověk musí pamatovat také do jaké verze je to podporováno ...

třeba ta ISA, znám spoustu strojů, které mají ISA sloty a v pohodě zatím slouží, představa, že by se místo nich měly kupovat nové nebo že přijdou o možnost mít aktuální software, mi tak úplně super nepřijde :-/

[Mandarinka]

Oni jaderní hackeři to dělají tak, že už ve skutečnosi většinu ovladačů rozbili předem, takže křičet, že vám přestane HW fungovat, už není nic platné:)

Moje ISA karty například už nefungujou. jedna od té doby, co vykopnuli OSS ovladače ("ALSA funguje"), u ostatních nevím, kdy ovladače přestaly fungovat..

[trekker.dk]

A hlásil jsi to?

[Mandarinka]

Jak říkám, třeba ta zvukovka má léta nefungující ALSA (cs4237b; nicméně zřejmě pouze v některých případech, protože modul se považuje za funkční) a že OSS z jádra vyhodili jsem zjistil po cca roce, takže se na mě asi zvysoka vykašlou... nebo spíš řeknou, jděte hlásit do ALSA. Což jsem udělal, ale 1) staré stroje nikoho netankujou - nejsem guru, abych to dokázal nareportovat fakt kvalitně (dump etc). Takže pro všechno dohromady zřejmě můj report zůstal nezodpovězen a vzhledem k nejistému osudu nemám chuť se snažit o víc. Už jsem s tou zvukovkou strávil mnoho, mnoho hodin, a víc už ani nápad. Protlačil jsem do toho přístroje Win XP a vzhledem k tomu, že to všecko funguje (a o dost líp než předtím) to tak už zůstane...

[trekker.dk]

třeba ta ISA, znám spoustu strojů, které mají ISA sloty a v pohodě zatím slouží, představa, že by se místo nich měly kupovat nové nebo že přijdou o možnost mít aktuální software, mi tak úplně super nepřijde

Nakonec se nic vyhazovat nebude.

[David Watzke]

A i kdyby jo, tak by to neznamenalo, že člověk nebude moct mít aktuální software. Linux 2.4 se taky pořád vyvíjí...

[cronin]

Cislovanie verzii je dost osemetna zalezitos a bol som svedkom toho, ako pri niektorych sw produktoch architekti, dizajneri a manazeri venovali pramalo zaujmu o fungovanie sw, ale o cislovani artefaktov a celych vydani dokazali viest niekolkodnove porady. Problem release managementu je v tom, ze postihuje prakticky vsetkych zainteresovanych: zakaznika, marketingove oddelenie, support, etc. az po posledneho vyvojara.

Ja ako pouzivatel chcem od verzovania sw, aby mi umoznil:

- porovnat dve rozlicne verzie a rozhodnut, ktora z nich je novsia.

- urcit, od akej verzie je to a to podporovane alebo opravene.

Ako sw vyvojar naviac chcem, aby mi verzovanie sw umoznilo povedat, ze to a to je deprecated a bude to odstranene "vtedy a vtedy". Preto ako cisla verzii pouzivam YYYY.MM, napriklad takto. Rozlisenie na mesiace mi postacuje, kto ma agresivnejsie planovane vydania, nech si prida dni. Cislovanie podla datumu napr. umoznuje povedat, ze "Tato ficura je dnes -- v oktobri 2008 -- deprecated, ale bude dostupna este aspon rok." a pouzivatel vie, ze vo vydani 2009.11 uz nemusi byt dostupna. Inak povedane, verzovanie na zaklade datumov umoznuje odvolavat sa dopredu na este neexistujuce verzie.

Aktualne cislovanie jadra mi pride trochu neprakticke. Co vlastne vyjadruje major cislo 2 a minor cislo 6? Existuje politika urcujuca, kedy sa niektore z nich ma a kedy nema zmenit? Ak neexistuje, rovnako dobre cislovanie by bolo 1, 2, 3, ..., 42, ...

[vlk]

ako pri niektorych sw produktoch architekti, dizajneri a manazeri venovali pramalo zaujmu o fungovanie sw, ale o cislovani artefaktov a celych vydani dokazali viest niekolkodnove porady

Pretoze cislovanie verzii je to jedine o com si manazeri myslia, ze tomu rozumeju a chcu dokazat, ze dany projekt riadia.

Naposledy ma vytocila poziadavka, ze cislovanie verzii dodavanych k zakaznikovi sa musia zvysovat vzdy o jedna. Ak je niektora instalacia chybna, tak sa vymaze a s rovnakym nazvom ( a cislom verzie ) sa doda nova instalacka ... Tato poziadavka ich presla, hned ako som im vyprodukoval dve rozne instalacie s rovnakym nazvom, a oni sa mali rozhodnut, ktoru odnesu k zakaznikovi.

[cronin]

Pretoze cislovanie verzii je to jedine o com si manazeri myslia, ze tomu rozumeju a chcu dokazat, ze dany projekt riadia.

Nastastie to nie je vzdy pravda. Vo firme, kde pracujem, su project manazeri napodiv technicky zdatni a ak neovladaju tu ktoru technologiu, snazia sa do problemu vniknut aspon natolko, aby svoje projekty vedeli skutocne manazovat.

Naposledy ma vytocila poziadavka, ze cislovanie verzii dodavanych k zakaznikovi sa musia zvysovat vzdy o jedna.

Ale ano, aj tuto alternativu som zazil: nech to vyzera, ze nieco robime. To je ta nepochopitelna honba za cislom verzie: Java 1.0, 1.1, 1.2, 1.3, 1.4, 5, 6, ... Zaujimave je, ze relativne stare a vyspele programy ako QCad, GIMP ci Linux kernel su vo verzii 2.

[Field]

Ne ze bych cislovani Javy hajil, ale mezi verzemi 1.4, 5 a 6 jsou skutecne velke zmeny, nikoli "nech to vyzera, ze nieco robime".

[cronin]

Ano, samozrejme. Ale skok z 1.4 na 5 je stale akysi iracionalny.

[Filip Jirsák]

Jenomže žádný skok z 1.4 na 5 u Javy nebyl. Byl skok v platformě Java z Java 2 na Java 5, a zároveň s tím byl „skok“ ve verzích JRE a JDK od Sunu z 1.4 na 1.5. Ten „skok“ z 2 na 5 byl celkem racionální, teď souhlasí verze Javy s druhým číslem ve verzi JRE/JDK.

[Filip Jirsák]

Problém číslování podle data je v tom, že až (nikoli když…) se vám podaří vydat nějakou hodně nepovedenou verzi, ke které budete potřebovat vydat ihned záplatu, budete muset tu opravenou verzi vydat s datem v budoucnosti.

[Michal Vyskočil]

Proč v budoucnu? Prostě se vydá opravná verze datum.x.

[Filip Jirsák]

Verze 2008.08.1 ale už nesplňuje formát verzování YYYY.MM…

[PePa]

Bude se muset použít formát: počet vteřin od 1.1.1970. Pak můžete každou vteřinu vygenerovat špatnou verzi. A stačí jedna šťastná vteřina ročne, abyste byl úspěšným.

[Andrej Herceg]

To by problém nevyriešilo. Z toho čísla by nebolo jasné, či ide len o opravu nejakej staršej verzie, alebo je to úplne nová verzia.

[Michal Vyskočil]

Jenže číslování podle data není dogma, jak to tu prezentujete, ale konvence. YYYY.MM se může brát jako major číslo, nebo jako major.minor s tím, že se výchozí číslo vydání (0) prostě uvádět nebude. Hlavní je, aby bylo jednoznačné, že je 2008.08 starší, než 2008.08.1.

[Filip Jirsák]

Jako dogma jsem to neprezentoval já, ale autor komentáře, na který jsem reagoval. A snažil jsem se mu vysvětlit to samé, co píšete vy – číslovat verze datem je nevhodné; číslování verzí systémem, který je založený na datu, je jeden z použitelných způsobů číslování.

[Michal Vyskočil]

Přiznám se, že jsem v tom původním příspěvku nic takového nenašel, ale díky za osvětlení.

[Nicky726]

+1

[Robert Krátký]

Cislovani verzi jadra by imho bylo nejlepsi ponechat tak, jak je.

Díky za námět na anketu.

[mrzout]

jak má být v číslování podle let probíhat aktualizace staré verze?

dnešní stav: -jádra 2.2.*, 2.4.* a 2.6.* Lze bez problémů provést aktualizaci například nad 2.4 a očíslovat ji třetím číslem. Všichni vědí, která verze v této řadě je novější.

Je jasné, že staré verze by se nepřečíslovávali, ale pokud si pokusím tento stav převést do budoucnosti (protože stabilizovaných větví bude jistě více), jak by se číslovala dnešní 2.4? Pokud by byla 2001.03.* (měsíc fakt nevím, jen jsem tam něco plácl), tak nebude zřejmé, ze kdy jádro s úpravou v roce 2008 pochází.

[David Watzke]

To by mě zajímalo na co jim tam tedy doteď ty nanosekundový časovače byly, když ty polling funkce odpovídaji v řádu milisekund.

[thingie]

Bylo/je to jediné použití časovačů?