Lustre (Sun) fejlesztő a Linuxról: a frissítés reverse engineering feladat

Vélemény

Andreas Dilger, a Lustre cluster fájlrendszer (és más, jellemzően tárolással kapcsolatos apróbb dolgok) fejlesztője nem óvatoskodott: egyenesen reverse engineeringnek nevezte azt a munkát, amely ahhoz kell, hogy a Lustre követni tudja a legfrissebb Linux kerneleket.
Mint írja: "az állandó mozgás és a dokumentálatlan változások a kernelben a (Lustre) frissítést reverse engineering feladattá teszik, ezen felül pedig nincs is óriási igény a legfrissebb alapkernelekre".

( BaT | 2008. 05. 16., p – 20:57 )

Épp ma futottam bele egy olyan problémába, hogy 2.6.25-re nem fordul egy alap nvidia kernel, mert a global_flush_tlb fv-t valaki átnevezte cpa_flush_all-ra. Na igen ám, csakhogy hiába írtam át a kódban a függvény nevét, úgy látszik ennyi nem elég hozzá, mert implicit declaration-t ad rá. Na mindegy, annyira nem lényeges.

A Windowshoz sem csak a Microsoft készít drivereket. Múltkor kipróbáltam az OS X-et a fröccsöntött műanyag notebookomon, amelyben inteles szarok vannak (centrino). Ehhez wifi driver nem, vagy csak gyerekcipőben (és csak a driver, amivel nem sokra megyek) van, így előkotortam a fiók mélyéről egy D-Link USB-s wifit és begudtam.
Elcsattogtam a D-Link weblapjára (az OS X-ben ilyen driver nincs), letöltöttem a dmg-t, hármat kattintottam, majd a saját alkalmazásával bekonfiguráltam és már volt is net.

A Windows (főleg az XP) sem támogat szinte semmit (manapság), de vannak hozzá driverek. Az OS X is működhetne ugyanígy.

Eddig az volt a policy, hogy amíg van céges gép, nem veszek notebookot, de lassan lehet, hogy megunom... :)

Szerintem is nagy hiba hogy az Apple a sajat hardware-re korlatozza az OSX-et. Ezek szerint nem en vagyok az egyetlen aki tamogatas nelkul is megvenne a PC verziot, es szerintem vannak meg jo paran. Az hogy jelenleg nincs arra mod legalis keretek kozott hogy valaki akinek mondjuk egy masik (pl Lenovo) hardver jobban tetszik mint egy Apple azert OSX-et hasznaljon az szerintem sajat piacuk csorbitasa attol valo felelemben hogy majd mas hardvereken osszeomlik es csokken a hirnevuk. Ez egy kihasznalatlan potencial amire akkor tettek szert mikor ataltak Intel architekturara ... Amugy akkor mi van ha megveszem az OSX-et de PC-n hasznalom, akkor is beperelnek ? Gondolom elmeletileg igen, de azert gyakorlatilag nezve ha tenyleg igaz hogy csak az OS araig perelhetnek, akkor behajthatjak masodszor ?

Fedora 9 liveCD-ről van szó. :) (Ja, csak ki akartam próbálni kde4 composite képességeit, eddig sehol nem sikerült. :/)

Egész egyszerűen az az ok, hogy hivatalos repoban nincs nvidia driver, freshrpms repoban van ugyan, de az meg elszáll valami lib hibájával. Gondoltam megpróbálom magamnak fordítani, mert a csomagoltban van néhány patch, ami nekem (szerintem) nem is kell. Csak ugye így elveszik az a patch is, amivel működésre bírható. De mivel hirtelen nem találtam a szükséges patchet, gondoltam megpróbálkozok vele én. Mert ránézésre nem tűnt bonyolultnak.

( siposa v | 2008. 05. 16., p – 21:20 )

Legalább bizonyos drivercsoportok felé csinálhatnának stabil API-t (storage, network) aztán majd csak alakulna a többi is szép lassan...

A stabil API nonszensz, meg aztán nincs is rá igény a gyártók részéről (sem).
Azért a gyártóknak csak könnyebb lenne az élete, ha nem Red Hat EL 5-höz, Novell xyz a-hoz, W C D-hez, stb. kellene drivereket kiadniuk, csak Linux 2.6-hoz.
Tényleg nem bírom megérteni, hogy miért olyan nagy dolog egy dollármilliárdos bizniszbe beletenni egy kis "software engineering"-et...

