Szükséges-e Linux bináris kernel driver réteg / API

Címkék

A Slashdot-on jelent meg egy hír, egy a Greg Kroah-Hartman blogjában található bejegyzésről: az OSDL Japan néhány tagja, nevezetesen a Fujitsu, az NEC és a Hitachi azt szeretné, ha lenne egy stabil kernel API a driver fejlesztők számára.El is készítettek egy javaslatot (Open Driver) arra nézve, hogy hogyan lenne (szeretnék, ha lenne) ez kivitelezve. A dokumentumból kapott Greg K-H is, akit külsősként (nem OSDL alkalmazott) kértek fel arra, hogy véleményezze a javaslatot, és győzze meg őket arról, hogy nem jó az ötlet. A javaslat egyik pontja (gyártói előnyök részben) így hangzik:

1. nem kell nyilvánosságra hozni a drivereket

(Terjeszthetők, mint zárt forrású szoftver)

Tehát Hartman blogja szerint, összefoglalva: az OSDL Japan azt szeretné, ha lenne egy stabil API, hogy lehessen zárt forrású drivereket írni.

Slashdot hír itt, a blog bejegyzés pedig itt található.

Hozzászólások

Keszen van ez a csoka. Hogy vallalhat ilyet? :)

"Or maybe I'll just say it sounds like a great idea, and why not just post the patch to the linux-kernel mailing list. Then I'll sit back and watch the fireworks, it's been a few weeks since we've had a big flamewar..."

BTW, valaki felhomalyosithatna, hogy miert illegalis az, ha keszitenek egy olan kernel API-t ami tudja azt amit akarnak, es irnak binary-only drivereket, ugyanis Greg azt irja "it's so illegal, it's not even funny".

"Gyakorlatilag egyetlen hardver-csoporttal vannak driver problémák Linux alatt, ez pedig a videokártya, az is a 3D gyorsítási résznél. Egy darabig nyűgös dolog volt a WiFi, de ahogy nézem már az sem gond."

Nekem az egyetemen jó időbe beletelt, amíg beüzemeltem linux alatt az rt2500 chipsetes kártyámat, és végül a *zárt forrású* windowsos driverrel tudtam meghajtani. (wpa_supplicant + ndiswrapper)

Van ugyan nyílt forrású driver is a gyártótól, de az nem támogatja a WPA-EAP-ot, és a wpa_supplicant sem képes együttműködni vele.

Szóval akkor jó-e a stabil API vagy sem?

(NDIS = Network Driver Interface Specification)

A belinkelt postnal van imho ujabb greg oldalan, amiben o is helyesbit, mert nem eppen az tortent, amire O fel volt keszulve.

post itt [www.kroah.com]

Prezi, ami a meetingen be volt mutatva

itt [www.kroah.com]

Mert tortenetesen van ket zacsko alkatreszem, ami Solaris alatt nem mukodik, Linux alatt meg igen, nyilt forrasu driverrel. Meggyozodesem, hogy a Linux nagysagrendekkel tobb hw-t tamogat, mint a Solaris annak ellenere, hogy a Solaris jelenleg megfelelne annak a kitetelnek, amit a 3 ceg szeretne. Tehat ez onmagaban nem garancia arra, hogy tobb driver lenne, es ha lenne azok jobb minoseguek lennenek (lasd ATI crap).

In article <42.56585@c.hup.hu>, frank wrote:
> A belinkelt postnal van imho ujabb greg oldalan, amiben o is helyesbit,
> mert nem eppen az tortent, amire O fel volt keszulve.

Osszefoglalva: kihasznaltak a licenszbuzerans elvakultsagat, hogy mast
utaltassanak meg a cegekkel. Teljesen ugyes. Igy jar aki barom.

--
Gabucino

hat nem okoztal csalodast snq-, nem tartalak sem hozzaertonek, sem ertelmesnek, es ezt lepten nyomon bizonyitod.

1. a linux hardware tamogatottsaga messze a legjobb az osszes opensource kernel kozott.

2. minden hardware csaladban van linuxon hasznalhato eszkoz, es midenhez keszul is driver, bar neha varni kell ra 1-2 evet.

3. a binaris driver _oriasi_ stabilitasi+biztonsagi problema. a M$ kizarolag azota nem fagy le naponta, amiota sajat csapata auditalja a driverek forraskodjat. csak akkor lehetne szabadna a linuxba binaris drivereket, ha azt pl az OSDL forraskod soronkent auditalna. viszont igy is oriasi problema lenne, hogy az advanced felhaszalok keptelenek lennenek kidebugolni egy problemat, ami erinti a binaris drivert.

