Linus Torvalds: Linux 3.0-rc1

Címkék

Úgy tűnik, hogy győztek Linus fejében a hangok, mert a korábban előrevetített major verziószám ugrás bekövetkezett a Linux kernel életében. 15 évet kellett várni erre az eseményre, hiszen a 2.0-s Linux kernel 1996 közepén jelent meg. Hogy milyen nagyobb változások érkeztek a 3.0-s kernel első kiadásra jelölt változatával? "SEMMI. Abszolút semmi. Persze megvan a szokásos kétharmadot kitevő driver változás, egy rakás javítás itt-ott, de a lényeg az, hogy a 3.0 *kizárólag* az újraszámozásról szól és mi nagyon *nem* csinálunk itt egy KDE-4 vagy egy GNOME-3 szintű dolgot."

Részletek a bejelentésben.

Hozzászólások

/me rettento kivancsi hany script torik el vilag-szerte emiatt.

Foleg hogy x.y.z formarol (3.0.0) atallnak x.y (3.0)-ra, meghagyva a .z-t a -stable teamnek, akik eddig egy negyedik szamot biggyesztettek a vegere.

--
|8]

Volt arrol is szo: azzal az volt baj allitolag, hogy akkor nem sorfolyamatos a verzioszamozas, pl 3.0 3.1 3.2 az mind letezo verzioszamok (lesznek?), ugyanakkor datum alapjan nyilvan nem minden ket verzio kozotti numerikus ertelmben vett tetszoleges verzio valos, mivel datum alapjan van krealva, az meg a kiadasok datumat mutatja. Hogy ez miert baj, azon persze lehetne gondolkodni.

Szerintem teljesen logikus lepes: 2.6 alatt a 6 kb csak disznek volt, nem valtozott, fuggetlenul attol, hogy mennyire alakult at alatta a kod az evek soran, ugyhogy 3.x alatt szepen kiutik, mert minor verzionak sokkal jobb az az x, mint patchlevelnek. Korrektebbul jelzi a valtozas merteket is, es a -stable kerneleknel meg lehet a patchlevel a harmadik.

A paros/paratlan kernelek 2.6-al megszuntek, igy a .6-nak, es ami utana jott volna, ha nem 3.x lesz belole, nem sok ertelme volt mar.

Ment szepen a levesbe :P

--
|8]

Felőlem azért fordulhatott volna a dolog a patch szintű változatnál. 2.6.49 után 2.7.0 jöhetett volna.

Így, hogy nincs lényegi változás és mégis főverziót ugortak, ezt soknak tartom. Illetve lásd fent, ha kétszámos verziót akartak, akkor is jöhetett volna 2.7 vagy 2.8 .

közellenség leszek, de...

ez segít egy minimális mértékben a linuxdesktopyear eljövetelében, mert a nagyobb verzióval talán jobban el lehet adni a fejlődést.

------------------------------------------
Egyetlen vi-parancsot ismerek, a kilépést.

Leüthetem? Legalább legyen egy kis flame is, lévén nem értek a programozáshoz:
"Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.) The individual function organization isn't that important, but the different data structure padding is very important."

Ez megkerülhető mappinggal, vagy merev struktúrák használatával. Igen, mindkettő szopás, de az előbbi esetében tök mindegy mi, hova kerül a memóriába, az utóbbinál, meg biztos, hogy minden, mindig ugyanoda kerül a memóriában.

"Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel:"

" different structures can contain different fields"

Miéééért?

" Some functions may not be implemented at all, (i.e. some locks compile away to nothing for non-SMP builds.)"

Ez esetben talán okos lenne dummy implementáció.

" Parameter passing of variables from function to function can be done in different ways (the CONFIG_REGPARM option controls this.)"

Az egységes API háttere ott kezdődik, hogy az ilyen dolgok fixálva vannak.

" Memory within the kernel can be aligned in different ways, depending on the build options."

Ez feltétlenül szükséges, vagy csak a szokásos fejlesztői onanizálás?

"Linux runs on a wide range of different processor architectures. There is no way that binary drivers from one architecture will run on another architecture properly."

Szvsz, erre megoldás a dedikált architektúra kijelölése, és a többi architektúra kernel szintű bináris fordítóval való támogatása. Ronda, erőforrásigényes, de a gyártó imádnák, mert csakis egy architektúrán kell fordítani és tesztelni a kódot. De, akkor már mehetne a kernel fejleszttés egy virtuális architektúrán is.

"Now a number of these issues can be addressed by simply compiling your module for the exact specific kernel configuration, using the same exact C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific Linux distribution. But multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each Linux distribution release contains a number of different kernels, all tuned to different hardware types (different processor types and different options), so for even a single release you will need to create multiple versions of your module.

