Linus Torvalds: Linux 4.0-rc1

Kernel

Linus bezárta a beolvasztási időablakot (merge window), majd kiadta a soron következő kernel első prepatch-ét. A bejelentés tárgyából az is egyértelmű, hogy Linus dilemmája megoldódott. A 3.x kernelsorozat a 3.19-cel véget ér, a soron következő kernel pedig már 4.0-ként fog megjelenni.

Részletek a bejelentésben.

( trey | 2015. 02. 23., h – 10:13 )

"On the other hand, the strongest argument for some people advocating
4.0 seems to have been a wish to see 4.1.15 - because "that was the
version of Linux skynet used for the T-800 terminator"."

--
trey @ gépház

( persicsb | 2015. 02. 23., h – 13:03 )

Egy tisztán technikai komponenst (aminek 0 marketingértéke van) összevissza, logika nélkül verziózni, mert Linusnak éppen így van kedve, nem éppen arra vall, hogy Linus bármilyen minőségi, mérnöki szemlélettel rendelkezne a fejlesztés irányítása során.

Ez az egyik legegyszerubb distro kernel verzio formatum.
A hozza adott tagog:
- upstream stable versio
- distro patch level (nehe az is tobb reszbol all)

Ha megnezed hogy hasznalta linux a '2.6' -t rajosz , hogy egyutt a '2' + '.' + '6' volt majornak tekintheto.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az egesz verzioszamosdi a kompatibilitas meghatarozasarol szol.

Igy: ha egy distro mar patcheli a kernelt, akkor az egesz packaget nem linuxnak kellene hivni (hiszen maga a package neve, ez a szofver maga a Linux, a vendor altal szallitott csomag meg egy fork tulajdonkeppen), hanem mondjuk linux-redhat, es azt kulon kell verziozni.

Ez azert lenne igy logikus, mert ki tudja, hogy a patcheles soran milyen olyan funkcionalitasbeli valtozas tortenik, ami eltori a vannilla linux 4.0.1-hez kepest a kompatibilitast. Egy szoftver lehet, hogy kompatibilis a linux 4.0.1-gyel, de nem kompatibilis a linux-redhat 4.0.1-gyel.

Es meg mielott azzal jonnek az emberek, hogy a semver csak librarykre vonatkozik, ez nem igaz. A kompatibilitas megallapitasara szolgal, runtime fuggosegek eseten is.

Sot, ket parancssoros eszkoz is lehet egymassal kompatibilis meg nem kompatibilis, ugy is, hogy egyik sem library, peldaul teszem azt a diff v1.2.3 kompatibilis a patch v2.4.0-val, mert az egyik outputjat megeszi a masik, de a diff v2.0.1 mar nem kompatibilis a patch v2.4.0-val.

A distro patch level nem feltetlen a kodra vonatkoik, jelentheti ha valtozas csak a build scriptben tortent.
A distro patchek rendszerint:
* upstream backport
* biztonsag fokozo core patch
* A vanilaba (meg) nem befogadott a distro szamara fontos feature

A vanilla kernel nem a veg felhasznaloknak szol elsosorban, hanem a distributoroknak es fejlesztoknek.
Distrok nem szoktak eltroni a kompatibilitast (ez rendszerint az elsodleges celok kozott van),
nagyobb `kompatibilitasi ized lesz`, ha ki/be kapcsolnak egy build time config flaget.

Linux <=2.4 modjuk ugy kihalt, uj szoftvernel elegendo megnezni forditaskor hogy Linux -e rendszer,
regen neztuk hogy 2.4 vagy 2.6. Minden >=2.6 utan kiadott kernel 2.6 -nak szamit (Rendszerint a jelenleg is_26 fugvenyek szerint is) a 4.0 is '2.6'.

Amit az user-space softwernek csinalni kellhet, az a runtime feature test, nem lehet benne biztos, hogy be lett forgatva a feature.
Amit itt el szoktak b@szni:
* betoltok modulok listazasa, modul nev test. (A feature lehet hogy nem modulba van forditva)
* Linux build config olvasasa:
* a config parameterek nevenek nem valtozasa soha sem volt garantalva
* biztonsagi, vagy lustagi okokbol ez lehet nem is erheto el hasonloan a ksym hez.

3th party kernel modulnak kellhet aprolekos verzio testet csinalnia forditas idoben, bizonyos reszeknel.
Nezd meg modjuk az nvidia vendor drivert.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"jelentheti ha valtozas csak a build scriptben tortent."
Attol az meg egy fork lesz, nem a linux v4.0.1, hanem a linux-redhat v.4.0.1