4. szerintem az a ceg, aki nem adja ki a driver forraskodjat, az mondjon le az opensource oprednszer hasznalo vevoirol. mivel ez mar egyre jelentosebb tomeg, nagyon meg fogjak gondolni, hogy megtegyek-e.

In article <42.56600@c.hup.hu>, Mészáros András wrote:
> 1. a linux hardware tamogatottsaga messze a legjobb az osszes opensource
> kernel kozott.

X-DDDD

> 2. minden hardware csaladban van linuxon hasznalhato eszkoz, es midenhez
> keszul is driver, bar neha varni kell ra 1-2 evet.

X-DDDD

> 4. szerintem az a ceg, aki nem adja ki a driver forraskodjat, az mondjon le
> az opensource oprednszer hasznalo vevoirol.

En meg inkabb lemondtam a linuxrol :D

--
Gabucino

Én meg azt szeretném, ha zárt forrású drivert írni sok munka lenne, inkább megérné kiadni nyiltnak. Miért is? Mert szvsz egyre nagyobb tömeg a linux felhasználóké, egyre lényegesebb piacvesztés, ha linux alatt nem használják a hardveredet.

Lassan már elég linux felhasználó van ahhoz, hogy ilyen API nemléte esetén a nyilt forrású drivert a piac kikényszerítse a gyártóktól. És az, ha belenézhetünk a driverbe, már csak paranoia szempontjából is megnyugtatóbb.

Ezzel viszont csak azt lehet elérni, hogy a zárt driverrel dolgozó cégek kerüljenek előnybe, mert tőlük nem tudnak a többiek ellesni valamit.

Inkább google-zek még driverek után egy darabig, mert szerintem hosszú távon ezzel járunk jobban.

L. Á.

In article <42.56616@c.hup.hu>, rpsoft wrote:
> Én meg azt szeretném, ha zárt forrású drivert írni sok munka lenne, inkább
> megérné kiadni nyiltnak. Miért is? Mert szvsz egyre nagyobb tömeg a linux
> felhasználóké, egyre lényegesebb piacvesztés, ha linux alatt nem használják
> a hardveredet.

Igen, a szokasos openszorsz tanitast hallottuk. Csakhogy nem tokmindegy,
hogy egy halokartyarol, vagy a legujabb ATI kartyarol van szo. Utobbit
"kicsit" tobben hasznaljak Windows meg MacOS alatt ;) Es lon, ezeken az
OS-eken a maximalis sebesseget hozza a kartya, nem pedig 50%-ot (linux,
2005). A linux user a halokartyat viszont feldughatja, ha kozben mondjuk
driver hijjan nem megy a tuxracer se, quake4rol nem is beszelve.

Aki gondolkodas nelkul emleget radikalizmust, az elobb utobb megerdemelten
megszopja.

--
Gabucino

Ne viccöjjünk mááá kérem...

Gyakorlatilag egyetlen hardver-csoporttal vannak driver problémák Linux alatt, ez pedig a videokártya, az is a 3D gyorsítási résznél. Egy darabig nyűgös dolog volt a WiFi, de ahogy nézem már az sem gond.

Praktikusan arról van szó, hogy van néhány olyan algoritmikus fogás a driverekben, amik gyorsítanak a 3D megjelenítésen és ezt nem óhajtja kiadni a cég, mert különben hardverből kéne ezt behoznia, elveszne az előnye.

A játékbolndok miatt van ez az egész, akik már 100Hz-es TV-t sem néznek mert gyenge az fps-e...:-)))

Nem tudom, hogy az a bizonyos 50% mennyire köszönhető a linuxnak és mennyire azoknak akik a drivert írják rá.

Szóval az ati driver pont egy olyan példa, ahol a fejlesztőknek is van bőven vaj a füle mögött. IMO

Elolvastam a http://www.kroah.com/log/linux/stable_api_nonsense.html oldalon lévő írást is, ha igaz amit a bináris interfészről ír, akkor az tenyleg elég szívás ilyet csinálni/karbantartani.

Persze tényleg jól jönne a driver, de nem hiszem, hogy ettől mindenki nekiállna linuxos drivert írni. Ha megéri a cégnek, akkor úgyis bele fog vágni, akár bináris API nélkül is. Legalábbis remélem :)

>> nem tartalak sem hozzaertonek, sem ertelmesnek

akkor ez kolcsonos, csak nem akartam mondani

>> a linux hardware tamogatottsaga messze a legjobb az osszes opensource kernel kozott.

torottlabuak kozott nem nehez futobajnoknak lenni

>> minden hardware csaladban van linuxon hasznalhato eszkoz, es midenhez keszul is driver

ilyen-olyan minosegben