Trust me, you will go insane over time if you try to support this kind of release, I learned this the hard way a long time ago... "

Pont ez a lényege a stabil APInak. Megfelelő definícióval és implementáció esetén sem a kernelnek, sem a modulnak nem kell tudnia, hogy mivel és milyen opciókkal volt a másik fordítva. A legnagyobb hátrány, hogy megköveteli a fejlesztőket, hogy egy adott infrastruktúra mentén legyen a fejlesztés, és ne lehessen quick&dirty, félig, negyedéig implementált modulokkal az adott eszköz támogatásának a látszatát kelteni. Ez pillanatok alatt lefelezné a támogatott hardverek számát, de nem kéne a mezei usernek fél éjszakát molyolnia, hogy rájöjjön, miért nem megy amúgy alap funkció a gépén. (Lásd: open-source broadcom modulok és az encrytion key esete)

"Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

As a specific examples of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem. These reworks were done to address a number of different issues:

A change from a synchronous model of data streams to an asynchronous one. This reduced the complexity of a number of drivers and increased the throughput of all USB drivers such that we are now running almost all USB devices at their maximum speed possible.
A change was made in the way data packets were allocated from the USB core by USB drivers so that all drivers now needed to provide more information to the USB core to fix a number of documented deadlocks.
"
Bullshit. Faszán megmagyarázza a tervezés teljes hiányát és még meg is veregeti a fejlesztők vállát. Ezek a reimplementációk jól jellemzik az egész open-source fejlesztési modellt. Igen látáványos changelogokat eredményez, csak épp a használhatóságot csapja agyon.

"This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This provides the ability for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer."

Újabb bullshit. Ezt ugyanis kompatibilitásnak hívják. Egy zárt forrású fejlesztő cég nem égethet fel minden hidat a hátamögött annak megfelelően, hogy a cégvezető milyen hangokat hall éppen. Ugyancsak előfordulhat, hogy az új fejlesztő szeretné, ha az alkalmazása régebbi OS-eken is futna. Pont ezeknek a fejlesztőknek az életét könnyíti meg a gyártó.

"In both of these instances, all developers agreed that these were important changes that needed to be made, and they were made, with relatively little pain. If Linux had to ensure that it preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the USB developers. Since all Linux USB developers do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility."

Azért csak kibújik a szög a zsákból. Ugye egy új, fényes kód polírozása mindig nagyobb dicsőség, mint egy régi karbantartása.

"Security issues are also a very important for Linux. When a security issue is found, it is fixed in a very short amount of time. A number of times this has caused internal kernel interfaces to be reworked to prevent the security problem from occurring. When this happens, all drivers that use the interfaces were also fixed at the same time, ensuring that the security problem was fixed and could not come back at some future time accidentally. If the internal interfaces were not allowed to change, fixing this kind of security problem and insuring that it could not happen again would not be possible.
"

A tervezés vajon mi? Vajon hány security issue ezek közül, ami a hiányos tervezés következménye? Nem egyszerűbb elkerülni ezeket, ha már a tervezéskor figyelembe vannak véve? Egen, csakhogy a hello.c után nem lehetne hirtelen, mindenki kernel hacker...

Végül az ideologizálás:
" The quality of the driver will rise as the maintenance costs (to the original developer) will decrease."
Ez kétséges.
" Other developers will add features to your driver."
Vagy épp kivesznek, különféle ideológiák mentén.
" Other people will find and fix bugs in your driver."
Vagy épp elcseszik.
" Other people will find tuning opportunities in your driver."
Amitől aztán működésképtelenné válik.
" Other people will update the driver for you when external interface changes require it."
Lásd fennt.
" The driver automatically gets shipped in all Linux distributions without having to ask the distros to add it."
Ezzel megszűnik a lehetőség, hogy csakis olyan formában kerüljön a driver a kernelben ami biztosítja a teljes működőképességét.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

>"Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel:"
>
>" different structures can contain different fields"
>
>Miéééért?

Pl. Debug trace modok miatt.

Egyes strukturak joval kisebbek lehetnek, ha kikacsolsz kerenel featurakat, pl: 687 struct user_struct
Nyilvan ott ahol nem kell ez pazarlas.

Nem mindeki akar pl. namespaceket, SMP kernelt vagy selinuxot.

A task_struct is erdekes.

>
>" Some functions may not be implemented at all, (i.e. some locks compile away to nothing for non-SMP builds.)"
>
>Ez esetben talán okos lenne dummy implementáció.