"A vanilla kernel nem a veg felhasznaloknak szol elsosorban, hanem a distributoroknak es fejlesztoknek."
Epp ezert kene minden distronak megmondania, hogy o nem linux v4.0.1-et szallit, hanem linux-debian v4.0.1-et, linux-redhat v.4.0.1-et, hiszen mas es mas a funkcionalitas kore.
Es ekkor megmondhatja egy szoftvercsomag (pl. kulso kernel modul), hogy o kompatibilis a linux-debian v4.0.1-gyel, de nem kompatibilis a linux-redhat v4.0.1-gyel (hiszen mas backportok, distro szamara fontos feature-ok vannak benne, ami a vanillaban nincs).

"Distrok nem szoktak eltroni a kompatibilitast (ez rendszerint az elsodleges celok kozott van)," vs " A vanilaba (meg) nem befogadott a distro szamara fontos feature"
Ez eltori a kompatibilitast egybol. Es ne a userspace-re gondolj, hanem olyan kernelt hasznalo komponensekre, amik nem a syscall API-t hasznaljak, hanem kulso modulok.

"Amit az user-space softwernek csinalni kellhet, az a runtime feature test, nem lehet benne biztos, hogy be lett forgatva a feature."
Egyreszt a kernel nem kepes ezt biztositani a syscall API-n keresztul (nincs isFeatureAvailable hivas).
Masreszt a linux-redhat v4.0.1 pontosan egyfele feature settel kell, hogy rendelkezzel, ha te mas kernelt forditas, akkor az linux-turul16 v.4.0.1 lesz, amivel sok szoftver nem biztos, hogy kompatibilis.

"3th party kernel modulnak kellhet aprolekos verzio testet csinalnia forditas idoben, bizonyos reszeknel."
Es ezt az egesz aprolekos tesztet meg lehetne kerulni azzal, ha lenne ertelme a verzioszamoknak. Erdekes modon, Windows alatt ha lekerdezed, hogy a kernel verzioja 6.2.9200, akkor tudod, hogy milyen szolgaltatas erheto el es pont.

Hogy mit hivunk forknak es mit nem az ertelmezes kerdese.
* Def 1. az uj branch mas iranyt vesz es nem erdekli igazan mi tortenik az origin brachel
* Def 2. ha mar valtoztattal egy komenten a te verziodban akkor az egy fork.

Def 2. szerint fork, Def 1. szerint nem.

BTW: Mindegyik distro kernel uname-ja amiket lattam tartalmazta a distro nevet valagy.
Pl. Fedora: 3.18.5-201.fc21.x86_64
Gentoo eseten gentoo
...
Linus nem nagy branding manias, ugyhogy nem fog beperelni ha nem teszed oda,
mas projectel pl. docker vagy firefox bajaid lehetnek elozetes egyeztetes nelkul.

Te vagy az elso aki ugy tesz mintha nem tudna, hogy a default distro kernel rendszerint nem vanilla,
es sepcial extra minositest erdemelne.

A legtobb distrohoz, lehet talalni `vanilla` verziot is, rendszerit ez hamarabb lat napvilagot mint a distro verzio.

'isFeatureAvailable' -t tudsz irni, azott feautrurar ami erdekel.

" Es ezt az egesz aprolekos tesztet meg lehetne kerulni azzal, ha lenne ertelme a verzioszamoknak."
LOL. Nezd meg az nvidia drivert. Verzioszam tesztek vannak benne. A Verziozas monoton novekvo es nem random szam.
Es igen 2. szamjegy valtozasa utan is lehet, hogy valamit maskepp erdemes csinalni.
Es igne, a Linux kernelben 3 honap honap alatt mehet vegbe akkora valtozas mint mas rendszereknel evek alatt.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Meg mindit nem erted, nem a branding a lenyeg meg a copyright, hanem a kompatibilitas.

"Te vagy az elso aki ugy tesz mintha nem tudna, hogy a default distro kernel rendszerint nem vanilla,
es sepcial extra minositest erdemelne."
Ezt en nagyon jol tudom, epp ezert van az, hogy bizonyos szoftver mukodik debian kernellel, mas meg nem. Meg mindig nem erted, hogy mi a lenyege az egesznek. A kompatibilitas meghatarozhatosaga verzioszam alapjan (ugyanis a package managerek is igy mukodnek).

"LOL. Nezd meg az nvidia drivert. Verzioszam tesztek vannak benne."
Es erre az egeszre semmi, de semmi szukseg nem lenne, ha lenne ertelme annak, hogy "kompatibilis a linux-debian v3.05-v4.84.0 verziokkal vagy linux-redhat v4.0.4-v4.1.6 verziokkal egy csomag. De mivel a Linux verzio szamozasa semmilyen szemantikat nem kovet, es ugyanis a distro kerneleke sem, ezert ilyet nem lehet csinalni, es minden magara valamit is ado szoftver (lasd nvidia driver) kezzel csinal verzioellenorzeseket. Akkor mi a francnak kell a package managerben verziokat deklaralni?