>> bar neha varni kell ra 1-2 evet

miert is?

>> a binaris driver _oriasi_ stabilitasi+biztonsagi problema

ha te mondod, akkor csak igy lehet

>> szerintem az a ceg, aki nem adja ki a driver forraskodjat, az mondjon le az opensource oprednszer hasznalo vevoirol. mivel ez mar egyre jelentosebb tomeg, nagyon meg fogjak gondolni, hogy megtegyek-e

ez az irtozatosan nagy tomeg hasznalhato drivereknek orulne elso korben

ne aggodjal, a kutyat nem erdekli, hogy te kirol mit gondolsz.

ugyanakkor viccesnek talalom, hogy a hozzad hasonlo hupdroidok allandoan, gondolkodas nelkul szenne fikaznak barkit, akik esetlegesen ellentetes allasponton vannak mint az utobbi evekben egyre inkabb elszallt linux fo-fo-fo developer atyauristenek, vagy uram bocsa' nem hisznek a "one open source way" vilagmegvalto baromsagban.

az arcodat meg nyugodtan tekerjed lejjebb, ha egy mod van ra.

"If your driver is in the tree, and a kernel interface changes, it will be fixed up by the person who did the kernel change in the first place. This ensures that your driver is always buildable, and works over time, with very little effort on your part.

The very good side affects of having your driver in the main kernel tree are:

The quality of the driver will rise as the maintenance costs (to the original developer) will decrease.

Other developers will add features to your driver.

Other people will find and fix bugs in your driver.

Other people will find tuning opportunities in your driver.

Other people will update the driver for you when external interface changes require it.

The driver automatically gets shipped in all Linux distributions without having to ask the distros to add it."

A multkor pont errol beszeltem, amikor a "closed-source-legyenfaszadriver-team" a torkomnak ugrott minden kulonosebb ok nelkul. (Az "ok" alatt ertem, hogy senkit nem sertettem meg a hozzaszolasommal)

UI: Ezen hozzaszolasomat nem flame inditasnak szanom, pusztan megjegyzes. Ha ugy erzed, hogy megis az, az a te bajod...

Utalod? Pont az OpenBSD-sek azok, akik _soha_ nem engednenek binaris reszeket a kernelukbe. Masreszt meg pont a BSD licensz az, ahol nem kell allandoan ilyen faszsagokon ragodni, hogy X-et osszelinkelhetem-e Y-al, ha annak a licenszeben van egy Z kitetel es meg sorolhatnam.

Ugyan miért is?

Azt hiszem ez a mondat színtisztán hit jellegű böfögés volt. De nem baj. Ugyanis - mint pl. a GNU/Solaris kapcsán polemizálók megjegyezték - a GPL-lel nagyobb *****ást érhet el a felhasználó, mint a BSDL-lel. De persze csak utáljad nyugodtan.

Egy kedves ismerősön .sig -jéből idézek:

"BSD - an Operating System. Not a Religion."

2005 augusztus, legújabb Xorg és DRI devel snapshot: UT2004 akad mint a *****élet (winben normálisan fut), UT elfogadható, de néha az is hulla lesz, ja és minden OGL 60Hz-ben nyomul... Hogy a 3Dről beszéljek... Különben játszani nemnagyon szoktam, csak néha SZERETTEM VOLNA, a TV-kimenetet viszont szívesen használnám...

Az hogy a GLXgears megy, meg a glxinfo kiírja hogy "direct rendering=YES" nem feltétlenül jelenti, hogy használható is :P

És nem hiszem hogy Linux/PPC-vel te akármit futtattál volna rajta ezeken kívül.

"érteni kéne hozzá": fentebb vki említett rt2500-as WLAN kareszt, nekem ~negyed órába telt a belövése, de csak mert a Celka lassan fordította a drivert :P

Milyen binaris kernel reteg, te joszagu malnabokor... Egyelore egy stabil API-nak is orulnenk... Pl. qrva jo lenne, ha nem kene minden masodik kernelverziohoz portolgatni a sajat kartyank sajat driveret, mert nem hogy binaris szinten, de meg API szinten sem kompatibilis. Aki szerint hulyeseg a stabil API, annak uzenem h. menjen varialja at pl. a malloc()-ot libc-ben, aztan nezze meg hanyan fognak orulni neki. (Egyebkent a libc is legalabb ilyen ***** egy csomo szempontbol, az is megerne egy miset.)

