Linus Torvalds: Linux 3.0-rc1

 ( trey | 2011. május 30., hétfő - 8:02 )

Ú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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

/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]

Tény hogy ennek a lépésnek semmi értelmét nem látom. :(

Az egyszerusegre torekves nem eleg?

tompos

Akkor már inkább valamilyen dátum formátumú verziózást választottak volna. :/ (pl. főverzió.éééé.hét )

Azért annak is kellene örülni, hogy ez a legnagyobb problémájuk :)

jo is lenne, ha ez lenne a legnagyobb problemajuk, es nem ez hogy egy idiota vezeti a fejleszteseket ott...
___
info

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.

Az már nem divat. Volt Windows 95, 98, 2000. Most már ők is csak 7-esnek hívják.

Mármint hogy ne háromszámos, hanem kétszámos kernel verzió legyen? Arra lehetett volna 2.7 is, ha már nincs külön fejlesztői kernelfa.

Lehetett volna, de miert problema az neked?

Megirtak azt is, hogy miert jobb a 3.0, mint a 2.7.

tompos

fejlesztoi -> linux-next
___
info

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 .

Pluszsok. Alapvetoen eleg lett volna a negyedik szamot kidobni, es kesz. (Sot, eleve be sem kellett volna vezetni, de ez mar egy masik tema.)

még egy (alalalverzió) szám kellett volna inkább és akkor elment volna ipv4 címnek :)

+1

--
"Windows... az mi?"

Ez legalabb jo kis vizvalaszto lesz. Az a script, amelyik elhasal eleve erdemes kidobasra.

Persze ettol meg a bennmaradok is lehetnek szarok....

Kezdetnek mondjuk:

Linux 3.0-rc1

.. except there are various scripts that really know that there are
three numbers, so it calls itself "3.0.0-rc1".

Hopefully by the time the final 3.0 is out, we'll have that extra zero
all figured out.

Signed-off-by: Linus Torvalds

ahahah

Es ezek az emberek voltak azok, akik azon poenkodtak, hogy "jeee, a Windows 7 verzioszama is 6.1, mert sok hulye alkalmazas 6.x-re matchel, mekkora szar mar...". tessek, megkaptak. Neha fontos a visszafele kompatibilitas, ugye?

Debian-devel-announce listán már ment is a riadózás emiatt...

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.

Ahhoz talán kellene egy stabil kernel API is. Ez pl elég nagy újítás lenne, még az új főverziót is indokolná. :)

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. "

tldr

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

Viszont ha nem ilyen hosszan valaszol akkor el lenne kuldve azzal, h "hulye vagy, a kernelfejlesztok jobban tudjak". :)

---
pontscho / fresh!mindworkz

az élet nem fenékig tEiffel :)

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

Nem túl izgalmas dolgok ezek. Amíg nincs a kernelből fork ...

Minden hw gyarto, aki linuxot hasznal, forkolt maganak egy kernelt

Minden szavaddal egyetértek. (Kár, hogy itt többen olyanok, mint a lovak: csak egy meglehetősen szűk sávban látnak.)

>"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.

> akkor miért nem lehet kernel api wrapper-eket készíteni.

Az a glibc dolga.

Jol mutatna a kernelben.

---
pontscho / fresh!mindworkz

Nem tipikus használatra gondolok, hanem arra hogyha valakinek van egy hardware amire nem adott ki friss drivert a gyártó, akkor ne kelljen downgrade-elni 2.4-esre az egész kernelt. Cserébe ordó n/2 időben futhatna a driver.

látom még mindig nem sikerült megérteni a kernel API és az ABI közötti különbséget...

Akkor majd te magyarázod el.

Sajnos nem érzem úgy, hogy nekem kellene mindent elmagyarázni... de majd egy-két év, aztán a ZipFS után ezt a bonyolult kernel API-ABI dolgot is megérted talán.

OK, ha nem magyarázod el, akkor nem magyarázod el. Nem probléma, megértem.

Nyugi!
RTFWikipédia:
http://en.wikipedia.org/wiki/Application_binary_interface
Elolvastam, ennyi.

Nekem elég hogy Hugi nem mer konkrétumokat írni :-)))

Hát bevallom őszintén én nem 100%-osan értem hogy miért ABI és miért nem system call interface. Ugyanis az ABI "low-level interface", én meg API-ról beszéltem, meg te is.

