Vista + Grafik im Kernel

[zbenjamin]

Hallo allerseits,

ich habe letztens gelesen das im neuen Windows Vista, die grafischen subsysteme aus dem kernel in den user-space verlagert werden.
Ist das für reactos auch geplant?

http://www.winfuture.de/news,23408.html

MFG Benjamin

[frik85]

Hallo allerseits,

ich habe letztens gelesen das im neuen Windows Vista, die grafischen subsysteme aus dem kernel in den user-space verlagert werden.
Ist das für reactos auch geplant?

http://www.winfuture.de/news,23408.html

MFG Benjamin

Ich habe mit anderen ros devs darüber gesprochen. Da derzeit noch niemand genau weiß wie MS das in Vista (Final) lösen wird, ... müssen wir derweilen noch abwarten. Es ist allerdings geplant es auf die selbe bzw. auf eine ähnliche Weise zu implementieren (damit Win2k/XP und WinVista treiber funktionieren).

WinNT 3.1 und WinNT 3.5.x hatten bereits damals so eine ähnliche implementation (grafik im user space).

[zbenjamin]

Danke für die schnelle Antwort,

ich finde das ist auf jeden Fall eine sauberere Lösung als die momentane unter den aktuellen NT Versionen.

Gruß Benjamin

[Dr. Fred]

Ja, sauberer und langsamer. Bei Vista sollen sowieso alle Treiber im Usermode sein oder nicht ?

[zbenjamin]

Jupp, es sollen alle Treiber im User Space laufen.
Microsoft führt an das die meissten Abstürze auf defekte Treiber zurückgeführt werden könnnen.
Wenn also ein Treiber abschmiert dann kann wenigstens das System weiterlaufen.

Lieber ein bissl schlechtere Performance (die man mit diversen Speichern / Prozessor ausgleichen kann) als ein System das einfriert wenn ein Treiber mist baut.

Nachzulesen unter: http://www.winfuture.de/news,23408.html

Greets Benjamin

[frik85]

Jupp, es sollen alle Treiber im User Space laufen.
Microsoft führt an das die meissten Abstürze auf defekte Treiber zurückgeführt werden könnnen.
Wenn also ein Treiber abschmiert dann kann wenigstens das System weiterlaufen.

Lieber ein bissl schlechtere Performance (die man mit diversen Speichern / Prozessor ausgleichen kann) als ein System das einfriert wenn ein Treiber mist baut.

Nachzulesen unter: http://www.winfuture.de/news,23408.html

Greets Benjamin