Linus szerint azért, hogy ne akarjanak a hardvergyártók bináris drivereket fejleszteni... szerintem ez rossz hozzáállás. Olyan, mintha a nyílt forrást API-obfuszkálásra használnánk, pedig eredetileg nem erre találták ki.

A másik, ami miatt szerintem nincs stabil API, hogy olyan erőfeszítéseket igényelne a kernelfejlesztők részéről - gondos tervezés, doksik, nehezebb karbantartás - amit nem akarnak felvállalni.

Hát munkahelyen lehet hogy megkövetelik...

Annyiban biztos egyszerűbb így nekik, hogy ha jön az új ötlet, isteni szikra, akármi, akkor különösebb kötöttségek nélkül tudják implementálni. Nem kell egy rögzített, régebbi működési mechanizmus kereteibe beleerőltetni az újat.

Simple, get your kernel driver into the main kernel tree (remember we
are talking about GPL released drivers here, if your code doesn't fall
under this category, good luck, you are on your own here, you leech
<"insert link to leech comment from Andrew and Linus here">.) 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.

HTH

Ja. Gyonyoru elmelet. Aztan jon egy onjelolt messias, aki "cleanup" cimszoval kiszorja az "obsolete" platformok tamogatasat a kernelbol, beleertve az osszes szukseges drivert is. Ugyanez, mikor vica-versa nem hajlandok integralni egy patchet, mert hogy "nincs elegge tesztelve". Es akkor kintvagy a korbol, varialhatod a patched minden egyes minor verziohoz. Az userek meg szep csendben agyfaszt kapnak.

Ez a nem elmeleti resze a dolognak, amit tapasztaltam a sajat boromon az Amiga/68k, Amiga/PowerPC, AmigaOne, Pegasos1 meg Efika support kapcsan. Ja es az Amiga SFS tamogatas is hasonlo cipoben jar. Egyszoval, basszak meg a nemiromidekit a nemiromhol a Linux kernelfejlesztok...

Ehhez kepest bemasolom a 1994-es Commodore halokartya 68k-procis binaris driveret a MorphOS PowerPC nativ TCP/IP stackje ala, vagy eppen a Pegasos II PPC nativ Gigabit ethernet driveret a 68k emuban futo Amigas TCP/IP stack ala, es megy. De persze nonszensz elvarasok ezek, mint tudjuk, csak halott platformokon foglalkoznak ilyen elavult dolgokkal...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Meghajlok erveid nagysaga elott... Amugy ketsegtelen h. a Linux fejlodik. A fejlodes iranya a kerdeses. Es majd irok egyszer egy szosszenetet errol a binary compatibility-rol, mert nagy kaosz van a fejekben ezzek kapcsolatban ugy latom, es eleg sok nagy mellennyel nyilatkozo embernek fingja sincs arrol, hogy ezt megis mekkora feladat megvalositani, egy normalisan megtervezett rendszeren.

Egyebkent, hogy mi fejlodik es mi nem... Egykor, nem is olyan reg, minden Linux elonyeit taglalo iras azzal kezdodott, hogy hat a Linux elmegy a legcsoffadtabb oreg vason is, nem kell hozza csilivili uj gep, mint a Vindozhoz, es tamogatja a legegzotikusabb sosevolt kartyakat is. Ehhez kepest nemreg az Ubuntu 8.04 hardverigenyet ugy sikerult lereagalni, hogy "vegye' meg 1 giga ramot, mer' occso!", ha valamit nem tamogat akkor meg "hat nyilvan, mert szar, vegye' ala normalis hardvert!".

Valtoznak az idok. En azert orulok, hogy van ami allando, es nem fejlodik ilyen hetmerfoldes leptekkel... IMHO persze.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

read: azok az it nagyvállalatok akik gyakorlatilag birtokolják (az és úgy kerülhet bele amit mi mondunk, kernelfejlesztők függenek tőlünk egzisztenciálisan) a linuxot, illetve közép- vagy hosszútávon szeretnék meglovagolni ($$$) a linuxhypeot, szeretnék, hogy mindeki szépen adja oda az eszközmeghajtóját nekik, mert csak