> miért ABI és miért nem system call interface

Gondolom "system call interface"-ből több is van, architektúrától függően.

Pedig nem, mert a low-level dolgok függnek az architektúrától, tehát az ABI.

OK, akkor a HW architektúrától függő ABI-k implementálják a HW-től független (absztrakt) "System Call Interface"-t. Az API meg ettől (az SCI-től) annyiban több, hogy tartalmazza a kernel és az alkalmazás közötti adatcserében használatos struktúrák leírását is?

Aha, hát én a "System call interface" alatt már az API-t magát értettem.
Szerintem arra gondolt, hogy nem tudod mi a különbség a kernel API, és a System Call API között. Szerintem.

> Szerintem arra gondolt, hogy nem tudod mi a különbség a kernel API, és a System Call API között.

Felesleges találgatni. Majd leírja ha számít neki. Ha meg nem számít neki, akkor nekem sem.

Már bocs, de ez nem egy verseny, hogy ki a rosszhiszeműbb. Ez egy nyilvános fórum, amit mi többiek is olvasunk.

> 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.

Az a stratégia lenne ideális, ami minél hamarabb rövidre zárja az ilyen vitákat, persze úgy hogy ne a trollnak legyen igaza. Hogy hogyan lehet ezt elérni az esetre válogatja, de nekem úgy tűnik hogy itt a jóhiszeműség a nyerő.

> ú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. :-(

Sehol nem látok konkrétumokat arra vonatkozóan, hogy a trollnak (kikiáltott fórumtársnak) miért is nincs igaza.


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

> 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?

Fenti hozzászólásomban konkrétan éppen konkrétumokat hiányolok, beszélni kicsi mágyár?


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Lehet úgy is értelmezni hogy igaza van. A baj az hogy udvariatlanul és rosszindulatúan lépett be ebbe a diskurzusba más fórumokra hivatkozva, rögtön a legrosszabbat feltételezve. Pedig csak egy kicsit kellett rendet tenni a fejekben.

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.

A trolloknak legtöbbször nincs igazuk

+1, szinte sosincs igazad.

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. :))

Tehát a kernel API az amit a kernel modulok használnak. Az ABI meg amit a fordító és a standard library művel. A GLIBC pedig egy erre épülő API. Csak hogy tiszta vizet öntsünk a pohárba.

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.

hibás api-t attól még breakelhet

Hogy erted, hogyan ?


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-e?

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31)
	//a második paramétert én kommenteztem ki
	//mert a 2.6.37-es kernelben már csak 2 paraméteres a függvény
	src = kmap_atomic_prot(s, /*KM_USER0,*/ prot);
#else
	src = kmap_atomic(s, KM_USER0);
#endif

--
Don't be an Ubuntard!

Kernel verziot emlitesz en gcc verziorol beszeltem.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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!

> a kernel fejlesztők szeretik időnként megváltoztatni pl. az api függvények paraméterezését

A kmap_atomic_prot "api* függvény" (pontosabban: "api makró") lenne? (*: pontosabban "driver programming interface"; hamár a nouveau driver-ből idéztél)

Miért, ez benne van a nouveau driverben is? Én egy vmware kernel modulból szedtem. :)

Tökmindegy minek hívod, a lényeg, hogy külső kód épül rá.

--
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. :)

De ennek kb. ugyanakkora karbantartási overhead-je lenne, mint a stable API-nak, amitől ódzkodik a Linux fejlesztőcsapata (pont ilyen okból, csak még ideológiát is gyártottak hozzá).


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

"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. Ha meg a fejlesztési modellt egy ideológia alapvetően befolyásolja... nos, azt az esetet inkább nem minősítem.


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

"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?

omg :D

+1
Nem az userlevel API-ra gondoltam, hanem a belsőre.

van, akinek már így is elég stabil, érd be ezzel, kérlek


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

csak szegény külső(és egy jó adag belső) fejlesztők nem gondolják így:\

Ne etess, irónia volt. (Új lehetsz errefelé. :-P)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

Ezen a "ne etess"-en jót derültem :)

+1, foleg, hogy eloszor fel sem tunt :) Ketertelmu manapsag.

--
http://www.micros~1

:)
--

> Ez pl elég nagy újítás lenne, még az új főverziót is indokolná. :)
Szerintem inkább a névváltást indokolná. Jelenleg Linux=UnstableAPI...