Osszefoglalva: mi pl. nem azert szeretnenk stabil kernel API-t h. ne kelljen kiadni a drivereink forrasat a vevoinknek, hanem mert kemeny munkaorak mennek el azzal, hogy minden egyes valtoztatashoz hozza kell igazitani a sajat forrasban levo driverunk. Magyarul: _NEKUNK_ kerul egy csomo penzbe, hogy vmi idiot odaat atnevezgeti a fuggvenyeket meg a konstansokat, meg ha kell ha nem, belevarial. Azonkivul rohelyes, hogy kb. 2.6.3 ota minden kernelben van vmi bug, ami miatt nem megy rendesen a driver, meg miutan a kernel "ujdonsagaihoz" lett barkacsolva, azutan sem. Szoval f#?szkivan a Linukszal, konkretan.

Es most akkor sem hozom fel peldanak, hogy a Commodore altal 1989 korul a 68k-s OS-hez definialt SANA-II network card API-val miert tudnak menni 2006-ban egy PowerPC-s gepen a gigabites halokartyak... Talan mert ott anno domini nem hitvallast gyartottak, hanem operacios rendszert. Sigh.

In article <42.56667@c.hup.hu>, Balogh Karoly wrote:
> Es most akkor sem hozom fel peldanak, hogy a Commodore altal 1989 korul a
> 68k-s OS-hez definialt SANA-II network card API-val miert tudnak menni
> 2006-ban egy PowerPC-s gepen a gigabites halokartyak... Talan mert ott anno
> domini nem hitvallast gyartottak, hanem operacios rendszert. Sigh.

Miert sejtem, hogy trey erre nem fog erdemben valaszolni? ;)

--
Gabucino

A legeslegjobb a felhasznalonak a gyarto altal adott open source driver. Ezt senki nem vitatja. Jo meg a felhasznaloknak a gyarto altal adott closed source driver, mert jobb -> mint a semmi, -> mint pistike lelkes, faradtsagos, visszafejtos felmegoldas ganyolasai. A leheto legrosszabb viszont ha nincs driver. Ezek kozul lehet valasztani. En nem vetnem el csipobol a masodikat.

Khm..azért azt nem mondanám hogy ma már csak a Video karik 3D támogatásával van baj linux alatt. Akad azért még ott bőven ugye scanner, webcam, hangkari, nyomtató, és még más cuccok is amikkel sokat nem sok mindent tudsz kezdeni. Persze tiszta sor, hogy ilyen más OS alatt is akad, de azért a jelenelgi helyzet nagyon gáz és éppen ez ellen kéne tenni..már amennyire lehet. :(

A). Valoban elfogadhato lenne egy koztes megoldas is, de sajnos a kernel tul gyorsan valtozik, ezt pedig "maganyos farkas" fejesztocsapat nem tudja utolerni.

B). Az, hogy nincs egy kiforrott API, elsosorba koszonheto a videokartya gyartok rossz egyuttmukodesenek is, mint egymassal, mint a kernelfejlesztokkel.

C). Halozati eszkozok terueten elmondhato, hogy mar van normalis API nyilt alapokon. Hangkartyak, szkennerek nyomtatok, adsl modemek, stb teruleten nyilt forras, gpl, anyamtyukja eseten sincsen normalis API, a gyartok egyutmukodese nehany esetben katasztrofalis. A nyilt forras ketsegtelenul elony, de onmagaban keves. Sajnos sok gyarto meg most is retteg, ha az eszkozei 100% mukodnek nyilt alapokon. Lasd: Creative Labs + SBLive!

D). A GKH eleg reszletesen kifejtette, hogy szamtalan pelda van ra amikor elkerulhetetlen az API atirasa. Barki akinek van nyilt forrasu drivere a mainline kernelbe, mar reg nem vagja foldhoz oket ez a kerdes, mert addig nincsen kernel-release sem amig valahol ismert komolyabb problema van. Megvarjak oket, sot segitenek.

Konzekvencia:

1. Amig nincs kiforrott driver, addig nincs kiforrott API.

2. Amig nincs kiforrott API, addig nincs kiforrott driver.

3. Amig, a ket vezeto gyarto el nem kezd egyeztetni a kernelfejlesztokkel valamint egymassal egy kozos API kidolgozasaba, addig nem beszelhetunk az 1. es 2. pontban foglaltakrol. A D) pontban foglaltakkal a gyartok is tisztaba vannak es nem ujkeletu dolog, tehat amig nincs egyutmukodes a gyartoknak a sajat szakallukra kell fejleszteni. Tegyek, elvegre ez a kerdes rajtuk mulik, de ne varjak el egy kernelfejleszto csapattol, hogy kimondottan az o ket szep szemukert kidolgoznak egy fix API-t mindenfele egyuttmukodes nelkul, ami elott minden egyes felfedezett bug/sebezhetoseg eseten terdre kell borulniuk, hozza-nem-nyulniuk, majd szuksegmegoldasokkal teleganyolni a kernelt, nehogy a ket maganyos farkas megszivja. Miert is venne be a felszentelt f*szt a szajaba helyettuk barki is?