Normalis verziokezeles tud ilyet:
http://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAV…

Maven ill. java artifactoknal ritka a build time config opcio.

Bele lehet hackelni, ilyenkor opciok szerint mas nevet szokas adni az artifactnak.

Az Nvidia cumot nem erdeli a distro,
A kernelben van macro a verzioszam lekerdezesre ill. a config opciok lekerdezesre is.
Az nvidia driverhez a `glue` resz mindig az adott kernellel `egyutt` fordul. Rendszerint a distributor altal.

Es kerlek ne keverd a verzio szamozast, meg build time opciokat.
Build time opciot nem fogsz tudni megmondani verziobol,
es veletlenul se kezdj el kapanyolni a build time opciok betiltasara, plane nem a linux kernel eseteben.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

En nem keverem.

"Maven ill. java artifactoknal ritka a build time config opcio.

Bele lehet hackelni, ilyenkor opciok szerint mas nevet szokas adni az artifactnak."

na, akkor megis at kene nevezni a linux v4.0.1-rol linux-redhat v4.0.1-re a dolgokat, nem? Hiszen mas a neve az artifactnak. Kitalaltak ezt mar masok, jol latod.
Peldaul ha van egy forraskod, es abbol tobb fele artifactot epitenek, pl. Maven profilokkal, akkor mas lesz az artifact neve, es ez igy van jol.

"Build time opciot nem fogsz tudni megmondani verziobol,
es veletlenul se kezdj el kapanyolni a build time opciok betiltasara, plane nem a linux kernel eseteben."
Ki kampanyol ellene? Mindig is azt mondtam, hogy nevezzek at az artifactot (a verzio qualifier nem artifact atnevezes).

Maven -nek nincs fogalma arrol hogy a te celjaidra barmelyik build jo, vagy 2 jo, 3 nem.
Explicite meg kell hataroznod egyet.

Tehat maven nem tudja azt ami nekunk kell by default.

Linux kernel varians ill. verziok eseten az alaklmazas futathatosaga nem verziotol, vagy build-tol fugg elsosorban.
A kerdes az hogy az adott kepeseget `provide` -olje az adott kernel.

A kernel es app parositasnal, a dependecy injectiont hasznalo modulok osszekapcsolasara hasonlo dolognak kell lefutnia a fejedben.

Nezzunk egy egyszeru peldat.:
pl. Egy proxy alkalmazas ki tudna hasznalni a splice(2)-t.
"The splice() system call first appeared in Linux 2.6.17"

splice(2) ha jol latom nem volt opcionalis, elvileg a verzio szam eleg lene, hogy megnezd van -e.
De ezert picsan rugas jarna.

Fejlesztes kozben fel merulo kerdesek:
Akkarunk splice -t nem tamagato verziot ? (igen)
Build time, vagy run time opcio legyen -e ?

Ha build time mellett dontesz, es valaki elviszi az appott egy splice-t nem tamogato
rendszerre, halalkor lehetsz olyan rendes es kiirod hogy splice az bizony kellett volna.

Az alkalmazas fuggosege: `Olyan Linux kernel ami tud splice-t`.

Mit irjunk a binaris dobozara ?
A, `Olyan Linux kernel ami tud splice-t`
B, Felsorolsz nehany distrot amitrol todod hogy megfelel.

Mit irjunk a splice()-t nem tamogato Linux build dobozara ?
Linux az adott archon ..

Ha futas ideju a dontes akkor http://www.gnu.org/software/libc/manual/html_node/Error-Codes.html ENOSYS a jutalmad a testnel, valthatsz a splice -t nem tamogato verziora.

Az alkalmazasa forras szerinit fuggosege jo eselyel csak POSIX, a binaris fuggosege jo esetben csak ugyan az arch es OS type (a dolgok amit gcc target opcio tartalmazni szokott).
Az alkalmazas ilyenkor, jobban tud futni splice -al, de nem szukseges.

Mit irjunk ilyenkor a Linux binaris dobozara ?
Minimum kovetelmeny: Linux az adott archon (ill. egyebeket amit gcc targetnel hasznalunk)
Javasolt kovetelmeny: Linux splice -al, (hint >=2.6.17).

Elmeletben ket hasonlo verzioju distro kernel nagyon eltero lehet,
de gyakorlatben nem. Beagyazott rendszereknel szokas csak feautre-t kikapcsolni, vagy ha
nem bizonyult megbizhatonak.