Illetve adjon dokumentációt és teszthardvert és majd __ingyen__ lefejlesztik és helyette __karbantartják__ (a Novell támogatásával) a mainline kernelben a driver-t. Jah, hogy ez nem kell? Akkor lehet sipárogni tovább. Senkit sem érdekel, szíjjon gázt. Eddig is ki tudtam választani azokat a vendorokat, akiknek a hardverei támogatottak és ezután is ki fogom.

--
trey @ gépház

Például a cciss, vagy hogy hívják (HP-kben domináns) legendásan csúcsszuper.

Hülye HP, még saját maga is kiad egy drivert, ahelyett, hogy csak a kernelben peccselgetné (bár: "Use these for systems using 2.6 kernels later than about 2.6.15. From 2.6.11 to 2.6.15 is kind of a gray area during which some kernel interfaces the driver relies upon were in flux."), biztos vannak, akik nem akarnak a bleeding edge kernelben lévő régebbi driverrel menni, inkább felteszik a bleeding edge drivert a régebbi kernelre.

Vagy valami ilyesmi. :)

A 2TB-nál nagyobb volume-ok szerencsére nem érintenek. Ennek ellenére mint érdekesség, szívesen utánaolvasnék. Gondolom bugreport volt. Esetleg egy linket vagy valamit kaphatnék?

Ilyen driverrel hajtott gépeken partnereknél mennek Oracle adatbázisok RHEL alatt látszólag problémamentesen évek óta.

A "lassú" számban kifejezve mit jelent? Itt van mellettem egy DL 380 ilyen driver hajtotta vezérlővel, Linux fut rajta. Megnézném ezen mit tud. Rohadni nem rohad.

--
trey @ gépház

Értem én, hogy ha elfogy az érv, akkor elütjük tréfával, de a logika hinyzik belőle. Legalábbis nekem.

Csak a játék kedvéért...

Tehát rettegnek, hogy azok fejlesztik le a driver-t, akik magát a Linux-ot fejlesztik. Azt a kernelt, amihez a vendor _szeretne_ driver-t. Őőő, miért is szeretne akkor egy olyan kernelhez driver-t, amit olyanok fejlesztenek, akiknek a munkájától rettegni kell?

--
trey @ gépház

>> Tehát rettegnek, hogy azok fejlesztik le a driver-t, akik magát a Linux-ot fejlesztik.
igen

>> Azt a kernelt, amihez a vendor _szeretne_ driver-t.
nem

>> Őőő, miért is szeretne akkor egy olyan kernelhez driver-t, amit olyanok fejlesztenek, akiknek a munkájától rettegni kell?
látod ezt kérdezem és is

Miért a HUP linuxos olvasói jelenleg braille rendszeren tapogatják le a tartalmat? :)

Egyébként ez megint a szokásos Linux trollkodás a részedről. Ugyanígy várják a NetBSD, OpenBSD, FreeBSD és többi felhasználók is, akiknek hiperszuper kiváló stable API-juk van. Mégis a hajukra kenhetik az egészet. Ettől még nem lesz jobb az NVIDIA driverük.

--
trey @ gépház

Megpróbálom cégként végiggondolni ezt a dolgot (azaz azt, hogy a linuxos fejlesztők ingyen fejlesztenek drivert, és ez miért nem jó nekem -hiszen nem jó, ha jó lenne minden cég ezt választaná-).

Van most egy csapatom, amely azért nem olyan nagyon drága, de nem is olcsó. Ha megtakaríthatnám a fejlesztési, kutatási, tesztelési, stb. költségeket, jobb lenne nekem, hiszen megkapnám ugyanazt, ingyen.
De megkapnám ugyanazt?

Hardver gyártóként abban vagyok érdekelt, hogy az elterjedtebb (ahol van megfelelő felhasználói igény) platformokon használható legyen a hardver.
Ez jelentse mondjuk -szerver alkatrész és x86 esetében- a Windowst, a Solarist és a Linuxot.