Minek egymagos rendszereket buntetny dummy hivasokkal? Annak CPU ido koltsege van.
>
>" Parameter passing of variables from function to function can be done in different ways (the CONFIG_REGPARM option controls this.)"
>
>Az egységes API háttere ott kezdődik, hogy az ilyen dolgok fixálva vannak.

Ez az ABI resze. Ill. source compatibilitas szempontjabol irrelevans.

>" Memory within the kernel can be aligned in different ways, depending on the build options."
>
>Ez feltétlenül szükséges, vagy csak a szokásos fejlesztői onanizálás?

Igen.
>
>"Linux runs on a wide range of different processor architectures. There is no way that binary drivers from one architecture will run on another architecture properly."
>
>Szvsz, erre megoldás a dedikált architektúra kijelölése, és a többi architektúra kernel szintű bináris fordítóval való támogatása. Ronda, erőforrásigényes, de a gyártó imádnák, mert csakis egy architektúrán kell fordítani és tesztelni a kódot. De, akkor már mehetne a kernel fejleszttés egy virtuális architektúrán is.

Es minden archon tolni qemu -t, hogy x86-ot emulaljon.
Es modjuk lehetne egy olyan modult fejleszteni ami megeszi egy masik OS driveret.
Volt mar ilyen.pl. ndiswrapper. A gyartok is leszartak. Vagy meg roszabb, fizetnek erte, en meg anyaztagatok azert amit drivernek neveznek.

>
>"Now a number of these issues can be addressed by simply compiling your module for the exact specific kernel configuration, using the same exact C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific Linux distribution. But multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each Linux distribution release contains a number of different kernels, all tuned to different hardware types (different processor types and different options), so for even a single release you will need to create multiple versions of your module.
>
>Trust me, you will go insane over time if you try to support this kind of release, I learned this the hard way a long time ago... "
>
>Pont ez a lényege a stabil APInak. Megfelelő definícióval és implementáció esetén sem a kernelnek, sem a modulnak nem kell tudnia, hogy mivel és milyen opciókkal volt a másik fordítva. A legnagyobb hátrány, hogy megköveteli a fejlesztőket, hogy egy adott infrastruktúra mentén legyen a fejlesztés, és ne lehessen quick&dirty, félig, negyedéig implementált modulokkal az adott eszköz támogatásának a látszatát kelteni. Ez pillanatok alatt lefelezné a támogatott hardverek számát, de nem kéne a mezei usernek fél éjszakát molyolnia, hogy rájöjjön, miért nem megy amúgy alap funkció a gépén. (Lásd: open-source broadcom modulok és az encrytion key esete)

Ezzel nagyon megnehezitetted volna az OS level virtulizacio (lxc, openvz) hozza adasat, vagy a Linux Secirity Modulest.
Nem ertem ez miert akadalyozna meg barkint, hogy printk("Not implemented\n"); -ekkel tegye tele a kodot.

>
>"Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.
>
>As a specific examples of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem. These reworks were done to address a number of different issues:
>
>A change from a synchronous model of data streams to an asynchronous one. This reduced the complexity of a number of drivers and increased the throughput of all USB drivers such that we are now running almost all USB devices at their maximum speed possible.
>A change was made in the way data packets were allocated from the USB core by USB drivers so that all drivers now needed to provide more information to the USB core to fix a number of documented deadlocks.
>"
>Bullshit. Faszán megmagyarázza a tervezés teljes hiányát és még meg is veregeti a fejlesztők vállát. Ezek a reimplementációk jól jellemzik az egész open-source fejlesztési modellt. Igen látáványos changelogokat eredményez, csak épp a használhatóságot csapja agyon.

Ezek szerint te meg tudod josolni a technologiai valtozasokat, es olyan API tervezni ami mindig hatekony es kezenfekvo lesz mindenkinek.
Nem ertem miert nem segitettel USB API-t tervezni. Es azt sem, hogy a papiron tervezett rendszerek miert lesznek szinten elkeffintve eloszor es masodszor ..

>"This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This provides the ability for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer."
>
>Újabb bullshit. Ezt ugyanis kompatibilitásnak hívják. Egy zárt forrású fejlesztő cég nem égethet fel minden hidat a hátamögött annak megfelelően, hogy a cégvezető milyen hangokat hall éppen. Ugyancsak előfordulhat, hogy az új fejlesztő szeretné, ha az alkalmazása régebbi OS-eken is futna. Pont ezeknek a fejlesztőknek az életét könnyíti meg a gyártó.
>
2.6.18 elotti kernelre manapsag nem eri meg fejleszteni. Szerencsere az ota tul sok driver fejlesztott erinto valtozas nem volt.
De valoban nem lehet tul kellemes os regi rendszerekre is fejleszteni.