Minden generic kernelnek kepesnek kell lenie a distro altal szallitott tobb ezer app kozel idealis futatasara,
ez elege limitalja azt, hogy mit kapcsolhatsz ki. Es nagyon specialasnik kell lenie annak az appnak aminek a generic nem jo.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Maven -nek nincs fogalma arrol hogy a te celjaidra barmelyik build jo, vagy 2 jo, 3 nem.
Explicite meg kell hataroznod egyet."
Lépjünk egyel tovább, mert a jelenlegi csomagkezelés és verziózás egyiket sem tudja Linux körökben. Ha annyit tudnának, mint amit a Maven nyújt, az nem lenne rossz.

Egyel továbblépés az OSGi szemantika használata, ahol megadhatod, hogy a szoftvered milyen csomagokat, képességeket exportál (reexportálhatsz függőségeket is).

"Az alkalmazas fuggosege: `Olyan Linux kernel ami tud splice-t`." Ezt szépen le lehet írni OSGi-stílusú függőségekkel.

"Ha build time mellett dontesz, es valaki elviszi az appott egy splice-t nem tamogato
rendszerre, halalkor lehetsz olyan rendes es kiirod hogy splice az bizony kellett volna"
Ilyennek nem szabad lennie. Nem véletlenül létezik a csomagkezelő, nemde?

"Elmeletben ket hasonlo verzioju distro kernel nagyon eltero lehet,
de gyakorlatben nem. Beagyazott rendszereknel szokas csak feautre-t kikapcsolni, vagy ha
nem bizonyult megbizhatonak."
Pont te irtad, hogy vannak vendorok, akik betesznek nem mainline funkcionalitast a kernelbe, nem csak embedded eszkozon is.

"Lépjünk egyel tovább, mert a jelenlegi csomagkezelés és verziózás egyiket sem tudja Linux körökben. Ha annyit tudnának, mint amit a Maven nyújt, az nem lenne rossz. "
http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html…
http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.h…

"Ilyennek nem szabad lennie. Nem véletlenül létezik a csomagkezelő, nemde?"
Nem is distro packagel eshet meg.

"Pont te irtad, hogy vannak vendorok, akik betesznek nem mainline funkcionalitast a kernelbe, nem csak embedded eszkozon is."
Pax, unionfs/aufs, tux on ice .. ilyesmi szokott elofordulni, rendszerint spec eszkozre megy.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az RPM/Debian Provides IMHO nem tud verziokat.
Annyit tudsz mondani, hogy Provides: someCapability, de olyat nem, hogy Provides: someCapability v1.4.0
Lasd:
"A Provides field may not contain version numbers, and the version number of the concrete package which provides a particular virtual package will not be considered when considering a dependency on or conflict with the virtual package name."
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

Ugyanigy az RPM Provides definiciojaban sem latom, hogy meg lenne ez engedve.

Innentol kezdve pedig megint bukik a verziozhatosag: nekem kell a someCapability ver >=1.4.0, de ezt nem tudom kifejezni ertelmesen.

Provider: http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/tree/xorg-x11-se…
Requires: http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-evdev.git/tree/xorg-x11…
A requires-nel hasznalt macro valami ilyesmi https://github.com/RussianFedora/xorg-x11-server/blob/master/xserver-sd…

$ rpm -q --provides xorg-x11-server-Xorg | grep ansic
xserver-abi(ansic-0) = 4

$ rpm -q -R xorg-x11-drv-evdev | grep ansic
xserver-abi(ansic-0) >= 4

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Miért, a főszámnak (2,3,4) van? Jelenleg az egész kernelverziózás értelmetlen, a 2.6.39 (utolsó 2.6 release) és a 4.0 között lesz bármilyen koncepcionális eltérés? Más a modulrendszer? Más az architekturája a kernelnek? Szerintem nem. Innentől kezdve semmi értelme a fő/al stb verziózgatásnak, lehetne sorfolytonosan számozni az egészet, és jöhetne év végéig az 5,6,... release-ek sorozata.

Pontosan így értettem. Az utolsó szám maradjon meg arra, amire a 3.0 óta használják, az első kettőt meg vonják össze és 4.1 helyett jöjjön az 5-ös. A random major növelés/minor nullázás helyett így lehetne használni a tízes számrendszert, egy ideje jól működik néhány területen.

Egy biztos, én szeretem a friss dolgokat használni, mert hiszek benne, hogy az újabb az jobb is (különben mi a fenéért fejlesztenék), és ugye a fejlesztés egy része konkrétan hibák javítása. DE, a "stabil" verziók 0-s első kiadását már én sem nagyon szoktam használni, még saját gépen sem, annyira gyakori a durva regresszio, ami 1, 2. patchben lesz kijavítva. Hogy egy kicsit konkrétabb legyek, a btrfs miatt szoktam új kerneleket használni, és arra vonatkoznak ezek a regresszios tapasztalatok is. :)