Úgy döntök, hogy kirúgom a driveres csapatot és kiadom a fejlesztést ingyen a linuxosoknak. Ők lefejlesztik a drivert, amire semmilyen ráhatásom nem lesz. Nem tudom garantálni, hogy a legújabb vasaimat (jól) támogatja majd, nem tudok QA-t végezni (nincs mivel, kirúgtam őket), ha felhasználói elégedetlenkedés van, az az én bevételeimet csökkenti és azt azért nem kellene mondani a milliárdos Linux biznisz közepén, hogy "sorry, nem én fejlesztem a drivert, írj bugreportot az lkml-re".
Aztán vegyük a többi platform kérdését.
Jó, Linuxra van (valamilyen) driverem, de mi van a Solarisszal és a Windowszal? A drivereseket kirúgtam, ki portolja ezekre a linuxos drivert? Vagy írjak újat? De akkor miért rúgjam ki a drivereseket? Sőt, ha nem kell őket kirúgnom, vajon megéri-e egy teljesen független linuxos drivert "kiadni" a linuxos fejlesztőknek, amikor a saját csapatom eleve képes úgy drivert írni, hogy az nem túl nagy extra költség mellett működjön Linuxon, Solarison és Windowson is?
De mi lenne, ha csak a driveresek felét rúgnám ki, a linuxos drivert ingyen lefejlesztenék a linuxosok és én csak a portolással foglalkoznék?
Úgy látszik, hogy a linuxosok ismerik a saját kernelüket és eleve nehezen portolható drivert írnak, olyat, amit például Solarisra áttenni majdnem felér egy új írásával.
Azaz ez sem jó, mert nagyobb munka lenne, mint sajátot (eleve portolhatóan) megírni, karbantartani.

És mi lenne, ha mégis működne ez? A GPL nem korlátozna? Hiszen van egy linuxos, GPL-es driverem, amit nagy nehezen átportoltattam a driveres csapat felével (vagy ugyanakkorával, hiszen a portoláshoz is komoly tudás és erőfeszítések kellenek, főleg egy Linux-only kódnál, amely ráadásul havonta változik az API-kkal együtt). Mi van, ha ezt módosítom és a Solaris mellé akarom adni? Bekerülhet egyáltalán a Solaris kódjába?

Azt hiszem cégként kb. ezeket gondolnám végig. Valahol itt lehet a kutya elásva.

Tökéletes okfejtés.
Még egy apró adalék: egy adott branden belül a különféle kártyák tudását időnként a driverekkel limitálják. Vagyis occsób kategóriában is benne van az a tudás, mint ami a kicsit drágább kártyában - csak driver szinten nincs implementálva.
Hogy nézne ki a világ, ha a linuxosok kihozzák a low end kártyából azt a tudást, amit két árkategóriával feljebb akartak csak eladni.

Nem tudom, hogy tökéletes-e, mindenesetre döntéshozóként én ezeket gondolnám végig és egészen biztosan a saját driver mellett döntenék.

Úgy gondolom, hogy ez az "ajánlat" a linuxos oldalról nem sok kockázatot rejtett emiatt, hiszen tudják ott is, hogy kb. milyen döntési mechanizmusok működnek egy cégben.

Értem. Akkor a Linux kernel egy öncélú játékszer pár hülyegyereknek, akik elvannak a saját homokozójukban és mindenki más (akinek munkája nem kerül vagy kerülhet bele) le van tojva?

A tudomány mai álláspontja szerint nem ennek kellene lennie, de ezzel, hogy gyk. szándékosan hátráltatják mások munkáját (szvsz. a Linux kernel már túl van azon, hogy Linus kísérletezése legyen) eléggé az előbbi benyomást keltik.

Csak nem lehetnek annyira hülyegyerekek, ha olyanok fizetik őket, mint az ibm, intel, sgi, stb...
Mindenesetre a "homokozó" az ő munkájuk eredménye, úgyhogy ott ők hozzák a szabályokat. Ha ez másnak nem tetszik, akkor nem muszáj abban a homokozóban játszani: lehet menni pl. egy bsd-s homokozóba, ott van már az opensolaris homokozója is, végső esetben meg lehet építeni saját homokozót.

A tudomány mai állása pedig holnap már csak a tudomány tegnapi állása lesz...

Na akkor azt mond meg: a Linux kernel a fejlesztők öncélú homokozója, vagy egy olyan valami, amit azért fejlesztenek, hogy mások használják?

Előbbi esetben nincs több kérdésem, utobbi esetben mingyárt megkérdezném azt is, hogy akkor miért tolnak ki azokkal, akik használni szeretnék/veszik figyelembe azok igényeit?