4. Novell + IBM hocipoje elobb-utobb tele lesz es nem lepne meg ha elkezdenenek dolgozni egy uj grafikus chipen, nyilt alapokon. Nem kell feltetlen vaddiszno teljesitmenyu kartyara gondolni, de ha van benne egy elfogadhato 3D gyorsitas, akkor vinnek mint a cukrot. Kesobb aztan fejlodhatne is akar es ha kiforrott, megcelozhatna a jatekipart is. Ez magaval hozhatna az igenyt es a lehetoseget is, hogy az X levaltasa mielobb megkezdodjon, es legyen egy mai igenyeknek megfelelo ujrairt szisztema. Ez utobbinak az akadalya elsosorban a ket nagy gyarto magatartasabol kovetkezik.

Meglatasom szerint a kernelfejlesztok celja, hogy a gyartokat egyutmukodesre birja, nem csak a videokartyak teren. Ez hosszutavon mindenkinek jo lesz. Elvegre a gyartoknak sajat erdekuk, hogy az eszkozeik zokkenomentesen mukodjenek.

>hat nem okoztal csalodast snq-, nem tartalak sem hozzaertonek, sem ertelmesnek, es ezt lepten nyomon bizonyitod.

Ne személyeskedjünk szerintem.

Én speciel snq-ot gondolom az egyik leginkább objektív hozzászólónak itt a hup-on.

> 1. a linux hardware tamogatottsaga messze a legjobb az osszes opensource kernel kozott.

Opensource téren nem nehéz neki. BSD-kbe egy cég se nyom bele annyi pénzt, mint a Linux fejlesztésbe, ennek ellenére nem annyival jobb a hardver támogatottsága, mint ebből adódóan kellene...

> 2. minden hardware csaladban van linuxon hasznalhato eszkoz, es midenhez keszul is driver, bar neha varni kell ra 1-2 evet.

1-2 évet? Tudod mit jelent 1-2 év az IT-ban? Simán elavulnak egyes hardverek annyi idő alatt...

"A). Valoban elfogadhato lenne egy koztes megoldas is, de sajnos a kernel tul gyorsan valtozik, ezt pedig "maganyos farkas" fejesztocsapat nem tudja utolerni."

az se lenne utolso dolog, ha kernel alverzionkent nem tobbmegas changelog kisereteben tolnak a faszt a szankba. jelenleg ugyanis ez a helyzet (ertsd: nem feltetlenul kene az ugynevezett stable agban turni es folyamatosan lapatolni a kernelbe az ujabbnal ujabb kodokat). jelenleg ugyanis pontosan ez a helyzet, hogy a "maganyos farkas" fejlesztok kapjak be, majd ok megmutassak, mi a jo. egyes hupdroidok szerint ez a professzionalis fejlesztesi modell (ezen a multkor visitva rohogtem napokig).

"B). Az, hogy nincs egy kiforrott API, elsosorba koszonheto a videokartya gyartok rossz egyuttmukodesenek is, mint egymassal, mint a kernelfejlesztokkel."

erre azert nem mernek merget venni, raadasul ne probaljuk mar bebeszelni magunknak, hogy jelenleg csak a videokartya driverek teren van szopas linux alatt, mert ez nem igaz. ezen tulmenoen tobbek probaltak mar ravilagitani ebben a threadben arra is, hogy az eszkoz felismerese != az eszkoz kepessegeinek teljes kihasznalasaval.

A changelogok hosszusaga valoban durva, de en nagyon bizom benne, hogy ez nem vegleges allapot. Ez rafoghato a fejlesztokre is ugyanugy mint a szervezesre. De hangsulyozom, hogy a kernel merete sem apro.

"erre azert nem mernek merget venni, raadasul ne probaljuk mar bebeszelni magunknak, hogy jelenleg csak a videokartya driverek teren van szopas linux alatt, mert ez nem igaz. ezen tulmenoen tobbek probaltak mar ravilagitani ebben a threadben arra is, hogy az eszkoz felismerese != az eszkoz kepessegeinek teljes kihasznalasaval. "

Zsirfeka: En a C) pontban egy az egybe errol beszeltem, meg peldakat is irtam ra. Nem olvastad el ;)

"A changelogok hosszusaga valoban durva, de en nagyon bizom benne, hogy ez nem vegleges allapot."

sajnos ez megy, amiota a 2.6 "stabil", en mar nem tudok bizni abban, hogy meg fog valtozni.