>"In both of these instances, all developers agreed that these were important changes that needed to be made, and they were made, with relatively little pain. If Linux had to ensure that it preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the USB developers. Since all Linux USB developers do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility."
>
>Azért csak kibújik a szög a zsákból. Ugye egy új, fényes kód polírozása mindig nagyobb dicsőség, mint egy régi karbantartása.
>
Hat ezt is sikerult kiolvasnod, fura a szemuveged van.

>"Security issues are also a very important for Linux. When a security issue is found, it is fixed in a very short amount of time. A number of times this has caused internal kernel interfaces to be reworked to prevent the security problem from occurring. When this happens, all drivers that use the interfaces were also fixed at the same time, ensuring that the security problem was fixed and could not come back at some future time accidentally. If the internal interfaces were not allowed to change, fixing this kind of security problem and insuring that it could not happen again would not be possible.
>"
>
>A tervezés vajon mi? Vajon hány security issue ezek közül, ami a hiányos tervezés következménye? Nem egyszerűbb elkerülni ezeket, ha már a tervezéskor figyelembe vannak véve? Egen, csakhogy a hello.c után nem lehetne hirtelen, mindenki kernel hacker...

Nem hiszem, hogy alapos tervezessel nem lenenek ilyen hibak a vegen. Nagyon nem triviallis labon lovesek kerulnek elo.
Annyi tokeltes tervezo es kivtelezo van, mint ahany elsore tokeletes kernel kodot irni tudo. (kevesebb mint egy)

Helyeseg bizinyitas -rol meg tudjuk , hogy a gyakorlatban kvazi lehetetlen.

>
>Végül az ideologizálás:
>" The quality of the driver will rise as the maintenance costs (to the original developer) will decrease."
>Ez kétséges.
>" Other developers will add features to your driver."
>Vagy épp kivesznek, különféle ideológiák mentén.
>" Other people will find and fix bugs in your driver."
>Vagy épp elcseszik.
>" Other people will find tuning opportunities in your driver."
>Amitől aztán működésképtelenné válik.
>" Other people will update the driver for you when external interface changes require it."
>Lásd fennt.
>" The driver automatically gets shipped in all Linux distributions without having to ask the distros to add it."
>>>>Ezzel megszűnik a lehetőség, hogy csakis olyan formában kerüljön a driver a kernelben ami biztosítja a teljes működőképességét.

WTF ?
- Ha mar distributorodtol kapott driverben nem bizol, akkor miert hasznalod azt a distrot ?
- Ki tiltja meg, hogy felul csapd egy masik driverrel ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én azt nem értem, ha windows-os hálókártya drivereket lehet virtualizálni linux alá, akkor miért nem lehet kernel api wrapper-eket készíteni.

Én ezt úgy képzelem hogy lenne egy stable api verzió kitüntetve, és minden api verzióhoz kiadnának egy wrappert amin keresztül lehetne használni(virtualizációval) a régi api-t is. A stable api meg mondjuk csak 5 évente változna.

> Ez egy nyilvános fórum, amit mi többiek is olvasunk.

Egyetértek. Ezért irritáló, amikor a trolljaink nagytudásúnak állítják be magukat, csak épp tanulni nem lehet tőlük. A piszkálódáson kívül, amit szemlátomást átvesz az ifjúság, mint valami követendő példát.

> úgy hogy ne a trollnak legyen igaza

Figyeld meg jobban a troll-kommunikációt: egyrészt explicit módon nem írnak le semmit, így fel sem merül hogy igazuk lehetne. Az az olvasó dolga, hogy a konkrét mondanivalót beleképzelje a(z implicit) szövegbe. Másrészt meg amit leírnak, az általában egy "komplementer", egyesek szerint irónia, ami a természeténél fogva nem igaz.

A trolloknak legtöbbször nincs igazuk, csak sose jut el az eszmecsere velük odáig hogy erre ők is rájöjjenek, és ezután konstruktív fórumtársakká váljanak. :-(

> a trollnak (kikiáltott fórumtársnak) miért is nincs igaza.

Köszönöm a példát a "tipikus troll kommunikáció"-ra. Semmi konkrétum, "találd ki te, mert én le nem írom" stílusban.

Kikről beszélsz? Melyik állításaikról beszélsz? Miből gondolod, hogy nincs igazuk?

párdon, úgy tűnik lemaradtál az előzményekről, de visszanézheted zamboriz műsorait régebbről is. pont azt csinálja, mint amiket leírt, mint "troll-ismérvek". egyetlen használható hozzászólása se volt még, csak néhány szavas beszólogatások és mások hozzászólásainak kiforgatása... csak azt kapja vissza, amit ő csinál.

ROTFL, nem tudom milyen konkrétumokra vársz, amikor a kifejezések önmagukért beszélnek... Persze nyilván neked nehéz lehet, aki még a "stable API"-t se értette meg, majd keverte az ABI-val, de ezt nem konkrétumoknak hívják, hanem alapismereteknek (illetve részedről annak hiányának).

De nem gond, majd ezt is megideologizálod, mint a ZipFS-t. :))