Dolgoztam egypar szoftverceggel, es alhiheted, hogy a legprofibb helyeken is igy megy. A legjobb amikor egy munkatars ir valamit, aztan tavozik a cegtol, majd jon az utodja o is ir valamit, majd o is tavozik a cegtol. Es ket vagy harom ev mulva realizaljak a cegnel, hogy potseged fogalmuk sincs az adott resz mukodeserol.

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

"A másik, ami miatt szerintem nincs stabil API, hogy olyan erőfeszítéseket igényelne a kernelfejlesztők részéről - gondos tervezés, doksik, nehezebb karbantartás - amit nem akarnak felvállalni."

Hogy lehet egy kernelt bármilyen komolyabb szoftvert tervezés nélkül fejleszteni?

Karbantartásnál meg nem tudom miben nehezebb, hiszen pont arról van szó, hogy egy csomó dolog amiatt nehezen karbantartható, hogy folyton változik ez-az.

Dokumentálni meg eleve illene, viszont ha nem változtatnak mindent folyton, akkor elvileg a változtatásokat se kellene dokumentálni :)

"szerintem ez rossz hozzáállás." Nem is kicsit. Mai napig probléma, hogy kevés a driver és még tesznek is azért, hogy még kevesebb legyen...

( Hiena v | 2008. 05. 17., szo – 09:36 )

