[elektro] oprendszerelmelet

[gyapo]

>Mikozben siman le is fagyhat. Ezek a legkomplexebb osszetevok.

Lehet, hogy a legkomplexebb, de ettol nem kell lefagyni, vagyis 
pontosan le lehet irni byte-ra es mikrosecre, hogy mikor mi tortenik, 
nem allhat elo ismeretlen allapot, ha a hardware nem hibas. Ha a 
komplexitast parositanank a megbizhatatlan mukodessel, akkor nem 
jutottunk volna ki a vilagurbe stb.

>Egyebkent egy driver csak ugy tud valamit tenni, ha ker egy I/O
>cimtartomanyt a kerneltol, amin warezolhat, a kernel meg ad neki.
>Nem tudom pontosan hogy mukodik az XP, de ha olyat kerek amivel bajt
>lehet okozni, akkor le lehet fagyasztani a rendszert.

Mondjuk en se ismerem az xp-t, de szerintem egy alkalmazas nem 
nyulkal a hardware-hez, hanem megkeri a kernelt, hogy az tegye.

>Tipikus pelda a direkt LPT port kezeles. Egy helper driverrel lehet
>direkt hozzaferest kerni az I/O porthoz. Ezen az elven barmihez lehetne
>kerni...

OK, ez tiszta, ha beengedek valamit kernel szintre, akkor az tud 
fagyasztani is. Atlag program nincs beengedve, megis tud fagyasztani, 
ezert inditottam a threadet.

>Hat... Nem sok. Maximum a Neumann architektura.
>
>A C64 mai szemleletben tulajdonkeppen csak egy "mikrokontroller", amin
>elvileg sem lehet ilyesmit megoldani, nem tudod visszakapni a vezerlest
>ha egyszer elugrottal valahova, es nem tudod akadalyozni ki mit tehet.

Arra gondoltam hasonlosag alatt, hogy ha megnyomom a (z utolag 
beepitett) reset gombot a c64-en, akkor hetszentseg, hogy egy adott 
cimre ugrik a processzor. Ez pont eleg ahhoz, hogy egy alkalmas 
odahelyezett programreszlet mindig megkapja a vezerlest, ha a gomb 
helyett egy tranyot teszek oda, ami x idonkent testre huzza. Ezzel 
meg el lehet erni, hogy az egyebkent berogyott foprogramot ki tudjam loni.
Az xp-ben elvileg kellene egy kernel, ami idonkent egy nem 
maszkolhato megszakitassal megkapja a vezerlest, barmit is csinalnak 
az alkalmazasok, es igy ki tudja loni a befagyottat. Ennyi a hasonlosag.

>Es ha "olyan" helyre irt?
>Nem nagyon van RAM checksum, hogy derul ki hogy az adat amivel epp
>dolgozunk hibas?
>A kernel beolvas a RAM-bol egy hibas (jonak velt) adatot, majd elkezd
>valamit csinalni vele. Barmi tortenhet.

Ugy tudom, hogy nem tud rossz helyre irni, mert a processzor ezt 
megakadalyozza, general egy gpf-et, amit le lehet kezelni. De rossz 
helyre iras a ramba nem tortenik, a kernel kodja nem serul, a 
megszakitas hardware-bol jon, innentol csak a kernel irojan mulik, 
hogy mennyit ellenoriz es mit csinal.

>Egy idoben bugos volt valami USB eszkozom, amire az alaplap elvette a
>tapot az USB-rol, HUB-bal, mindennel egyutt. XP alatt csak ujrainditani
>lehetett, linux alatt kilottem az usb_uhci modult, visszatoltottem, azt
>csa'. Ha mondjuk a swap vagy esetleg a rootfs USB diszken lett volna,
>valszeg barmelyik rendszer itt elhalt volna.

Na ezt emlegettem a jo oreg netware-rel kapcsolatban. Nem ertem a 
Billieket, mi a turoert nem hasznaljak a modszert.

>Szoval alapvetoen hibaturo az ami most van, nagyon sokmindent lekezel
>szo nelkul, a w9x-hez kepest igen ritkan fagy le az XP is, nyilvan
>amikor ez bekovetkezik, az az a hiba, amire nem gondoltak a fejlesztok.

Persze, a dos 3.1-gyel kezdtem en is, win 3.0, 3.1, 98, nt, xp, es 
valoban javult a stabilitas, de meg mindig le tud fagyni egy egyszeru 
programocskatol. Legutobb valami tuzfalat telepitettem fol, es boot 
kozben egy ponton kekablak. Es nem tudta lekezelni a problemat, nem 
kaptam meg promptot se, addig nem jutott el a boot folyamat. Nem 
hiszem, hogy a tuzfal program atirta volna a kernelt hibasra.

Udv.: gyapo

gyapokuk at cfwpont.hu