A fordító nem művel semmit ezzel kapcsolatban. Az ABI ahogy már megsejtetted többekközt a syscall interfacet foglalja magába, valamint a futtatható binárisokkal kapcsolatos formátum kezelést és signal trampolinet. Azok a rendszerek is, amelyek Linux kompatibilitással rendelkeznek (Pl. a BSD-k, a Solaris, XTS-400, LynxOS) ilyen Linux ABI-t nyújtanak - jórészt kernelből - a userspace felé, hogy a Linux futtatható binárisokat módosítás nélkül futtatni lehessen. A normál programok és az ABI között helyezkedik el a libc (nem GLIBC, az csak egy libc implementáció a sok közül).

Forditonak van koze hozza:
Hint: mregparm, msseregparm
Csak hogy legnyilvanvalobbakat emlitsem.

Nem csak user->kernel hivas van. Es nem is az a legnagyobb resze ez ABI dukumentacionak ami a Linux Standard Base resze, es NEM VALTOZIK. STABIL

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Forditonak van koze hozza

Opcionálisan lehet - pl. sebesség optimalizáláshoz -, de nem szükségszerű.

Hint: mregparm, msseregparm

Nincs használva. SSE kernelben pláne.

Nem csak user->kernel hivas van

Hanem?

NEM VALTOZIK. STABIL

Nem mondta senki, hogy nem stabil. A kernel api-ra mondja mindenki, csak ti ketten zamborizzal valahogy nem akarjátok megérteni.

"Nincs használva. SSE kernelben pláne."

beszeltel libc-rol is, ott mar lehet hasznalva.
mregparm lehet hasznalva kernelben, es szokas is (volt?). (32 bites x86-nal) Mivel kisebb es gyorsabb kodot eredmenyezett. (Binaris drivereknel kellett ,hogy az mregparm ertek is megegyezzen.)
in kernel ABI -t vagy userspace ABI -t is befolyasolhat gcc parmeter.
user-kernel kozotti komunikaciohoz pedig semmi koze a gcc opcioknak.
Beagyazott rendszereben , az userspace ABI -t gonosz emberek eltortek mrgeparm -al, hogy kisebb es gyorsabb rendszert kapjanak. De a stabil ABI miatt ez nem terjedt el masutt.

"Nem csak user->kernel hivas van"
Linux -nal az userspace C ABI van definialva. Ami sziten stabil, es semmi koze az in kernel ABI -hoz.

Az in kernel ABI nem stabil. Nem veletelne mondanak olyan csunya dolgot, hogy ugyan azzal gcc -vel (ket fobb verzioszamig), es forditasi opciokkal forgasd a modulokat, mint a kernelt. Ill. az in kernel ABI elterhet az userspace ABI tol.
Az in kernel ABI -t leginkabb gcc ill. opcioi hatarozzak meg. Neha az asm kod reszeknek kell idomulni ehhez.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

beszeltel libc rol is ott mar lehet hasznalva

alapvetően az ABI-ról beszéltem, a libc mellékszál, taxy GLIBC említése miatt jött szóba.

Nem veletelne mondanak olyan csunya dolgot, hogy ugyan azzal gcc -vel (ket fobb verzioszamig), es forditasi opciokkal forgasd a modulokat, mint a kernelt.

Ezt hívják kernel API-nak, nem pedig ABI-nak.

API szamomra olyan dolog ami foleg fuggveny szignaturak es struktura decalaracok megadasat jeleneti. (tudod ami .h -k egy reszeben van :), vagy pascalban az "interface" resznel )
Te szerinted mit jelent ? Mert mintha nem lennenk kozos nevezon.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Remek.
Akkor abban egyet ertunk -e, hogy a gcc verzio valtas ill. parameterei miatt -e dokumentacio ill. dokumentacio ervenyessege nem valtozik, vagyis az API nem valtozik. --> Stabil
(implicit/explicit plusz makro definalas nelkul.. )

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Félreolvastam a hozzászólásod, de értem már, hogy mire akarsz kilyukadni és miért van a félreértés. Természetesen van kernel oldali ABI is, amelyik a kernel exportált interfacét írja le (moduloknak), de én ABI alatt - meg úgy általában mindenki - a userland alkalmazások kompatibilitását szolgáló interfacét értettem (ahogy írtam is: syscalls, elf parser, signal handling, etc.), amellyel garantálható, hogy egy Linux alkalmazás futni fog másik Linux kernel (vagy ahogy írtam akár másik oprendszer Linux kompatibilitási rétege) alatt is. Ez stabil. A kernel oldali interface - amit leginkább csak kernel API-nak hívnak, még ha van ABI-ja is - nem stabil, ezért kell a modulokat az adott kernelhez fordítani.

