Greg Kroah-Hartman: Linux 2.6.11.1 ``sucker-tree''

Kernel

Új hivatalos kernelfa Greg Kroah-Hartman és Chris Wright vezetésével.

Abban a hosszú threadben, amelyben Linus új kernelszámozási módszert javasolt felmerült az ötlete annak, hogy a Linux kernel kiadási folyamatába be kellene építeni egy kis release engineering-et is. Linus egyetértett ezzel.

Mint írta, jelenleg van az -mm fa amelyben a veszélyes és kiszámíthatatlan patchek vannak, és van a saját fája, ami remélhetőleg stabil mostanra. Szerinte jól lenne, ha lenne egy harmadik fa is, de ő ebben nem szeretne részt venni. Ebbe a fába kerülnének a veszélytelen, és ahogy fogalmazott, unalmas patchek (bugfixek).

Az új fa megnyitásának több előnye is lenne:- csökkenne Linus terhelése

- az emberek hozzájuthatnának egy másik 2.6.x kernelhez + fixekhez

- nem lennének tesztelési problémák, mert biztos, hogy sokan tesztelnék a kernelt

Linus levelében leírta, hogy milyen szigorú szempontok alapján kellene megnyitni az új kernelfát. Greg K-H és az OSDL-es Chris Wright úgy döntöttek, hogy elvállalják a feladatot. Az új kernelfa a hivatalos 2.6 kiadások + bugfixek + biztonsági javításokból áll majd. A működéshez szükséges infrastruktúra a napokban ki lesz alakítva, de már meg is jelent az első kiadás.

Összeszedtem néhány kérdést és a (szerintem lehetséges) válaszokat:

K: Miben másabb ez a fa, mint a jelenleg is a stabilitást és biztonságot célzó -ac és -as fák?

V: Abban, hogy ez hivatalos, és Linus által felállított szabályok alapján kerülnek bele a patchek.

K: Bele lesznek építve az -ac és -as patchek is?

V: Greg szerint az egész nem, de ha valaki egyes részleteit elküldi hozzájuk ezeknek a patcheknek, és azok a részletek megfelelnek a felállított követelményeknek, akkor azok belekerülhetnek. Jeff Garzik szerint az -ac patchnek a 2.6.11.x-re kellene épülnie, és akkor az -ac-ben benne lenne minden javítás.

K: Ennek a fának a kiadásai be lesznek jelentve a kernel.org-on?

V: Igen, be lesznek, csak ki kell építeni a hátterét.

Az új kernelfa első tagjának bejelentése itt.

Totya!

"Az Nvidia pedig nem megy a 2.6.10, 2.6.11 vanilla kernellel."

Mar sokadszor emlited, ugyhogy csak beleugatok. En is vanilla kernelt hasznalok, meg nvidia-t, es nem volt soha gondom, ugyhogy nem kene annyira ezt eroltetni...

-(zsoltino@moonlight)-(4/pts)-(11:43/06-Mar-05)--

--($:~)-- cat /proc/version & cat /proc/driver/nvidia/version

Linux version 2.6.10 (root@moonlight) (gcc version 3.4.1) #2 Sun Feb 27 19:15:42 CET 2005

[1] 2455

NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-6629 Wed Nov 3 13:12:51 PST 2004

GCC version: gcc version 3.4.1

[1] Done cat /proc/version

--(zsoltino@moonlight)-(5/pts)-(11:43/06-Mar-05)--

--($:~)--

udv

( miq | 2005. 03. 05., szo – 10:56 )