"Ez rafoghato a fejlesztokre is ugyanugy mint a szervezesre."

ez majdnem lenyegtelen, ugyanis azert a ket dolog osszefugg.

"En a C) pontban egy az egybe errol beszeltem, meg peldakat is irtam ra. Nem olvastad el ;)"

en kerek elnezest :-)

> Es most akkor sem hozom fel peldanak, hogy a Commodore altal 1989 korul a 68k-s OS-hez definialt SANA-II network card API-val miert tudnak menni 2006-ban egy PowerPC-s gepen a gigabites halokartyak...

Ez igy elso hallasra nagyon szepnek tunik, de egy kerdesem lehetne? Ezzel az API-val egyuttmukodnek olyan dolgok, mint peldaul a linuxos NAPI (New API - Improving the performance of a Gigabit Ethernet driver under Linux [icfamon.dl.ac.uk])(mas helyeken polling-nak ismert)? Mert ugye 2006-ot irunk lassan...

Hát nekem edig sikerűlt 2 scenert (azt a ketőt amivel találkoztam) 1 webkamerát, 2 cd írot (abból az egyik NEC DVD normafűgetlen újraíró) beűzemelni és a Tuxracer,meg a Tuxcart sem akad.

Az nforce 4 -es alaplapomon minden funkció kihasználva amíről tudok.

(8 csatornás alaplapí hangkártya, 8usb2 port, optikai kimenet,) A cuc 64 biten dolgozik tőbb játék is van hozzá , 3D modellezőprogram (Blender) Nekem ez így jó ahogy van a forumok segítségével edig mindent sikerűlt összehozni.

Köszönöm.

Joco

"en mar nem tudok bizni abban, hogy meg fog valtozni."

Amikor a Linus atvarialta a kernel fejleszteset+verziszamozasat en abban biztam, hogy a feature-ok tomese, helyett egy stabil kernel kigyurasara fog jobban koncentralni. A disztroknak, rendszergazdaknak ketsegtelenul nagy megkonnyebbules lenne egy hardened kernel. A baj az, hogy amikor megjelenik az uj release, akkor fogjak magukat, felrugjak a stable agat es atvonulnak a kovetkezo projektre, majd kezdik az rc fat. Teszem azt, nekem pl a szerveremen a 2.6.13-as van fent, de nem is szandekozom cserelni nehany honapig, az en celom az, hogy stabil legyen. Vagy netan kockaztassam meg, hogy atterek az uj agra es ki tudja, hogy milyen rejtett sebezhetosegekkel/bugokkal kell szembeneznem a feature-tomesek eredmenyekeppen. Szamomra ez sokkal aggasztobb es gyanitom, hogy nem vagyok egyedul, de a ket videokartya gyartoval szemben ettol meg nem valtozott a velemenyem. Ez alol ok borzaszto egyszeruen mentesulhetnenek. :-)

A masik dolog, nehany evvel ezelott mar volt a "hardened kernel" temakorbol nehany threadnyi flameunk, akkoriban en is fejlesztettem a kernelbe, de remelem megint elojon a tema es ezuttal talan lesz eredmenye. :-)

"en kerek elnezest :-)"

Semmi gond, velem is elofordul. ;-)

snq- wrote:
> 1. a linuxnak csapnivalo a hardvertamogatottsaga
Srácok, múltkor kaptunk egy tesztgépet, amely SAS kontrolleréhez
egyetlen egy OS-hez van driver: a Linuxhoz.

Vegyétek észre, hogy a tíz évvel ezelőtti folyamat megfordult: akkor a
linuxos emberkék könyörögtek a pálya széléről, hogy kapjanak doksikat,
most pedig ők anyázzák a cégeket, ha szar drivert küldenek be a
kernellistára és a cégek könyörögnek, hogy bekerüljön valami a
mainstream Linuxba.

Csak sajnos a kettő közt elmaradt a nyílt forráskód és a szabadon
hozzáférhető tudás eszméje, ezért anyáznak az OpenBSD-sek állandóan. :)

Mészáros András wrote:
> 4. szerintem az a ceg, aki nem adja ki a driver forraskodjat, az mondjon le
> az opensource oprednszer hasznalo vevoirol. mivel ez mar egyre jelentosebb
> tomeg, nagyon meg fogjak gondolni, hogy megtegyek-e.
Szerintem az a cég, amelyik nem adja ki a termékéhez a full doksit,
mondjon le az...

Nekem a nyomtatóm hála az égnek 1 évvel a megvétele után már TUD NYOMTATNI NORMÁLIS SZÍNEKKEL (innovatív fejlesztési modell).