taxy meg azt szeretné, ha ez utóbbi is stabil lenne...

nem értem: LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31) miért 31, miért nem 37?

ezt sem értem: kmap_atomic_prot()


2.6.31: #define kmap_atomic_prot(page, idx, prot)       kmap_atomic(page, idx)
[változatlan]
2.6.36: #define kmap_atomic_prot(page, idx, prot)       kmap_atomic(page, idx)
2.6.37: #define kmap_atomic_prot(page,      prot)     __kmap_atomic(page)

Látszik, hogy a 'prot' paraméter nem való semmire. Akkor miért kmap_atomic_prot(), és nem kmap_atomic()? Ha már az #else ágban is az van.

2.6.37-ben nem lett volna semmi gond a kmap_atomic() -al:


#define kmap_atomic(page, args...)    __kmap_atomic(page)

Nem értem, hogy ennek a "fura" kódnak a bedöglése kernel verzió váltáskor mire példa? Hogy "szépen" kódoljunk, mert az megvéd a változásoktól?

"nem értem: LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31) miért 31, miért nem 37?"

Azért, mert a kernel modult nem én írtam, aki írta az nem adott még ki frissítést a 2.6.37-es kernelhez, én meg csak azért hogy lefordítsam, nem akartam saját #if-et írni, mert minek. De csak neked:


#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)
	src = kmap_atomic_prot(s, prot);
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31)
	src = kmap_atomic_prot(s, KM_USER0, prot);
#else
	src = kmap_atomic(s, KM_USER0);
#endif

Őszintén szólva fogalmam sincs, hogy miért kellett a prot (azt se tudom mire jó), de én feltételezem, hogy jó oka volt rá. A teljes függvény: http://pastebin.com/j5Ysf5Ve

Egyébként arra példa, hogy a kernel fejlesztők szeretik időnként megváltoztatni pl. az api függvények paraméterezését, ami nem tesz jót azoknak a kódoknak, amik nincsenek a kernelben.

--
Don't be an Ubuntard!

Köszönöm szépen!
Akkor ez is a helyére került.

Hát én ehhez képest a KERNEL API-t akarnám becsomagolni.
Tehát arra gondolok, hogy egy ezt a mostani 3.0-ás kernelt kikiáltani stable api-nak, és csinálni egy olyan kernel modult, amivel a későbbi kernel verziókba be lehet tölteni a 3.0-ás api-ra leforgatott bináris kernelmodulokat. Szerintem ez hasznos lenne a linux desktop eljövetelének szempontjából. :)

"ennek kb. ugyanakkora karbantartási overhead-je lenne, mint a stable API-nak"
Ez igaz, csakhogy így nem kéne megválni attól az ideológiától hogy a kernel api változékonysága a hatékonyságot szolgálja. Én legalábbis ebből indultam ki. Mert a nyílt driverek követhetnék a mainstream kernelt, a zártak meg kicsit lassabban, de elkullognának valahogy.

"Ez most is így van, tehát ezért egy szalmaszálat is kár lenne odébb tenni."

Azért van egy aprócska különbség aközött hogy a gyártó nekiáll új drivert fejleszteni a 20-adik kernel variánshoz, vagy a kernel fejlesztők mikor api-t módosítanak, nem csak a 200 drivert módosítják hozzá, hanem a 201-edik wrapper modult is. Nem?

