Idézet: didyman - Dátum: 2009. ápr. 6., hétfő - 14:50
De egy veszettül félreértetted. Debaj leírta neked most másodszor is, de csak nem sikerül megértetni, hogy az NT5 ilyen és ez van, nem fogja nekünk Bill csapata újraírni.
Nem is gondoltam, hogy újraírnák.
Akkor elbeszéltünk egymás mellett. Úgy értettem, hogy általánosságban mondja.
Idézet: didyman - Dátum: 2009. ápr. 6., hétfő - 14:50
Mit akarsz akkor másképpen? Tessék, Előtted az ajtó, állj neki az NT5-nek és csináld meg, amilyenre szeretnéd, én örömmel segítek, ha mást nem is tudok benne, tesztelni, máris vagyunk ketten
. Mindent lehet másként, a lottó ötöst is meg lehet nyerni, ki a fene kérdőjelezte ezt meg?
Nem is gondoltam, hogy újraírnák.
Windows kernelnek nem állnék neki, mert nem látom értelmét.
De pár éve összedobtam egy egyszerű 32 bites kernelt, priorításos preemptív ütemezővel, memóriakezelővel, néhány periféria kezdetleges kezelőjével (IRQ vezérlő, PIT (időzítő áramkör), bill., text módú videó, meg talán még 1-2 dolog amik tényleg kellettek az alap működéshez) meg egy nagyon az elején abbahagyott lemezkezelővel és IDE driverrel, szakdolgozat gyanánt. Persze egy igazi OS-hez képest csak játék volt, nem volt hozzá sem shell, sem programok, de el lehetett indítani benne többszálú processzeket.
Mostanában gondolkodtam, hogy el kéne kezdeni a 2-es változatot, nyilvánosság előtt, pl. egy fórum lenne az oldalon, és le lehetne tölteni ami éppen készen van, és hozzá lehetne szólni, stb ...
Idézet: didyman - Dátum: 2009. ápr. 6., hétfő - 14:50
Elvileg userspace meg védett mód, gyakorlatilag lefagy az X86-on a kutya töke is, ha arról van szó. És ez nem a rajta futó szoftverek explicit gyengesége, hanem már vasból fakad, egy hibás memóriaterület is elég hozzá, miről beszéljünk akkor, arról, hogy de ez is marhaság, mert van ECC? És hány deszka képes ECC-zni, mennyi ECC-s RAM-ot látsz a boltokban? Erről beszéljünk, ne az elméletéről, azt bizonyosan mindannyian jól tudjuk, vizsgáztunk belőle meg esetleg használtuk is már.
Persze, hibás hardveren nem fog jól működni. (Léteznek módszerek a meghibásodott hardveren is jól működő rendszerekre --persze nem tisztán szoftveres megoldások--, de az tényleg más téma, és egyáltalán nem házi használatra)
De most nem arról volt szó, hogy hibás hardveren ne működne, hanem tökéletes hardveren sem, egy driverhiba miatt.
Idézet: debaj - Dátum: 2009. ápr. 6., hétfő - 15:32
Ja, csak amíg a driverek ugyanazon a jogosultsági szinten futnak, mint a kernel, addig sokmindent nem lehet csinálni.
Miért ne lehetne??? Minden egyes processznek megvan a saját virtuális memóriaterülete, és ha ez jól van beállítva, akkor nem lát bele más processzek területébe.
Ugyanúgy, mint ahogy a userspace programok sem piszkálják el egymást, pedig egy szinten futnak.
A biztonsági szint az csak egyetlen a védelmek közül, és nem azért van, hogy a processzek ne tudják egymás memóriaterületét elpiszkálni, hanem azért, hogy kernel szintről ne lehessen véletlenül (vagy direkt se) userspace szintű processzt _közvetlenül_ meghívni vagy userspace szintű program ne tudjon kernel szintű szelektorra hivatkozni (kódszegmensnél call, far jmp vagy iret esetén számít, adatszegmensnél meg a szegmensregiszterbe töltéskor).
A szint más ellen véd, mondhatni "az ellen nem véd": hiszen egy 3. szinten futó processz is átírhatná a kernel memóriaterületét, ha be volna neki állítva a saját memóriaterületére írható jogosultsággal a kernel területe.
Idézet: debaj - Dátum: 2009. ápr. 6., hétfő - 15:32
XP alatt is vannak driverek, amik a userspace-en futnak, de nem lehet mindent odapakolni. Egy videókártya drivere meg is nyakkanna, ha a Ring3-ban kellene futnia, vagy mondjuk a kernelre kellene várnia, amíg elszüttyögi a dolgát, aztán átadja neki a rendszerbuszt.
Őőő ... ez így ebben a formában nem igaz. Hozzáteszem, bizonyára nem a 3. szinten fut a video driver, de
elvileg (ez függ az oprendszertől is) megírható volna ott is.
A 0. szinttől csak annyiban kisebb az alatta lévő szintek jogosultsága, hogy bizonyos utasítások végrehajtásakor kivételek keletkeznek. Ezek az ún. privilegizált utasítások. De ezek az utasítások a CPU állapotát állítják be, elvileg a drivernek ezekre nincs szüksége. (Pl. megszakítás letiltása, engedélyezése, descriptor táblázatok beállítása, laptáblázat beállítása, stb ... ezek tipikusan a kernel által elvégzendő feladatok: a kernel kapcsolgathatja amegszakításokat, a kernel osztja ki a memóriát, a kernel osztja ki a szelektorokat, más ezekhez nem piszkálhat jó esetben)
És az sem a szinttől függ, hogy melyik processznek kell várnia melyik processzre, ez csak az ütemezőtől függ.
Attól, hogy egy processz a userspace-ben fut, még adhat neki az ütemező nagyobb priorítást (pl. be lehet állítani real-time priorítást egy saját magad által elindított programnak is, ami pedig biztosan nem kernel módban fut).
Idézet: debaj - Dátum: 2009. ápr. 6., hétfő - 15:32
Ilyen hozzáállással vagy az egész Ring0 sandboxban fut, vagy ott a veszélye a kékhalálnak.
Nem kell sandbox, elég ha a processzek virtuális memóriája jól van beállítva.
Mint ahogy a 3. szinten futó processzek sem keverednek össze egymással. Másrészt nem is a szinttől függ, hogy belátnak-e vagy beírhatnak-e egymás memóriaterületére.
Fentebb leírtam bővebben.
Idézet: debaj - Dátum: 2009. ápr. 6., hétfő - 15:32
Az egész kernelt meg nem lehet átírni hülyebiztosra, mert akkor a vízzel együtt a gyereket is kiöntjük, és el lehet felejteni az összes eddig megírt windowsos alkalmazást és a visszafelé kompatibilitást (vagy futhatnak azok virtuális layeren, csak akkor megint ugyanott vagyunk, mint ahonnan elindultunk).
Most kezdek megzavarodni, fentebb általánosságban volt, hogy ha a driver a kernel szintjén fut, akkor nem lehet mit csinálni, kérem ez van ...
Egyébként a kernelnek az volna a lényege, hogy hülyebiztos legyen. Különben visszatérhetnénk a Win95-re.
Attól, hogy a kernelt átírják nem fontos, hogy a régi alkalmazásokkal való kompatibilitás elvesszen. Elég, ha megtartják a Win API-t, ami eddig volt (és eddig is rengeteget változott, ahogy fejlődött az oprendszer)
Hiszen pl. wine-ban is egész más kernel van alatta, és "mégis mozog" ... ott csak az API-t írták meg hozzá, többé-kevésbé. Vagy pl. Linux-hoz is készítenek másik kernelt (tisztán GNU projektben van az egész rendszer, nem GNU/Linux), mégis kompatibilis a meglévő programokkal.
Persze a Windows kernelét nem fogják átírni valószínűleg mostanában. (De még lehet hozzá egy jobb kernel mondjuk egy Windows 9-ben, végülis bármi előfordulhat.)
Szerkesztette: Sparow2 2009. 04. 06. 21:17 -kor
Súgó
A téma zárva.