A viszonylag gyors és nekem megfelelően erős 64 MBos Radeon 7000 kártyám meg éppen szobadíszként teljesít szolgálatot, mert Linuxban jó ha a framebuffer konzol hajtására jó, reverse engineered driverrel, nemhogy 3D meg TV-kimenet meg ilyen fölösleges kacatok... Akartam TV-n nézni, kellett vennem új nvidia kártyát, köszönöm szépen...

A fényképezőgépről le lehet szedni a fájlokat... Webcam funkciója is van, nemes egyszerűséggel nem megy, de terminálban (Radeonnal) kinek kell? :PPP

Nem azt mondom a kernelfejlesztők hibája, csak ilyen ***** a helyzet, és sokra nem megyünk vele...

Persze a Linux a Plan9nál (~teljes hw support lista: VESA/Cirrus VGA, néhány hálókari és Creative SB16) sokkal több hardvert támogat, hát örüljünk neki ;P

Micskó Gábor wrote:
> Generic kernel API [0] [marc.theaimsgroup.com]
> [0] http://marc.theaimsgroup.com/?l=freebsd-current&m3149697210510&w=2
Igen, azokat, amiket Scott mond én is végiggondoltam, ugyanakkor úgy
gondolom, hogy hosszú távon megvalósítható lenne az ötlet, legfeljebb a
drivereket ugyanúgy kellene írni, mint bármelyik jelenlegi szoftvert:
bizonyos részek kernelspecifikusak lennének.

/Off on

Öööö... szóval akkor itt csak _hozzáértők_ szólhatnak hozzá?

Nekem megengeded hogy holnap még számítógép elé ülhessek?

Mert ha gondolod, és zavarunk akkor inkább mi haza is mehetünk!

De akkor ki fog a Te hozzászólásodra válaszolni ezentúl?

Egyébként meg annyit az elfogulatlan objektív hozzászólásokról, hogy Te mint a legnagyobb

szemellenzős Linux pap, szoktad remegve habzó szájjal osztani a BSD-t, bármilyen hír kapcsán, hogy bezzeg így, bezzeg úgy, amikor a kutya nem kíváncsi a nagyszerű

világmegváltó naugyemegmondtamhogymegintalinuxajobb típusú

hozzászólásaidra...

Szóval ilyen szempontból sztem nevetséges amit snq- hozzászólása kapcsán írtál. No mind1. Magánvélemény volt, ugyanúgy mint a Te előbbi hozzászólásod.

Peace!

/Off off

vomberg wrote:
> *Gyakorlatilag* egyetlen hardver-csoporttal vannak driver problémák Linux
> alatt, ez pedig a videokártya, az is a 3D gyorsítási résznél. Egy darabig
> nyűgös dolog volt a WiFi, de ahogy nézem már az sem gond.
Nézz már bele pár olyan driverbe, amelyiket mondjuk nem a gyártó írt.

Tele vannak feltételezésekkel, próbálgatásokon alapuló megoldásokkal, stb.

Alig van olyan gyártó, amelyik teljes dokumentációt adna a termékeihez.

Balogh Karoly wrote:
> Es most akkor sem hozom fel peldanak, hogy a Commodore altal 1989 korul a
> 68k-s OS-hez definialt SANA-II network card API-val miert tudnak menni
> 2006-ban egy PowerPC-s gepen a gigabites halokartyak... Talan mert ott anno
> domini nem hitvallast gyartottak, hanem operacios rendszert. Sigh.
Azokkal a gigabites kártyákkal képes vagy mindenféle mai trükk
kihasználására?
vlan, prioritások, jumbo frame, interrupt trükközések, mittudomén. :)

Az API kb. megmondja hogy fogsz kommunikalni a driverrel te, mint TCP/IP stack, vagy mas halozatos szoftver. Nagyjabol az AmigaOS szabvany device I/O API-janak kiterjesztese az egesz, par halozati dologgal (pl. Mac Address Query, es nehany mas dolog). Hogy a driver alatta hogyan intezi a dolgat, pollinggal, interrupttal, esetleg negyvenhat subtaskot inditva, vagy hogyan mashogy, az a driver maganugye. Az API egyebkent az alap funkcionalitason kivul lehetoseget ad arra, hogy minden driver sajat fuggvenyeit, jobbanmondva parancsait is rendelkezesre bocsassa az azt kihasznalni kivano alkalmazasok fele. Parancsait, mert az egesz egy aszinkron message-es felulet, amit custom message-ekkel ertelemszeruen nagyon egyszeru boviteni, a plusz funkciok kihasznalasahoz, mikozben megtarthatjuk a kompatibilitast a regi cuccokkal.