2.6.42 :( , pedig milyen jo lett volna hosszu karbantartasunak.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

kuldj egy patchet 2.6.32-hoz:



scyla:/usr/src/linux# git diff Makefile
diff --git a/Makefile b/Makefile
index d43a635..a2bf7ba 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 2
 PATCHLEVEL = 6
-SUBLEVEL = 32
+SUBLEVEL = 42
 EXTRAVERSION = -op5
 NAME = Man-Eating Seals of Antiquity


___
info

Igazából lehetne nyugodtan a rövid git hash a verziószám, mert kb. sehol nem éri meg úgysem figyelni a többit. A kiadások meg simán a tag-elt verziók lehetnének.
--
http://www.naszta.hu

Open Source-os zászlóshajók elkezdtek koncepciótlanul verziót váltani. Ez már a vég kezdete.

Nem hinném, hogy ez koncepciótlan lenne, sőt, teljesen jól illeszkedik a linux kernel fejlesztési módszeréhez, azaz hogy ha valami előnytelenné válik, azt egyszer csak lecserélik, és nem túlzottan zaklatja fel őket az, ha valakinek ez nem tetszik. A helyzet az, hogy a jelenlegi verziószámozás megérett a cserére, a 2.6.x-ből a 2.6-nak semmi szerepe nem volt(illetve csak annyi, hogy megkülönböztette az előzőektől, de erre egy számjegy is tökéletesen elég), logikus volt lecserélni egyetlen számjegyre.

Mint egy rossz celeb, akinek az egyetlen szempont, hogy beszéljenek róla.

"Persze megvan a szokásos kétharmadot kitevő driver változás"

Ezen még soha nem gondolkodtak el amúgy? Ha egy kernel minden kiadásában ekkora változtatások vannak, miközben a kernel tartalmaz drivert szinte minden létező hardverhez (az más kérdés, hogy a gyakorlatban mennyire használhatóak), ott valami nagy gond van.

Egyébként az az érv jogos, hogy a minor verziót azért kell növelni minden kiadáskor, mert olyan mértékű változásokat hoz minden kiadás. Majd ha lesz egy stabil api, akkor megragadnak a 3.x-nél. :)

--
Don't be an Ubuntard!

A gyártók ilyen okokból nem foglalkoznak linuxos driverrel a kütyüikhez.
Mert tudna csinálni egy next-next-next -finish telepitőt, de a .ko modul már meg sem fog nyikkanni a gépen ha nem olyan kernelhez akarod telepiteni,amihez forditották. Forrást meg - megérthető okokból- nem adnak ki.

--

A záptojásról meg tudom mondani, hogy záp anélkülis, hogy tudnék újat tojni helyette :-P

Másrészt: sajnos a valóság és tények engem igazolnak (rossz intel grafikus driver, max. 1-2 évig támogatott ati driverek, nem működő kms nVidiánál, csak hogy a legfontosabbakat említsem)

Igen, Linuxot. Hosszabb-rövidebb időkre ott hagyom, mert néha felmerül az igényem arra, hogy valami professzionálisabb környezetben nézzek meg egy youtube videót (értsd: ne egye szénné a processzort a flash), vagy épp működnie kéne a 3D gyorsításnak kielégítő sebességgel, és akkor ott volt a WindowsXP, legutóbb a Windows7.

Viszont azokból nagy bánatomra sokminden hiányzik, ami viszont desktop linuxokban már évek óta van: okosabb ablakkezelés (always-on-top, több desktop), bash, csomagkezelőből felpakolt libek néha, és persze az synaptics-os egérgörgő (ami windows alatt hulladék). Amíg az itthoni gépen fejlesztek, addig maradni fog ez így :\ Ubuntu 10.04 LTS, amíg támogatott, azután is csak LTS lesz, és együgyűen hiszem, hogy a nagyobb progik major verziói kijönnek erre a rendszerre.

Szerk.: tudom, hogy a fent felsorolt dolgok egy része elérhető Windows alatt is, de vagy macerásan, vagy nem olyan minőségben. Legutóbbi windowsozásom alatt igen fasza bash-es környezetet sikerült belőnöm, de hiányzot az... érzés :)

> Egyetlen dolog ami hiányzik a linuxból otthon az a bash.
Mármint Windowsból? Mondom, én egész jól felturbóztam bash-sel a rendszerem (ami a GIT-tel jött asszem, az volt egész jól bekonfigurálgatva, ahhoz még hozzácsaptam pár dolgot, aztán onnan ssh-ztam, működött az na, de autoconf, ilyesmi már bajosan). Közben a céges muszájUbuntu10.04 annyira jól be lett lőve, meg jól muzsikált, hogy itthon is azt tettem fel, nem konfigoltam szét, és lám, egész jó szolgálatot tesz. Céges is Thinkpad T61, itthon is.