Csodalatos! Egy ujabb ok arra, hogy a hardware-gyartok, ha csinalnak is Linuxos Drivert, azt csak a kereskedelmi disztrok altal hasznalt kernelverziokkal teszteljek. :-(

Ennyifele kernelhez egyik ceg sem fog fejleszteni.

No igen. Nekem is csak patch segítségével megy az NVIDIA driver 2.6.10 óta, és a vmware-hez is patch kell 2.6.11-hez. :-(

Azért ilyen a 2.4 szériában nem volt. Kezdem fontolgatni, hogy hagyom a saját kernel forgatást a fenébe, és a disztribekhez (éppen hol melyiket használom) kernelt fogom felrakni. 1.2-es verziótól kezdve saját kernelt használok. De megöregedtem, családos ember vagyok ;-)... és kezd elegem lenni.

Totya

( f0xhu v | 2005. 03. 05., szo – 11:59 )

linux 2.6.10.1.2.3.4.a.b.c.d.e.... nemjo ez :((

Most felfedezted a szarban az utoeret. Ez mondogatja Linus eleg regota. A disztributoroknak kell a felhasznalok fele az egyseges kerneleket mutatni. Soha sehol nem olvastam, hogy ok azt javasoljak egy vegfelhasznalonak, hogy kernel.org-os, -ac, -as, -mm, -mjb, -foobar, vagy barmi mas kernelt hasznaljon. Sot azt is ki merem jelenteni, hogy egy vegfelhasznalonak soha nem is kell LKML-t olvasni, nem kell ezekrol tudni. O kibontja a ki SuSE, Novell, Red Hat dobozat, es abban megtalalja a 2.6.10-smp-i686.rpm csomagocskajat, amit a vendor kitesztelt. Ot kurvan nem kell, hogy erdekelje, hogy melyik kernelfahoz kotelezte el magat a gyartoja. Ez all a 3party driver es alkalmazas gyartokra is.

Ki mondta neked, hogy az NVidia minden driverhez ad ki hivatalos drivert? Nem ad ki. Meg kell nezni, hogy mikhez ad drivereket. Az NVidia vagy az ATi szerintem sose mondta, hogy neked sajat kernellel kell hasznalni a stuffjat. Az, hogy te a 2.6.10-grsec-ck-sajat_hack_stuff_supermount_lop_*****_bakot_ugrik_vps_anim_boot_zenelogrub kerneledbe akarod beleeroltetni a kiadott drivereket az a te bajod.

Kb. egy fel eve en is hasonlo konkluziora jutottam, csak annyi kulombseggel, hogy a kernel forgatas maradt :) De nem a kernel.org-os kernelt hasznalom, hanem a gentoo-dev-sources-t ami a sima kernel megpatchelve, biztonsagi, bugfix, es egy ket plusz dologgal. Szoval ha valami gaz van a kernellel akkor nem nekem kell osszevadaszni a patch-eket hanem mecsinaljak helyettem :) Ilyen automount, reiser4, es hasonlo cuccokat meg nem hasznalok.

Nem tudom. Elkepzelheto.

Azok a disztrok amiket a vendorok, ISV-k komolyan vesznek nincsenek sokan. Red Hat, Novell-SuSE. Kihagytam valakit? Itt nem latok olyan nagy fragmentaciot. A tobbi N+1 disztroval nem igen foglalkoznak a gyartok szerintem. Egy SLES vagy Red Hat AS/ES kernele nem valtozik olyan gyakran, mint ahogy a szel fuj. AFAIK.

( ProTech | 2005. 03. 05., szo – 13:05 )

Akkor most ez lett a 2.6.paros / 2.6.paratlan helyett? Vagy meg mindig all ez a paros/paratlan dolog csak lesz ez is?

Gondolom az elso de sose lehet tudni :)