Alapvetoen a legnagyobb problema, hogy a kernel-fejlesztes nem foallasu munka. A kernel-fejlesztok nagyon szeles spektrumon mozognak, van aki kieletlen porgramozoi vagyait teszi bele (a'la sysfs), van aki a helloworld.c utan szeretne valami komolyabbat, es valaki csak egy nyomorult eszkozt akar mukodesre birni.
Emiatt nincs bebetonozott API, folyamatosan valtozik az egesz, es 900+ sornyi egyhuzamban valo kodolas utan a kutya sem fog dokumentaciot irni. Emiatt aztan amikor valaki kernelpiszkalasba fog, akkor jo esetben egy mar mukodo kodreszt fog atszabni az igenyeinek megfeleloen, ami miatt alapban mar egy hibalehetoseg tovabbgorgeteset rejti magaban.
Tovabbi gond a monolitikus kernel szemlelet eroltetese. Ez nagyon kenyelmes, mert nem kell API-t definialni, es jol el lehet az ember a susnyakosban, mert buntetlenul ganyolhat megy - nem megy alapon. Csakhogy, kellemetlen amikor hot-plugrol, automatikus hardver felismeresrol van szo (Udev-es viccrol ne is beszeljunk), a 3rd party hardware gyartot meg a hideg razza ki tole. Ugye, senki se varja el, hogy majd egy ceg leborul a memoriakezeles iroja elott, hogy javitson mar ki egy icipici hibat, hogy futhasson az O vasukon is a driver.

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

Ok. Pontositok.
A linux kernel fejlesztoi kozul, százalékosan milyen aranyban vannak akik foallasban linux kernelt fejelesztenek?

A kernel-fejlesztoi munkakor (legyen szo barmilyen operacios rendszerrol) egy igen szuk terulet. Ahhoz, hogy valaki jot, eloremutatot tudjon alkotni nagy foku elhivatottsag, tehetseg, es igen szeles ismeretkor szukseges. Egy multiplatform kernel eseteben, minden egyes architekturaval szorzodik ezen ismeretek szuksegessege.

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

"A linux kernel fejlesztoi kozul, százalékosan milyen aranyban vannak akik foallasban linux kernelt fejelesztenek?"

Az ilyen fejlesztők számánál jóval nagyobb jelentőségű, hogy milyen arányban járulnak hozzá a kernel fejlesztéséhez.

http://hup.hu/cikkek/20080401/linux_foundation_whitepaper_a_linux_kerne…

Bár arra nem térnek ki, hogy ki csinálja főállásban, és ki nem, az mindenesetre jól látható, hogy a cégek által támogatott fejlesztők hozzájárulása dominál.

( sjrextor | 2008. 05. 17., szo – 09:55 )

Én a Sun-t nem bírom követni, hogy hol bratyizzák a GNU/Linux-ot, hol meg fikázzák. Ennek a követése is reverse engineering?

A Sun gyűlöli a Linuxot, mint a friss szart. Miért lenne másképp?
Szeretni legfeljebb akkor fogja, amikor a Solaris sírkövét már benőtte a gaz és a hardver (ha akkor még árul hardvert), a szolgáltatás (ha akkor még szolgáltat) és az egyéb termékekből (ha akkor még lesznek egyéb termékei), azok járulékos bevételeiből lesz minimum akkora, de inkább nagyobb nyeresége, mint most -a Linuxnak köszönhetően-.

A Linux konkurencia nekik, ráadásul az egyik (ha nem a) legnagyobb, mert alulról egyértelműen lecsavarta már a töküket (bár egyesek szerint a T1-T2-es platform olyan nagyon jól teljesít, én így kívülről ezt nem látom ennyire egyértelműnek, főleg az általános low-midrange x86-os eladásokhoz képest) és úgy tűnik, hogy a fejüket is le akarja tépni.

Sok helyen (hogy a saját környezetemről ne is említsem) tapasztaltam azt, hogy a SPARC-os vasakat -ha lehetett- leváltották Solaris/x86-os vasakra (először sunos hardverre, majd mikor rájöttek, hogy az milyen rohadt drága, másra), aztán mivel a SPARC-on edződött adminoknak az x86 már nem volt annyira trivi, jöttek a csillogó szemű fiatalok és behozták a Linuxot.

És úgy látom a programozók is kezdenek magukhoz térni és lassan felkészülnek arra, hogy nem az a jó megoldás, ha egy nagy, übermegbízható (hahaha) vason fut a cucc, hanem ha sok olcsó szaron, redundánsan, hibatűrően. Szerintem ezt mutatja az is, hogy mennyi kommunikációs (open source) library fejlődött az elmúlt pár évben és a cluster -hálózatos, elosztott- fájlrendszerek is gombamód szaporodnak, az ezeket használó, vagy saját utakon járó önálló megoldásokról már nem is beszélve.

Nos sztm egy ceg nem "gyuloli" a linuxot, ugyanis a Sun is tamogat pl SuSE-t, es a Microsoft is forgalmaz SuSE-t. Egyszeruen mas a fo profil. Es annak pedig konkurencia a Linux ahogy mondottad is.

Es attol ha vki kifogasolja a Linux fejlesztesi menetet, attol az mar szemet, Linuxgyulolo, SUNberenc?
Ez mar kicsit mintha vallasi felhang lenne, nem technikai, ami ebben a temaban altalanosan elofordulo nagy baj.
Sztm igenis gaz ugy uj kernelekhez fejleszteni, hogy az ember nem gyozi kovetni pl az emlitett pelda alapjan a fuggvenynev valtozasokat. (Tuloztam, gyanitom, hogy a core reszekben ilyen relative ritkan tortenik.) Szal azert nem csak azt kene nezni, hogy aki a Linuxot fikazza, az SUN/M$berenc, es akkor hulye is. Bizony nem mind arany ami fenylik.
Valoszinuleg a stabilitast nyujtani kivano termekek ezert epulnek meg 2.6.18-ra, etc. A legujabbat meg nyustolje aki bator. De ettol a SUNos srac megallapitasa meg igaz. (S biztos a linuxgyulolet jele, hogy bar Sunosok, a Linuxhoz is fejlesztenek.)
Amugy nem tartom kizartnak, hogy ez egy olyan kenyszerito eszkoz is, hogy inkabb add kozre a cuccodat, tegyek be a vanillaba, s akkor az ilyen valtozasok - elmeletileg - kezelve lesznek.

A csillogo szemu fiatalokkal akik linuxot hoznak, sokszor meg az a baj mint a csillogo szemu windowsosokkal, azt hiszik, hogy ha mar beuzemeltek egy ftp szervert akkor mar adminok:) Szal sokan csak azt ismerik, ezert hozzak be. Ezzel nem az embereket fikaznam, hanem azt akarom mondani, hogy attol, hogy az uj emberek uj rendszert hoznak, az nem feltetlenul az uj rendszer jo minoseget jellemzi.

Az elosztottsag valojaban trend, s a mainframe-ekrol elmozdulas is. De sztm a Sun mozdult is erre az iranyba. A vasaik sosem voltak olcsoak, de sztm akik elosztott rendszereket epitenek, altalaban ugyis nagy beszallitoktol (HP, DELL, SUN) rendelik a vasakat, nem a sarki PCboltbol hoznak meg egyet, garancia, kedvezmenyek, egyebek miatt. A premium cuccaik a HPnek meg a DELLnek sem olcsoak.