A wireless kartyak pl. igy mukodnek: a TCP/IP stack sima halokartyakent kezeli oket, mig egy kulon beallitoprogram a kiterjesztett "parancsokkal" be tudja allitani a WiFi-specifikus dolgokat. Igy nem kellett szetbarmolni az API-t, nem kellett ujrairni, sot meg ujraforditani sem az IP-stackot, meg semmit. Egyszeru, es nagyszeru. Binaris, es megis rugalmas az egesz. Tudom, UNIX-os fejjel nehez elkepzelni h. valami pici, egyszeru es rugalmas is lehet, de megis... :D

Meg annyi jutott eszembe, hogy egyebkent a fenti eset egy nagyon jo pelda arra, hogy hogyan kell jo, hosszu tavon is hasznalhato API-t tervezni. Nem orulten genericnek kell akarni lenni, nem kell akarni mindent tudni lekezelni, mert akkor tenyleg elobb-utobb modositasra, kidobasra, vagy ujrairasra kerul a sor. Az alap funkciok tamogatasan kivul a boviteseknek kell jol hasznalhato helyet hagyni. Ennyi a titka, szerintem.

"A viszonylag gyors és nekem megfelelően erős 64 MBos Radeon 7000 kártyám meg éppen szobadíszként teljesít szolgálatot, mert Linuxban jó ha a framebuffer konzol hajtására jó, reverse engineered driverrel, nemhogy 3D meg TV-kimenet meg ilyen fölösleges kacatok..."

Az biza fura... Nekem meg PowerMacen, LinuxPPC-vel is megy a full gyorsitott X, DRI es 3D tamogatasa egy Radeon7000-nek... XFree 4.3 + X.Org 6.8.2-vel is... De netan erteni kene hozza? :P Igaz, TV-kimenet, az nincs rajta, ezert azt passzolnam...

engem az bosszant fel a legjobban, hogy ugy turjak a "stable" agat, mint annak idejen a devel-t, amikor meg letezett. most nem letezik. most mindenki beletur mindenhova, mert feltetelnul improve-olni kell mindent, azonnal, mert ettol lesz majd fejlodes, mindenki kussoljon, ok majd tudjak, hogy mi a jo (kinek?).

asszem gsimon irta a nexentas threadben, hogy a fo-fo kernelfejlesztok elitista hozzaallasa mennyire nem jo, es ezzel is maximalisan egyet tudok erteni, foleg, mivel szerintem ez a jelenseg open source korokben egyre inkabb elterjedt es nagyon nem tesz jot senkinek.

a masik tendencia pedig az, hogy a mainline-ba azonnal bele kell tolni minden szart, es igazabol ezt sem ertem. a xen-t nagyon szeretem es igazan kivalo dolog, de remelem, hogy nem fogjak berakni a mainline-ba (minek?). az pedig, amit redhat mondott (t.i. lobbyzni fognak azert, hogy olvasszak be) kurvara nem szimpatikus. annak idejen, ha jol remlik, pont azt hangoztatta mindenki, hogy a linux fejlesztese cegektol fuggetlen es senki nem szolhat bele. nekem az utobbi idokben kicsit mas az erzesem.

1. a linuxnak csapnivalo a hardvertamogatottsaga

2. mindenki biccsel, hogy a cegek nem csinalnak drivert linuxra

3. a cegek szeretnenek drivert kesziteni linuxra

4. a felhasznalok roppantul orulnenek ennek, mert hasznalni szeretnek az eszkozeiket, es nem erdekli oket a politika

5. Mr. Kroah-Hartman es az aranycsapatnak nem tetszik az otlet (illegalis; tehat akkor az nvidia driver is illegalis, es monnyon le)

6. ???

7. sz*pjatok tovabb

Jobbat mondok: miért nincs egy multiplatform driver API?

Lehetnének benne kernel capabilityk, így a kernel tudása szerint differenciálhatna a driver.

Ha mindezt el lehetne sütni úgy, hogy megfelelő számú OS-ben támogatott legyen, elég lenne csak egy drivert írni.

a 4. ponttal egyertertek. A vegfelhasznalok tobbseget nem erdekli, hogy nem eri el az altala birtokolt eszkoz meghajtoprogramjanak forraskodjat, csak az a lenyeg, hogy mukodjon. Aki erzekeny az ilyesmire, az ne vegyen olyan hw-t, aminek nincs nyilt forrasu drivere.

1. es 7. Hm, ez valoban nezopont kerdese. 2.6 ota nem igazan talalkoztam olyan geppel, amiben olyan eszkoz lett volna, amit nem tudtam binux alatt meghajtani. Biztos szerencsem volt.