> linux 2.6.10.1.2.3.4.a.b.c.d.e.... nemjo ez :((

Nem tok mindegy a szamozas? Vedd ugy, hogy van egy 2.6-mm, egy
2.6-gregkh es egy 2.6-linus ag, aztan valaszd ki, hogy neked melyik a
tokeltes a stabilitas/bleeding-edge cuccok aranyaban es hasznald azt.
2.4-es kernelnel is volt fejlesztesi ag, csak itt mas az elnevezesi sema.

ilyenkor az egyetlen jarhato ut sajat kernel tree inditasa, ahol valogatod magadnak a patcheket :DD

viccet felreteve ez nem egy n+1. tree lesz remelhetoleg, hanem egy olyan dolog, ami hivatalos, es a 2.6 stabilitasat (annak megiteleset) jelentosen javithatja. a tobbi stabilitas/bugfix 2.6-faszagyerek tree alapozhat erre, nem uti, hanem segiti annak munkajat, es a kulonbozo szintu javitasokat (kritikus, egyszeru javitasok csak ebben a treeben) meg egy laikus is kulonvalaszthatja

amugy pedig a disztrib. kernel sem egy elitelendo dolog alapbol, ezzel a valtoztatassal is az volna a cel, hogy kozos alapja legyen ezeknek a kerneleknek, segitheti, hogy ne tavolodjanak el tulzottan a disztribuciok (ami nyilvan azert sem fog megtortenni, mert nekik sem erdekuk a karbantartasi munkat feleslegesen duplazni)

ha meg nem derult volna ki, en optimista vagyoK :)

Ez mind szep es jo, csak az a baj, hogy a Novell-SuSE illetve a RedHat disztrokra en valahogy soha nem tudtam "teljeserteku Linuxkent" tekinteni.

Masreszt eleve nem tetszik nekem ez a "user ne is akarja tudni, hogy hogyan mukodik" filozofia. A M$ is ezt a filozofiat kepviseli hosszu evek ota, es nezd meg mi lett belolle: olyan szinten lama emberek hemzsegnek a gepek elott, amilyeneket par eve meg elkepzelni sem tudtunk.

Harmadreszt szet kellene kicsit nezni a vilagban, es latni, hogy a fent emlitett disztrokon kivul meg letezik nehany, es a Linuxos kozosseg jelentos %-a hasznal Debiant, Gentoot, stb.-t. Es ezzel az ezernyi kernelfaval (meg a 2-3 kernellel futo driverekkel es programokkal) bizony ok fognak hatalmasakat szopni... :(

Negyedreszt, valoszinuleg a Gentoo/Debian/stb. felhasznaloktol nagysagrendekkel tobb (hasznalhato) bugreportot kap ugy a kernel, mint a kulonbozo software-ek, igy talan nem artana az o erdekeiket is figyelembe venni.

> Ez mind szep es jo, csak az a baj, hogy a Novell-SuSE illetve a RedHat disztrokra en valahogy soha nem tudtam "teljeserteku Linuxkent" tekinteni.

Miert is?

> Masreszt eleve nem tetszik nekem ez a "user ne is akarja tudni, hogy hogyan mukodik" filozofia. A M$ is ezt a filozofiat kepviseli hosszu evek ota, es nezd meg mi lett belolle: olyan szinten lama emberek hemzsegnek a gepek elott, amilyeneket par eve meg elkepzelni sem tudtunk.

Azt mondtam, hogy a vegfelhasznalonak. Ugye te se akarod azt mondani, hogy a Otthonigamer Ferikenek tudnia kellene, hogy hany kernelfa van, es hogy melyik mire valo?

> Harmadreszt szet kellene kicsit nezni a vilagban, es latni, hogy a fent emlitett disztrokon kivul meg letezik nehany, es a Linuxos kozosseg jelentos %-a hasznal Debiant, Gentoot, stb.-t.

Ez a szoftvergyártókat a legtobb esetben nem erdekli. Aki meg Debiant, Gentoot hasznal, annak nagy valoszinuseggel nem jelent gondot eldonteni, hogy melyik is valo neki.

> Es ezzel az ezernyi kernelfaval (meg a 2-3 kernellel futo driverekkel es programokkal) bizony ok fognak hatalmasakat szopni... :(

Milyen ezernyirol beszelsz? Kettorol tudok ami eddig szoba johetett:

-mm: nem javasoljak az atlag embernek, bleeding edge, inkabb fejlesztok nyuzzak. ebbe kerulnek a legujabb dolgok, eloszuro Linus fele

-linus: ez a Linus fa, ez a stabil kernelfa

Most ehhez jon majd megegy, ami csont ugyanaz, mint a -linus + a legfrissebb bugfixek, es sec frissitesek vannak benne. Linus rendszeresen (akar naponta) csinal majd ebbol egy bk-pull-t (ugye elolvastad a thread-et nem csak irogatsz). Magyarul a feladata, hogy a -linus kiadasok kozott is legyen egy gyakran kiadott verzio, ne kelljen olyan sokat varni, es le legyen jol tesztelve.

Marha nagy dilemma. Reszemrol az -mm kiesik, mert nem vagyok fejleszto, es nem igen erdekel, hogy hetente egyszer kicserelik az utemezoket. Eddig a -linus fat hasznaltam, de ha a -gregkh gyorsabban fog kijonni, akkor elkepzelheto, hogy azt kovetem majd. Hol latsz te itt meg mas hivatalos kernelfat?

(Most azt, hogy Wannabe Pistike csinal holnap egy -wannabe fat, es azt bejelenti az LKML-en (mert miert ne tehetne meg?) nehogy mar ideszamitsuk. lol lenne kicsit.)

( nevergone v | 2005. 03. 05., szo – 18:21 )

Valóban egyetértek ezzel az új kenelfával, remélem karbantartása rendszeres és szakszerű lesz. És egyetértek trey -jel is, hogy az átlagusernek úgyis elég az a kernel, amit az általa készített terjesztés összeállít és szállít... aki pedig maga akar kernelt "bányászni", az remélhetőleg úgyis tudja, mit akar. Ha pedig nem, akkor magára vessen.

Csak azt nem tudom így hirtelen, hogy akkor mi a helyzet az -mc [www.hup.hu] patch-készlettel...? Mert erről nagyon kevés híradás esik, ha létezik még egyátalán. :)

> a Linuxos kozosseg jelentos %-a hasznal Debiant, Gentoot, stb.-t. Es
> ezzel az ezernyi kernelfaval (meg a 2-3 kernellel futo driverekkel es
> programokkal) bizony ok fognak hatalmasakat szopni... :(

greg-kh Gentoo developer, szoval szerintem csak jol jarnak a Gentoo
userek... :) Eddig is eleg komoly munkat vegzett a kernel team, most
talan picit konnyebb lesz a dolguk, ha masok is besegitenek egy
stabilabb alap fa keszitesebe.

> Ki mondta neked, hogy az NVidia minden driverhez ad ki

> hivatalos drivert?

Én nem mondtam, hogy tegye ezt... csak tényt állapítottam meg.

> Az, hogy te a

>2.6.10-grsec-ck-sajat_hack_stuff_supermount_lop_*****_bakot_ugrik_vps_anim_boot_zenelogrub

>kerneledbe akarod beleeroltetni a kiadott drivereket az a te bajod.

Tévedés. A kernelem nem ugrik bakot! :-D

Egyszerű vanilla kernelt használok csak. Csak egy pptp-mppe patch-et rakok csak hozzá. Ez meg kell a céges bejelentkezéshez. Az Nvidia pedig nem megy a 2.6.10, 2.6.11 vanilla kernellel. Ehhez egy kicsit mókolni kell az Nvidia installeren. A vmware pedig a 2.6.11-rc2-ben eltávolított skb_copy_datagram miatt nem megy. Ha ezt visszarakod, akkor megint van vmware.

Részemről egyébként nem tartom rossz ötletnek az új fát. Csak leírtam a tapasztalatom, és elnézést kérek amiért "vanilla" "stable" kernel-t mertem felrakni a gépemre. :-D

Totya

Miután felraktam a kernel-t és rebootoltam a linux-om, a vmware közölte, hogy most akkor ő újra építené a modulokat és legyek oly kedves futtatni egy vmware-config.pl parancsot. Na ez nem tudta a vmnet modult megcsinálni. Vmware 4.5.2-8848.

Miután google-ban találtam egy megjegyzést ezzel kapcsolatban (http://lkml.org/lkml/2005/1/22/60), és alkalmaztam a patch-et, már meg is csinálta a modult vidáman.

Totya