Egyebkent az elosztott rendszer sokszor nem megoldhato, es mas hibalehetosegeket hoz be, de ez mar egy masik tortenet...

( turul16 v | 2008. 05. 17., szo – 11:59 )

Azert ne keverjuk egy driver vagy egy ClusterFS problemajat dokumentaltsag/API valtozas ugyileg.
Linux ala konnyu drivert fejleszteni, ha van jo dokumentaciod a hardwerrol es erted hardware mukodeset.

Linux kernelrol, driver modelljerol, memoria kezelseserol,.. sok konyv es hoszabb iras jelent meg. De alapjaban veve RTFS hozzallas dominal, a kod teli van megjegyzesekkel is.

Ha mar Sun-os emberke "ugat", akkor kerem szepen mutassa meg, hogy naluk milyen publikusan elerheto szep kernel dokumentacio van, nem hiszem, hogy OpenSolarissal jobb lenne a helyzet.

Az OpenSolaris forraskodja szep es olvashato, persze vannak olyan reszek, amik itt is csunyak, es tudja a table api nonsense-t, amit a linux nem (sot, meg a stable abi nonsense-t is). Ha jo Solaris kernel dokumentaciot akarsz, akkor Solaris Internals, es a Second Edition. A Second Edition-ben nincs benne az, ami az elso ota valtozatlan (pl. boven a modularis utemezorol), viszont az igen, ami a Solaris 8-ban meg nem volt, Solaris 10-ben viszont mar igen. Egyebkent erdekes megfigyelni, hogy hogy fejlodik a Solaris kernel. 2-3 evvel ezelott az x86os Solaris meg egyertelmuen subsetje volt a SPARC-osnak. Ma mar van olyan, amit az x86os tud, es a SPARCos nem. A commodity hardver tamogatas is egyre jobb, eleg sok az olyan commit, ami a community felol jon es nem foallasu Sunos kernelfejlesztotol. Az opensolaris.org-on egyebkent eleg sok dokumentacio van, plusz van egy jo source reader is.

Szerk: docs.sun.com-on is eleg sok jo dokumentacio van (Sunos compiler, x86 es SPARC assembly guide, how to write solaris device drivers). A cimeket fejbol irtam, de docs.sun.com-rol le lehet tolteni a pdf-eket.

Latszik, hogy egy bizonyos szinten tul egyik sincs kulon dokumentalva, es johet "reverse engenering".
Ami erdekes , 2.6.0 linux kernel -hez 748oldalas dokumentum jelent meg csak memoria kezelesrol. Erdemes lenne megnezni, hogy menny maradt igaz meg belole, mikozben tudjuk, hogy azota rengeteg minden valtozott ezen a teren is. pl. 30 oldal szol SLAB-rol ami mar nem az alap ertelmezett, de meg mindig valaszthato.

Azert ne keverjuk egy driver vagy egy ClusterFS problemajat dokumentaltsag/API valtozas ugyileg.

O, dehogynem lehet oda keverni, leven valami alapjan csak le kell fejleszteni az adott interfacekat. En is mocskosul ruhellem, mikor melo kozben hirtelen megvaltozik valami, es az adott kod egyaltalan nem, vagy ami rosszabb hibasan kezd el mukodni egy nem dokumentalt eset miatt. Toltottem mar napokat debuggolassal mert az egyik ISO draft menet kozben megvaltozott, csak errol elfelejtettek szolni. Aztan nemi anyazas utan megallapodtunk abban, hogy ha ilyesmi van, akkor doksiba atvezetes + legalabb egy mail arrol, hogy vmi valtozott.

---
pontscho / fresh!mindworkz

Ha tenyleg csak a neve valtozik, akkor jobban ileszkedhet az elnevezesi konvenciokhoz.
Az ilyet 5 perc alatt le lehet kovetni.

Persze, a külső kernel modul fejlesztő, meg rakhatja az ifdef-eket a kódjába, ha azt akarja, hogy a 3 hónappal ezelőtti és a mostani kernelen is menjen a modulja.
A kernel fejlesztők kvázi átdobták a szart a szomszédba.