[lordrolee]

Épp akartam írni, hogy a windows nem szar attól mert kékhalál. Egy dump-ból sokszor több információ nyerhetõ ki, mint egy egyszerû hibaüzenetbõl. Persze tudni kell értelmezni.

[debaj]

Idézet: Macikák - Dátum: 2009. ápr. 3., péntek - 10:07

2. Ergo, mégis az oprendszer a (ar, mert annak egy drájver
inkompatibilitást, talán nem így kéne lekezelnie, hogy az egész
elhasal... 

Hanem mit csináljon a szerencsétlen? Te is elájulsz, ha jól kupánvágnak, nem kezdesz el okoskodni meg akadékoskodni. Ezen maximum a virtualizált kernel segíthetne, csak akkor ugyanahhoz a teljesítményhez kétszerakkora gép kéne. Szar drivertõl a Linux meg a Mac OS X is megfekszik, nem csak a vindóz.

Átlagjúzernek meg tökmindegy, hogy mitõl kell újraindítani a gépet, a kékhalál nem is neki való, hanem a szakembernek. Az meg vakargathatná a fejét, ha úgy magyarázná el a hibát a kékhalál, hogy az egypontnulla is megértse, és semmi olyan ne legyen a hibaüzenetben, ami összezavarhatná.

Szerkesztette: debaj 2009. 04. 03. 09:38 -kor

[didyman]

Idézet: Macikák - Dátum: 2009. ápr. 3., péntek - 9:07

Az, szerintem... 

Az én gépemben az is csoda még, hogy nem heti
szinten kell Ghost-ozni -- annyi minden van benne
és rajta... 

Itt a vonatkozó szekció... 

NB.: Az azért elgondolkodtató ha így saját magadat
visszaolvasgatod...  Hogy ezt sem szabad, azt sem, hát... 

1. Egy olyan mélyen láma átlag user például ezt honnét tudná???
Honnét kéne tudnia??? Miért is kéne, hogy érdekelje EGYÁLTALÁN,
miféle chip(ar van a micsodájában??? Miért kéne ELFOGADNIA,
hogy õ biza, nem TV-zhet és játszhat eccerre???

2. Ergo, mégis az oprendszer a (ar, mert annak egy drájver
inkompatibilitást, talán nem így kéne lekezelnie, hogy az egész
elhasal... 

Nem brooktree, hanem philips SAA7130. Azt annyira nem ismerem.

Nem tudom, nekem ez kicsit magas, tévénézés közben miért kéne játszani valamivel? Egyáltalán hogy lehet azt, C&C Generals, bal alsó sarokban a Scud Launcher mellett meg megy a bóbitás hamupipõke?

Az oprendszer a szar. Esetleg nem az illesztõprogramot készítõ cég felelõssége, hogy a rendszerhez illeszkedõ valamit készítsen, ami képes lekezelni normálisan egy erõforrás foglaltságát? A Windows sebezhetõ ilyen oldalról (ami tényleg nagy hibája, bár ennek jelentõsége az NT5 óta sokkal kisebb), a felépítésébõl fakadóan, de ha már van egy autóm, ami mondjuk hidegen indítva padlógázzal hamar hengerfejes lesz, akkor szerintem nekem (a programozónak, nem a végfelhasználónak) illenék tudni, hogy egy kis járatással ez megelõzhetõ és még akkor sem várom el az ECU-tól, hogy hideg motornál szóljon be.

[Macikák]

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 10:40

Az oprendszer a szar. Esetleg nem az illesztõprogramot készítõ cég felelõssége, hogy a rendszerhez illeszkedõ valamit készítsen, ami képes lekezelni normálisan egy erõforrás foglaltságát? A Windows sebezhetõ ilyen oldalról (ami tényleg nagy hibája, bár ennek jelentõsége az NT5 óta sokkal kisebb), a felépítésébõl fakadóan...

Húúú... akkor Philips... Volt nekem még leánykori néven
CONEXANT is -- az simán kifingott...  :Ð

Oprendszert illetõen az XP megjelenésekor az ugye nagy ficsör volt,
hogy a döglõdõ szoft-ot nagykegyesen be lehetett már zárni (már
amelyiket), és nem dobott kékhalált az egész (arkupac mint a
9x-ek, hm! Ez valóban gigantikus vívmány... 

És ezzel M$ verte magát -- tehát a dolgot az oprendszer felõl nézte,
hogy "lám, ez milyen szuper Windows!"... 

Természetesen, nézhetjük a Te oldalad felõl közelítve is a dolgot!

 

[Macikák]

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 10:36

Te is elájulsz, ha jól kupánvágnak, nem kezdesz el okoskodni meg akadékoskodni.

Én kipurcanok mert emberbõl vagyok... 

Oprendszernek pedig ilyen esetekben illene lekezelnie a hibát,
aztán tojni rá és mûködnie tovább...  :Ð

"Csak" ennyi a különbség! 

[Macikák]

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 10:40

Nem tudom, nekem ez kicsit magas, tévénézés közben miért kéne játszani valamivel? Egyáltalán hogy lehet azt, C&C Generals, bal alsó sarokban a Scud Launcher mellett meg megy a bóbitás hamupipõke?

Túlbonyolítod... Megint! 

Csak a TV HANGJA kellett volna (idõjárásjelentés),
de mivel nem Onyutha-anyuka volt, gondoltam, közben
megnézek egy játék-demót...  :Ð

Az XP pedig mást gondolt...   

[debaj]

Idézet: Macikák - Dátum: 2009. ápr. 3., péntek - 11:01

Ez valóban gigantikus vívmány... 

Nézd, erre semmi szükség nem lenne, ha a programozók vennék a fáradságot, és a szoftvereikben lehetetlenné tennék, hogy mondjuk egy változóba nagyobb értéket írjanak, mint a neki lefoglalt memória mennyisége. Ez szoftverenként viszonylag kicsi plusz munka, a legtöbben mégis szarnak rá. Aztán ha az oprendszer nem védi a saját folyamatait, akkor egy ilyen túlcsordulás szépen telefos valami fontos memóriatartományt, és a gép összehányja magát. Ezért meg kell úgy írni, hogy minden esetben védve legyenek ezek a folyamatok, és ez már nincs meg egy feltételellenõrzéssel meg egy kivételdobással. De ettõl maga a szoftver nem lesz kevésbé gány, csak megfogják a kezét mielõtt hülyeséget csinálna.

Ez körülbelül ugyanaz, mintha a kocsiba kellene beépíteni olyan rendszert, ami nem enged az aktuális sebességkorlátozás fölé menni, vagy olyan üzemanyagtartályt, amibe kizárólag azt a benzint tudod tölteni, amit a gépkönyv elõír, de úgy, hogy a kutakhoz ne kelljen hozzányúlni. Jóval egyszerûbb lenne betartani a KRESZ-t meg tankolás elõtt elolvasni, hogy melyik tömlõbõl milyen benzin folyik, de minek csináljunk ilyet, a kocsi szar, ha nem gondolkodik helyettünk.

[debaj]

Idézet: Macikák - Dátum: 2009. ápr. 3., péntek - 11:05

"Csak" ennyi a különbség! 

A hibás driver a kernelfolyamatokat bassza szét, általában ott már nincs lehetõség hibajavításra, a rátojásra meg a továbbmûködésre meg pláne nem. Ezért példálóztam a fejbeveréssel, mert miután megkaptad, már kalap, kabát.

Meg lehet oldani azt is, csak éppen sokkal bonyolultabb munkával és több elpocsékolt erõforrással (plusz több friss hibalehetõséggel), mintha azt a nyomorék drivert írnák meg biztonságosra.

[Macikák]

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 11:14

Nézd, erre semmi szükség nem lenne, ha a programozók vennék a fáradságot, és a szoftvereikben lehetetlenné tennék, hogy mondjuk egy változóba nagyobb értéket írjanak, mint a neki lefoglalt memória mennyisége.
Ez körülbelül ugyanaz, mintha a kocsiba kellene beépíteni olyan rendszert, ami nem enged az aktuális sebességkorlátozás fölé menni...

Objektum-orientált programozás picikét már másképp zajlik...  :Ð

Az én programomhoz is a VB-telepítõkészlet gyártó bizgentyûje
még hozzámásolt 2 marék DLL-t, hogy ezek kellenek, fogalmam se
hogy mik, de nem is érdekelt... 

Minden "új" BMW lock-olt már, elektronikusan, és nem picit
bonyolultan...  :Ð

Bocsánat...   

[debaj]

Idézet: Macikák - Dátum: 2009. ápr. 3., péntek - 11:22

Objektum-orientált programozás picikét már másképp zajlik...  :Ð

Papíron. A gyakorlatban meg lapátolhatod a szart azok után, akik még elhiszik, hogy az ojjektumorientált programozás megvéd a memóriatúlcsordulástól, úgyhogy szarnak is a hibakezelésre erõsen káposztalevéllel.

Java lekezeli, hogyispersze, mikor hogy, C++ már nem annyira. Destruktor mond valamit?

[Macikák]

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 11:28

Java lekezeli, hogyispersze, mikor hogy, C++ már nem annyira. Destruktor mond valamit?

Mond, bár a C++ mint olyat, utálom... 

Elõször JAVA-ban kezdtem, de elakadtam -- meg idõ se volt... 

A VB for Mazsolák viszont éppen megfelelt...  :Ð

[didyman]

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 10:28

Papíron. A gyakorlatban meg lapátolhatod a szart azok után, akik még elhiszik, hogy az ojjektumorientált programozás megvéd a memóriatúlcsordulástól, úgyhogy szarnak is a hibakezelésre erõsen káposztalevéllel.

Java lekezeli, hogyispersze, mikor hogy, C++ már nem annyira. Destruktor mond valamit?

Heheh. AMikor mi még azt sem tudtuk, miért jó az OOP, már akkor sikerült olyan programot írni C-ben, amivel csontra dobtuk a debuggert, a C-t,vagy a gépet. Akarat kérdése :Ð

[Sparow2]

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 10:19

A hibás driver a kernelfolyamatokat bassza szét, ...

Az IA-32 CPU-kban lévõ védelem segítségével ez elkerülhetõ volna.
Hiszen minden egyes processz külön virtuális memóriatérben fut. Egyáltalán nem volna kötelezõ más rendszerprocesszeket tönkretennie egy drivernek azért, mert hibásan van megírva.

Az Intel CPU-k védett módja direkt a programozási hibák elleni védelmet szolgálja.
Azért lett kitalálva, hogy az oprendszert ne borítsák fel a hibás userspace programok és hibás driverek. (Különben visszamehetnénk a 386 elõtti idõkbe, amikor userspace programból letiltható volt az összes megszakítás, és akár megállítható volt az egész oprendszer; vagy felül lehetett vágni az oprendszer memóriaterületeit. Manapság ez userspacebõl már nem megy, de driver szintrõl még azért igen)

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 10:19

... általában ott már nincs lehetõség hibajavításra, a rátojásra meg a továbbmûködésre meg pláne nem. Ezért példálóztam a fejbeveréssel, mert miután megkaptad, már kalap, kabát.

Jó, elképzelhetõ olyan driver, ami létszükséglet a mûködéshez (pl. diszk rendszer drivere megáll, akkor többet nem lehet olvasni/írni a diszkeket, és le kell állni --bár erre is lehetnek technikák, pl. több szálon fut ugyanannak a hardvernek a drivere, és ha egyik szál megáll, akkor egy másik átveszi a munkáját, amíg a leállt szálat újraindítja az oprendszer--), de pl. egy hangkártya driver ha elszáll, milyen jó volna, ha nem vinné magával az egész oprendszert (max. hang nélkül menne tovább; vagy esetleg újra is indítaná az oprendszer a drivert).

Idézet: debaj - Dátum: 2009. ápr. 3., péntek - 10:19

Meg lehet oldani azt is, csak éppen sokkal bonyolultabb munkával és több elpocsékolt erõforrással (plusz több friss hibalehetõséggel), mintha azt a nyomorék drivert írnák meg biztonságosra.

Éppen ez az! Hogy a driverben mindig lehet hiba, hiszen azt külsõs cégek írják, ráadásul rengeteg külsõs cég. (Ráadásul ezt védené ki a védett mód)
Ettõl nem biztos, hogy sokkal több hibalehetõség volna, vagy sokkal bonyolultabb volna az oprendszer, hogy ha leáll egy driver processz, vagy adott kérésre nem válaszol, akkor kilövik (és esetleg újra elindítják).

Csak annakidején nem ez volt a koncepció, vagy nem így alakították ki.

Több elpocsékolt erõforrás??? A Vistának a normális mûködéshez 1 GB RAM kell, meg 3D-s videokártya ...
Ehhez képest az, hogy a kernel pár kB-tal vagy MB-tal nagyobb, az nudli. (Egyébként ettõl nem biztos, hogy a kernel nagyobb volna és bonyolultabb. Sõt, az volna a jó, ha volna egy pici, de robosztus kernel, ami vezérli a drivereket is. És ha egy-egy driver "kisiklik", akkor nem tud a kernelben kárt tenni.)

Szerkesztette: Sparow2 2009. 04. 03. 13:16 -kor

[didyman]

"Az IA-32 CPU-kban lévõ védelem segítségével ez elkerülhetõ volna."
Tudsz olyan megvalósítást, ahol a teljesítmény jelentõs rovása nélkül ez így sikerült?

Akartam írni, de lusta vagyok, eszembe jutott a merevlemezes dolog és inkább nem :Ð

[Gyula2222]

Legkissebb erõforrásigénye nyilván annak a megoldásnak van, amikor a részprogramok önmaguk figyelnek arra, h csak a nekik kiosztott térben maradjanak.
Az meg nyilván csak kompromisszumok árán megy, h gyors is legyen, meg egyszerre sokmindent csináljon. Mindezt persze biztonságosan is tegye.

[Macikák]

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 14:55

Akartam írni, de lusta vagyok, eszembe jutott a merevlemezes dolog és inkább nem :Ð

EMBEREK!!!

Nekem most meló. Gyia!  :Ð

Vár, a user-em. Az egyik... 

De SZERETEK itt lenni...  :Ð

   

[Macikák]

Idézet: Gyula2222 - Dátum: 2009. ápr. 3., péntek - 15:13

Az meg nyilván csak kompromisszumok árán megy, h gyors is legyen, meg egyszerre sokmindent csináljon. Mindezt persze biztonságosan is tegye.

Neked elküldtem a programom... 

Objektum-orientáltan egy program gyártása úgy megy,
hogy ELÕSZÖR megálmodod a grafikát, (gombok, ablakok,
miegymás), feldobigálod ablakokra ("Form"), UTÁNA izzadol
ki hozzá egy kódot, hogy valamit csináljon is az a SZÉPSÉG
ha a user kattintgatja...   

Végül, de nem utolsó sorban, esetemben a VB, még hozzámásol
vagy 2 marék DLL-t, amirõl fingom se hogy mi, de õ állítja, hogy
márpedig kellenek... (mint "Dependencies", azaz Függõségek!) :Ð

Visual Basic esetén az EXÉ-re történõ fordításkor, például igenis,
akadt ilyenféle opció, hogy "Favor Pentium Pro", de ez már nagyon
tavaly elõtti hó, meg nagyon is...

Csatolt fájl:

•  pcode.jpg (0byte)
  Letöltések:: 0

Szerkesztette: Macikák 2009. 04. 03. 14:54 -kor

[Sparow2]

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 13:55

"Az IA-32 CPU-kban lévõ védelem segítségével ez elkerülhetõ volna."
Tudsz olyan megvalósítást, ahol a teljesítmény jelentõs rovása nélkül ez így sikerült?

Akartam írni, de lusta vagyok, eszembe jutott a merevlemezes dolog és inkább nem :Ð

Nincs kihatással a teljesítményre: az adott drivernek csak az a memória van a saját virtuális memóriaterében írási joggal bemappelve, amit írnia is kell.
Ha hibásan írták meg, és mást "akar" átírni, arra nincs joga.

Persze ez így egy egyszerû kijelentés, ami a gyakorlatban bonyolultabb.
Nem szabad a kernel alapvetõ mûködésének olyan memóriától függenie, amit más processzek is átírhatnak.

Vannak ökölszabályok, amik direkt erre szolgálnak:
Pl. egy magasabb szintû kód (pl. a kernel egy belsõ része) és egy alacsonyabb szintû kód (pl. egy driver, vagy egy userspace program):
- felsõbb szintû kódhoz tartozó adatmemóriát nem érheti el az alsóbb szintû kód (nem lehet a kernel memóriáját elérni a kernelen kívülrõl).
- felsõbb szintû kódot meghívhat az alsóbb szintû kód (a kernel rutinjait meg lehet hívni alsóbb szintrõl is).
- az alsóbb szintû kód memóriáját elérheti a felsõbb szintû kód (a kernel belelát a többi processz memóriájába).
- a felsõbb szintû kód nem hívhat meg alsóbb szintû kódot közvetlenül (a kernel nem hívhat meg közvetlenül egy alsóbb szintû rutint, hiszen akkor nem biztos a mûködése: pl. ha az alsóbb szintû kód elrontja a vermet, akkor bedõl a kernel processz, aki hívta). Erre vannak direkt technikák, pl. kapukon keresztüli meghívás, amikor is hiába csinál bármit az alsóbb szintû kód, a kernel processz memóriája nem sérül meg (pl. szintenként külön verem; az alsóbb szintû verem hiába romlott el, a kernel verme jó maradt).

Persze ez mind teljesítménybe kerül, de ezek a dolgok mind hardveresen vannak támogatva, ezért elég gyorsak, minimális a teljesítmény igényük.
Igazából nem itt megy el a teljesítmény: hanem ott, hogy a kódújrafelhasználás, meg böhöm programok, millió objektum egy programom belül.
Maga a kernel (pl. egy Linux-kernel) simán elmegy egy 386-os gépen is, ebbõl is látszik, hogy nem a kernelben lévõ dolgoknak kell a teljesítmény.

A lényeg: gyakorlatilag minimális teljesítmény többlettel meglehet csinálni, hogy egy processz ne tudjon tönkretenni egy másik processzt. A 386-os processzort annakidején direkt így találták ki. Enélkül nem lehetne megbízható oprendszert készíteni.

És még ide tartozik valamennyire: nem csak az lehet fontos, hogy mit írhat egy processz, hanem azt is, hogy mit olvashat.
Bár olvasással nem lehet tönkretenni egy másik processzt, de ahol fontos a biztonság, hogy illetéktelenek ne juthassanak hozzá védett információkhoz, ott pl. gáz lehet, ha indítok egy processzt, kérek X MB memóriát neki, és amit kapok a memóriaterület nincs kinullázva, abban az X MB-ban ki tudja milyen adatok vannak: csak a véletlentõl függ, hogy utoljára milyen processz használta, és mit írt oda. Szerencsétlen esetben érzékeny adatokhoz juthatok hozzá.

Idézet: Gyula2222 - Dátum: 2009. ápr. 3., péntek - 14:13

Legkissebb erõforrásigénye nyilván annak a megoldásnak van, amikor a részprogramok önmaguk figyelnek arra, h csak a nekik kiosztott térben maradjanak.

Igen, de mivel ez nem megoldható (hibátlan szoftver nincs), ezért vannak az erre a célra szolgáló hardveres védelmek.
Amiket megfelelõen kell használni. Lásd. Win9x: hiába ment védett módban, egy rosszul megírt program összedönthette az egész oprendszert.

Másrészt ez így nem is igaz, hogy az önellenõrzésnek kell a kevesebb erõforrás:
Hiszen pl. mondjuk a veremnél ezt hogyan biztosítod? Minden egyes vermet is használó utasítás elõtt megnézi a kód, hogy a veremmutató jó-e, nem telt-e meg a verem, vagy éppen nem üres verembõl akarok kivenni ... Ekkor rögtön egy utasításból (az eredetibõl) csináltunk egy egész ellenõrzést, ami X utasítás.
Hardveres védelemmel nem kell erre figyelni, ha rossz a veremmutató egy veremmûveletnél, akkor jön egy kivétel, és kész. Elég akkor lekezelni, amikor történt a hiba, nem kell minden egyes mûveletnél megnézni, hogy na, most hiba van-e?
Ha pl. megtelt a verem, akkor az adott processz számára láthatatlanul megnövelheti a vermet az oprendszer: a kivételben megnöveli a porcessz vermét, utána a hibás utasítást újraindítja. A vermet használó processz nem "veszi észre", hogy neki az elõbb tele volt a verme.
Ezáltal nem kell minden egyes programba bonyolult ellenõrzéseket beiktatni, hanem az ellenõrzést a CPU végzi, a saját védelme által, és az operációs rendszer kezeli a fellépõ hibákat.

Lehetnek olyan esetek, amikor egy memóriamûveletrõl a kódban nem is tudnád eldönteni, hogy jó-e. Hardveres védelem mindenképpen kell.

Szerkesztette: Sparow2 2009. 04. 03. 18:20 -kor

[didyman]

És úgy véled, hogy a MS/Linus programozó matematikusai mind ilyen képzett hozzá nem értõk, hogy egy ilyen "egyszerû" dolgot képtelenek implementálni? Az egész függõség egy lemezkezelésselmáris borulni látszik, hiszen a kernel explicit függõvé válik egy õt kiszolgáló folyamattól. Ugyanez igaz a memóriavezérlõre, az ACPI-re is, és egy D3D-t éppen használó folyamat belsejébõl kinézve a videovezérlõre is, hiszen rendszermemóriát kap közvetlen használatra. Aztán innen kezdve lehet elmélkedni csak igazán megoldáson, mert az a nyamvadt lemezkezelés, vagy memóriavezérlés egy szálon fog mûködni, mert egy csatornája van, egy pufferrel, egy buszvezérléssel, nem "többszálúsított" olyan formában, mint egy CPU mûködése. Magyarán, az okos CPU-t egy buta alrendszer szolgálja ki, hardveres reset igényével és a CPU felé NMI-vel, ami alrendszert a CPU maga is kvázi illesztõprogramon keresztül fog elérni, hiszen IRQ és DMA van, ami az ACPI hatásköre (sajnos vagy nem, rég nem a BIOS-é), ami meg a kernel alatt csücsül. Páff.

[Sparow2]

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 18:18

És úgy véled, hogy a MS/Linus programozó matematikusai mind ilyen képzett hozzá nem értõk, hogy egy ilyen "egyszerû" dolgot képtelenek implementálni?

Persze a gyakorlat mindig bonyolultabb, mint az elmélet.
Maga az egyszerû elmélet itt leírva, meg a megvalósítás az olyan, mint ahogy elmondod valakinek, hogy hogyan kell motort vezetni, aztán ráülteted, és induljon el.

Lehet olyan rendszer, amiben a driverek összeomlása nem húzza magával a kernelt.
Hiszen a driver is csak olyan processz, mint bármely másik program (csak kicsit több joga van, hogy a hardvert tudja mûködtetni).
Azért mert az MS/Linux nem jobb, még ne gondold, hogy ne lehetne jobb:
Ezelõtt 10 évvel még a sima userspace programok is összedönthették a Windowst. Ma már ez csak kernel szinten fordul elõ.
Akkor miért nem implementálták, hogy a userspace programok ne lehessenek ilyen nagy hatással a kernelre?
Mert nem tévedhetetlenek az MS programozói vagy tervezõi sem (mint minden ember).
(Egyébként asszem egy hibás driver nem dönti le a Linux-ot; már ha nem valami létfontosságú dolog áll meg; pl. egy hangkártya driver nem tesz nagy kárt)

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 18:18

Az egész függõség egy lemezkezelésselmáris borulni látszik, hiszen a kernel explicit függõvé válik egy õt kiszolgáló folyamattól.

Az nem kizárt, hogy egy-egy létfontosságú driver ha leáll, akkor megálljon az oprendszer. (Bár ez is kikerülhetõ, ha a lemezkezelõ driver több példányban fut, és egyik példány leállása esetén ott a másik.)
De pl. egy hangkártya driver ne dönte le az egész rendszert.

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 18:18

Ugyanez igaz a memóriavezérlõre, az ACPI-re is, és egy D3D-t éppen használó folyamat belsejébõl kinézve a videovezérlõre is, hiszen rendszermemóriát kap közvetlen használatra.

Igen, de attól a rendszermemóriától nem függ a kernel mûködése.
A videokártya nem a kernel belsõ memóriáját kapja meg.

(Igazából nem csak a video driver, hanem minden processz kap memóriát közvetlen használatra.)

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 18:18

Aztán innen kezdve lehet elmélkedni csak igazán megoldáson, mert az a nyamvadt lemezkezelés, vagy memóriavezérlés egy szálon fog mûködni, mert egy csatornája van, egy pufferrel, egy buszvezérléssel, nem "többszálúsított" olyan formában, mint egy CPU mûködése.

Igen (bár vannak multipath eszközök is: ha az egyik diszk vezérlõ meghal, akkor a többi még mûködik, csak kisebb a diszk rendszer felé a sávszélesség; persze tipikusan nem házi használatra)

De az mindegy is, hogy a diszk vezérlõ "hány szálú".
Ha nem történik hardver hiba, akkor elég az egyetlen vezérlõ is.
A driver programnak volna hasznos, ha több processzból állna: egyik "kisiklik" és le kell állítani és újra elindítani, addig a többi még mûködik. (Persze a megfelelõ hibakezelésre, miegymásra oda kell benne figyelni)
Esetleg, a létfontosságú driverek és a kernel létfontosságú részei nem kilapozhatóak, mindig a memóriában vannak, ekkor ha a diszk driver hal meg is, simán újraindítható volna, mert nem kell hozzá semmit olvasni.

Idézet: didyman - Dátum: 2009. ápr. 3., péntek - 18:18

Magyarán, az okos CPU-t egy buta alrendszer szolgálja ki, hardveres reset igényével és a CPU felé NMI-vel, ami alrendszert a CPU maga is kvázi illesztõprogramon keresztül fog elérni, hiszen IRQ és DMA van, ami az ACPI hatásköre (sajnos vagy nem, rég nem a BIOS-é), ami meg a kernel alatt csücsül. Páff.

Ezt nem értem, most miért mondod ...
Attól, hogy a periféria buta, még nem következik, hogy ha drivere hibásan van megírva, akkor tönkre kell tennie a kernelt.

Ez két külön dolog, és (megfelelõ tervezés esetén) egymástól független:
1. A driverek ne tehessék tönkre a kernelt.
2. A driver hogyan kezeli a perifériát.

Szerkesztette: Sparow2 2009. 04. 03. 18:50 -kor