Saubere in der implementation ist die WinNT 3.x Variante schon. Über WinVista kann man noch nichts genaues sagen. Allerdings spricht auch einiges für den Kernel mode (siehe "Windows Internals 3./4. Edition").
Die grafik im user space ist auf jedenfall langsamer (siehe WinNT 3.x und *nix/*bsd X-window sys), darum wird WinVista unter älteren Rechner wahrscheinlich nicht mehr so "rund" laufen. Aktuelle Linux distros benötigen schon mind. 1,2 GHz um überhaupt in x-window mit KDE/Gnome zu booten/laden.
Da MS aber angeblich auch noch WinXP Treiber unterstützen möchte sind wir schon gespannt wie MS das implementiert. Einfach (und "sauber") wird es wohl nicht werden (können).

[zbenjamin]

Da MS aber angeblich auch noch WinXP Treiber unterstützen möchte sind wir schon gespannt wie MS das implementiert. Einfach (und "sauber") wird es wohl nicht werden (können).

Stimmt, diese Kompatibilität wird wohl das was sie mit der auslagerung erreichen wollten ein bisschen aushebeln.
Denn WinXP Treiber können imho nur im Kernel Space laufen, also muss das ja wohl noch funktionieren.

Und einen Kernel Space im UserSpace "simulieren" is wohl auch nicht das richtige *lol*.

[Dominik2]

Hallo,
ich bin ja bestimmt kein OS-Guru, aber wie kann ein Treiber im UserMode laufen?
Das ist doch eigentlich überhaupt nicht möglich, weil er ja sonst nicht direkt auf die Hardware zugreifen kann (IO-Schutz, Memory-Schutz), was er ja muss.
Oder irre ich mich da???
Und ist es wirklich so, dass bei Linux der Treiber nicht im KernelMode läuft? Kann es nicht sein, dass eben nur der X-Server (der wiederum den Treiber benutzt) im UserMode arbeitet?
Vielleicht könnte mir dies jemand erklären...

MfG
Dominik

[RandomMe]

Hallo,
ich bin ja bestimmt kein OS-Guru, aber wie kann ein Treiber im UserMode laufen?
Das ist doch eigentlich überhaupt nicht möglich, weil er ja sonst nicht direkt auf die Hardware zugreifen kann (IO-Schutz, Memory-Schutz), was er ja muss.

Ich glaube, man kann auch Programmen im User Mode Rechte in Form von IO Zugriffen zuweisen. Memory geht ja auf jeden Fall. I/O sollte auch gehen.

[zbenjamin]

ich weiss auch nicht genau wies funzt. Aber der Treiber muss eben seine Anfragen wie jeder andere Prozess ueber den Kernel laufen lassen.
Das ganze ist zwar dann sicherer aber auch etwas langsamer.

Ob bei Linux wirklich alle Treiber im UserSpace laufen weiss ich leider auch nicht.

Greets Benjamin

[Dr. Fred]

Man muss alle IO-Zugriffe als System Calls abstrahieren, direkt geht es AFAIK nicht.

Und ist es wirklich so, dass bei Linux der Treiber nicht im Kernel Mode läuft?

In Linux gibt es keine Treiber, nur Kernel-Module. Und die laufen alle im Kernel Mode soweit ich weiß.

[RandomMe]

Man muss alle IO-Zugriffe als System Calls abstrahieren, direkt geht es AFAIK nicht.

Ich denke schon. Siehe z.B. http://www.beyondlogic.org/porttalk/porttalk.htm

[Dominik2]

Hallo!

Man muss alle IO-Zugriffe als System Calls abstrahieren, direkt geht es AFAIK nicht.

Ja, das wäre eine Möglichkeit, aber wohl nicht wirklich ratsam!? Man hat ja genau deswegen die Trennung zwischen User und Kernel Mode gemacht, um es eben nicht zu erlauben, dass User-Programm privilegierte (CPU-)Operationen ausführen können. OK, bei einem System Call habe ich noch die Möglichkeit evtl. falsche Parameter bzw. Rechte zu prüfen, aber ob damit die Situation besser wird? Es muss ja alles genauso möglich sein wie es vorher auch ging (Der Kernel kann ja nicht immer prüfen, ob es jetzt sinnvoll/richtig ist genau diese Operation auszuführen). Man würde somit eigentlich nur die benötigte API an eine andere Stelle verschieben (die vom User Mode aus zugänglich ist). Der einzige große Vorteil, den ich - im Moment - sehe ist, dass es einem Treiber nicht mehr möglich ist Speicher des Kernels bzw. anderer Prozess/Treiber zu überschreiben (gewollt oder ungewollt! Vorausgesetzt man denkt daran es nicht zu erlauben die MMU-Register entsprechend zu setzten ). Mit dem Preis privilegierte Operationen von jedem Anwendungs-Programm (inkl. Viren/Würmer) aus aufrufen zu können (Rechte sind bei Windows ja kein wirkliches Argument, es ist ja eh jeder Admin.).
Ich hoffe mal, dass die Leute bei Mircosoft genau wissen was sie da machen. Sie werden wohl keine Ideen von DOS übernommen haben (da war es nämlich so, es konnte jedes Programm quasi alles machen).

Ich denke schon. Siehe z.B. http://www.beyondlogic.org/porttalk/porttalk.htm

Das ist genau das, was man eigentlich nicht machen sollte! Einen Treiber (also Kernel Mode) schreiben der die Schutzfunktion gezielt umgeht/ausschaltet. Ich weiss, solche Treiber haben durchaus ihren Sinn (z.B.: Um alte Programm die direkten IO benötigen auch unter NT ausführen zu können). Es öffnet aber genau die oben beschriebene Sicherheitslücke, jedes User-Programm kann direkt (und unkontrolliert) auf die Hardware zugreifen!


Aber wie gesagt ich bin kein Profi! Vielleicht geht es ja doch ohne die Sicherheit des Systems stark zu gefährden!?
(Oder vielleicht stimmt *meine* Behauptung ja nicht!?)

In Linux gibt es keine Treiber, nur Kernel-Module. Und die laufen alle im Kernel Mode soweit ich weiß.

Ja, Kernel-Module die die Aufgaben eines Treibers übernehmen (also quasi Treiber sind)(?). Die aber im Kernel Mode laufen (darum gings mir eigentlich).

MfG
Dominik

[TiKu]

(Rechte sind bei Windows ja kein wirkliches Argument, es ist ja eh jeder Admin.)

Bei Vista nach meinem Kenntnisstand nicht mehr.

[zbenjamin]

Hier sind ein paar Angaben zu dem neuen Grafiksystem (is sogar an Entwickler gerichtet):

http://msdn.microsoft.com/library/defau ... aphics.asp