Ez nem ilyen kérdés.
Ez olyan dolog, hogy pénzből él a gyártó. Csinál egy vasat, és ir hozzá egy drivert. Húzza száját, ha ki kell adnia a titkait, mert üzleti titok a hw működésének sok része. Ebből él ugyanis...
Aztán fog egy OS-t alárakja, kicsiszolja. A lemezre ráirja a drivert és a telepitőt, illetve kiteszi a weblapjára. És érdekes módon, az xp-s driver az xp teljes élettartama alatt működik is, függetlenül attól, h. sp1-2- vagy 3.
ÉS amikor azt látja, hogy fordit a 2.6.32 -es kernelhez egy modult, d e ak öv. update felrak egy 2.6.35 -öt, esetleg olyan disztró alá akarják beszuszmákolni ami régebbit használ (centos -> 2.6.18.xxx), esetleg az buntusok fél évente teljesen lecseréli ka rendszert, de ha támogatom akkor a csip-csup-csóka disztró közössége anyázni kezd a fórumon, hogy őket miért nem támogatom külön, akkor én is azt mondom, hogy win XP, w7, osx, "osztkapjátokbe" és/vagy "tanuljatokmegvazzeOS-tcsinálni".

Ezért mondom újra, és újra, hogy az 1bites desktop user horda nagysága, és a hw támogatottság szorosan összefügg.

Tudod amikro van egy régi lapim amin nem megy xy disztró, mert a driverében már nem támogatott az a kártya, de win alá bármikro előkapom a CD-t/letöltöm netről és pöccre megy, addig nincsen miről beszélni.
Tipikusan 11.04-es ubuntu, old p4-es HP gépek az intel videó chippel....
--

Attól hogy a marketinggépezet a sok buta emberrel megvetet valamilyen terméket, még nem lesz sikerplatform. Jön egy generációváltás, egy konkurens, aki jobbat csinál, és el is felejtik.
A sikerplatform az IBM PC volt (vagyis még mindig az), aminek a specifikációi nyilvánosak voltak, és bárki fejleszthetett rá, szoftvert is, hardvert is, meg is tették.
A mai PC-k mind binárisan kompatibilisak az XT-vel, az összes akkor írt program fut a mai gépeken. Ha az IBM nem nyitja meg akkor a spec-t, valószínűleg a PC is csak egy lett volna a sok számítógép között.

alpha? beta? Legalabb major verzional legyen mar a latszat kedveert

Ezen ennyit pöcsölni, a lényeg, hogy a kód se jobb, se rosszabb nem lesz, akkor nem mindegy, hogy minek hívják? Mostantól 3.x és kész, ennyi.

Igen, csak build es qa rendszerek sora epitett erre a verziozasra, nem is beszelve a kulso driverekrol, amikben a stabil API/ABI hianya miatt egy rakat #ifdef-van, mivel kernel verzionkent maskepp kell hasznalni egy bizonyos fv-t.
Annak aki nem fejleszt ra/vele annak konnyu ugralni, hogy csak egy verzio szam valtozas lesz, nem nagy cucc, de aki benne van, az kb tudja, hogy mivel fog jarni ez az egesz.
LKML-en epp most megy egy thread, hogy most mi lesz a fejlesztoi agakkal, mert szinte mindegyik tartalmazza a 2.6-ot, es hogyan tovabb...
___
info

Igazad van, ott csak simán nem úgy működik, ahogy kellene, és még csak meg sem tudom nézni a forrásban, hogy hogy lehetne workaround-olni, mert amit valamelyik eldugott msdn-es blogon írnak valami kommentben mint workaround (már?) nem működik.
(Ne értsetek félre, nem azt mondom, hogy a linux kevésbé bugos, mert soha nem fejlesztettem komolyabban natívan linuxra, csak annyit mondok, hogy az Windowsnál sem olyan hűdeegyszerű az élet...)

Mivel a Windows API-t már hegesztik egy ideje, sokkal ritkább benne a bug, mint hinnéd. Lehet, hogy én fejlesztek keveset, de Windows API alatt nem találtam még bug-okat. Biztos szerencsém is volt (nem driver-eket írok). Ugyanakkor Linux "API" miatt már kellett újraírnom teljes függvényeket is úgy, hogy esély sem volt arra, hogy a probléma megoldódik később.
--
http://www.naszta.hu

ioctl váltás miatt szoptam, soros és párhuzamos portot használó alkalmazással is. 7-8 évet ment némelyik, mígnem gépet nem cseréltek alatta, aztán jött a WTF érzés.
Szintén zenész a párhuzamos port alacsony szintű elérésének az átkufircolása. Kellemes dolog, amikor előhúz az ember egy 12 évvel korábban megírt alkalmazást egy quick&dirty hackkeléshez, aztán 3 napig nyálazza a kernel dokumentációt.
Termelésben gyakori, hogy egy rendszert akár 20 évnél tovább is használnak. Ilyen esetben egy gép kiesése, vagy upgradeje irgalmatlan szívást tud generálni.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szerintem Széll Kálmán után kellett volna elnevezni.