(Elnyom egy asitast)

Lásd Firefox, már jön az öt, sőt a hat is :)
----
Hülye pelikán

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

:D Komoly. Tetszett.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

/o\

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.

Jé te még élsz?
Ja, +1

+1
Szerintem sem volt most semmi komoly bejelenteni való, de kellett durrantani egy hangosat.

"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.

--

sokkal inkább: forrást meg - érthetetlen okokból - nem adnak ki. de még specifikációt sem.
btw, hánynom kell a nextnextfinishtől.

És ami miatt hánysz, azt a sikerplatformok alkalmazzák, és pont ezért sikerplatformok, a linuxod alá meg pont ezért van rosszminőségű driver túlnyomó részt.

Bugreportoltál? Forkoltad? Írtál jobbat? Nem? Akkor ne trollkodj. :-P


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

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)

Es Linuxot hasznalsz amugy?

Amúgy ez miért releváns? :)
----
Hülye pelikán

Mert kmARC jo haverom, de nem lattam kb. harom honapja :) Mi jokat szoktunk beszelgetni ilyen dolgokrol is.

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. Elvileg powershellel lehetne pótolni, de akarja a halál megtanulni a 4. (vagy 5.?) parancsértelmezőt is, inkább használok pythont (nagy ötlet volt az interaktív interpreter).
----
Hülye pelikán

> 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.

Gondoltam, hogy nyelvtanilag megtévesztő lesz. A linuxban meglévő dolgok közül hiányzik otthon a bash, implicit ezzel mondtam, hogy otthon Windowst használok.
Erről a gittel jövős bashről tudsz még mondani valamit? Mifélehogyféle?
----
Hülye pelikán

Semmi különös, csak be van lőve hozzá parancsikon, meg valami normális prompt, meg néhány elérési út talán. Abból indultam ki, amikor a sajátomat elkészítettem. Ennyi. De nem volt sajnos jó terminál emulátor hozzá, vagy valami ilyesmi volt a gondom vele.

"Egyetlen dolog ami hiányzik a linuxból otthon az a bash"
+1
--

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.

Vigyázz, ha egy nem sikeres platformal foglakozol, sikeres ember nem lehetsz! :)

Sikerplatform... aranyköpésekkel teli napra virradtunk. :)

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

Fejlessz Windows-ra! Ott nincs ennyi szívás az API-val... :)
--
http://www.naszta.hu

+1 (na ide akartam irni elsore is csak a hulye drupal bejelentkezes utan miert a fo thread-be dob? :( )

mert szar opensource fos

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

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

> Ugyanakkor Linux "API" miatt már kellett újraírnom teljes függvényeket

Pár konkrétumot még írhatnál.

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 ha valamilyen rendszerhez 20 (de akar csak 2-3) evig nem nyulnak, akkor ne csodalkozzanak egy kis szopason kesobb. Termeszetes hogy ennyi ido alatt jelentosen valtozik a szoftver, de meg a hardverkornyezet is, amit azert illik kovetni.

> 7-8 évet ment némelyik, mígnem gépet nem cseréltek alatta

A hardver csere hogyan okozhat "ioctl váltás"-t?

Úgy, hogy az új géphez, új rendszer és új kernel is jár. A dolog bájossága, hogy talán 2.6.8-nál volt a váltás.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Úgy, hogy az új géphez, új rendszer és új kernel is jár.

A régi, meg az új kernel-t is te fordítottad? Nem volt az egyikbe valami "külsős" soros driver beleforgatva?

A régi is és az új is a vanilla, alap soros driver volt.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> A régi is és az új is a vanilla, alap soros driver volt.

És a soros HW ugyanolyan maradt? (Például multiport kártya át lett rakva az új gépbe?)

Hidd el, hogy ioctl hiba volt, lévén a kód fordításakor a maga a fordító szállt el.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

> Hidd el, hogy ioctl hiba volt, lévén a kód fordításakor a maga a fordító szállt el.

Én inkább a tényekben hiszek. Ott tartunk, hogy a fordító elszállt ioctl váltás miatt. Mi volt az az ioctl hívás?

Hát gondolom az Activation Context API-t nem sokan használják, szóval lehet nem volt szerencsém...

-

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

+0.6666666666...

Linux 69 ;)