summaryrefslogtreecommitdiff
path: root/document.asciidoc
diff options
context:
space:
mode:
Diffstat (limited to 'document.asciidoc')
-rw-r--r--document.asciidoc25
1 files changed, 12 insertions, 13 deletions
diff --git a/document.asciidoc b/document.asciidoc
index 12a160d..e8580f0 100644
--- a/document.asciidoc
+++ b/document.asciidoc
@@ -81,7 +81,7 @@ Als Parameter bekommt die Funktion die Startadressen von Quelle und Ziel im
Speicher.
Der Funktion ist dabei die Groesse der jeweiligen Speicherplaetze nicht bekannt.
Es wird nun eine Speicherzelle nach der Anderen kopiert, solange bis in der
-Quelle ein NUL-Byte auftaucht.
+Quelle ein Null-Byte auftaucht.
Dabei kann die Funktion weder sicherstellen, dass sie nicht ueber den
Quellpuffer hinaus Bytes kopiert, sowie dass sie nicht ueber die Grenzen des
Zielpuffers hinaus schreibt.
@@ -173,16 +173,16 @@ und übergibt beim Start den Deskriptor für den Kommunikationskanal.
Wenn nun zur Laufzeit weston ein Eingabe-Hotplug-Ereignis erhält
und das Gerät öffnen möchte, so nutzt weston nicht -- wie andere Programme --
-open(2), denn um das Gerät direkt zu Öffnen fehlen die Rechte.
++open(2)+, denn um das Gerät direkt zu Öffnen fehlen die Rechte.
Stattdessen wird eine Nachricht über den Kommunikationskanal gesendet,
die mit einem OpCode beschreibt, dass ein Gerät geöffnet werden soll,
-und als Parameter den Pfad zum Gerät, z.b. /dev/input/event0 enthält.
+und als Parameter den Pfad zum Gerät, z.b. +/dev/input/event0+ enthält.
Weston-launch empfängt diese Anfrage und prüft, ob es ein zur Öffnung erlaubter
-Pfad ist (z.B. beginnend mit /dev/input/).
+Pfad ist (z.B. beginnend mit +/dev/input/+).
Falls erlaubt, wird das Gerät geöffnet und der Deskriptor über den
Kommunikationskanal als Socket-Control-Message an ``weston'' als Antwort
übertragen. Weston erhält damit einen Deskriptor, der sich nicht
-von einem durch direkten Aufruf von open(2) geöffneten unterscheidet.
+von einem durch direkten Aufruf von +open(2)+ geöffneten unterscheidet.
// TODO: Ähnliches Szenario: DRM Set Master
Weston läuft somit im User-Mode und kann bestimmte Operationen,
@@ -227,7 +227,7 @@ explizit gefiltert, um die Beeinflussung von anderen Prozessen zu verhindern.
Um verschiedene Prozesse voneinander zu trennen, kann auch die
UNIX-Rechte-Verwaltung verwendet werden.
-Jeder Service sollte unter einem separaten Nutzer-Konto laufen.
+Jeder Service sollte unter einem separaten Nutzerkonto laufen.
Es sollte vermieden werden, mehrere Dienste mit den gleichen Nutzungsrechten
auszuführen, da sich diese untereinander beeinflussen koennen.
Sollte ein Dienst keine eigenen Dateien benoetigen, kann dieser unter dem
@@ -250,10 +250,9 @@ kommuniziert und wo sich die Kommumikationspartner befinden.
Kommunikation innerhalb eines Hosts sollte ueber das Loopback-Interface
oder UNIX-Domain-Sockets gefuehrt werden.
Ein Dienst, welcher ueber das Loopback-Interface kommuniziert, kann von jedem
-Prozess erreicht werden, der einen Netzwerk-Socket oeffnen kann.
-//FIXME: Gibt es Programme, die keinen Socket öffnen können?
+Prozess erreicht werden.
UNIX-Domain-Sockets sind an Dateien gebundene Verbindungen,
-mit den gewöhnlichen Berechtigungs-Parametern, durch die sich ueber die
+mit den gewöhnlichen Berechtigungsparametern, durch die sich ueber die
systeminterne Benutzer- und Rechteverwaltung der Zugriff auf die Verbindung
steuern lässt.
//FIXME: geeignet?
@@ -266,7 +265,7 @@ fuer die verschiedensten Zwecke genutzt werden koennen.
In jedem Fall sollte die Erreichbarkeit von Diensten soweit wie moeglich
eingeschraenkt werden.
-Auch Tunnel-Techniken wie IPSec und andere VPN-Loesungen koennen verwendet
+Auch Tunneltechniken wie IPSec und andere VPN-Loesungen koennen verwendet
werden, um einen Dienst ausschliesslich ausgewaehlten Nutzern zugaenglich
zu machen.
@@ -288,7 +287,7 @@ das Gesamtsystem betrachtet.
=== Kernel-Architektur
-Die meisten Betriebssysteme verwenden ein monolitisches Kernel-Design.
+Die meisten Betriebssysteme verwenden ein monolithisches Kernel-Design.
In diesem werden viele Aufgaben des Betriebssystems im Kernel erledigt.
Das bedeutet, dass der Programm-Code mit sehr hohen Berechtigungen
ausgefuehrt wird.
@@ -320,14 +319,14 @@ So werden z. B. Speicherbereichsverletzungen vom Prozessor erkannt.
Ein fehlerhaft programmierter Treiber kann so nicht mehr das gesamte System
gefaehrden.
Dieses Kernel-Architektur hat grosse Performence-Nachteile gegenueber eines
-Monolitischen-Designs.
+monolithischen Designs.
Denn will einen Anwendung Beispielsweise mit der ueber das Netzwerk ein Paket
versenden, so muss fuer dieses Paket zwei mal der Userspace-Kernelspace-Kontext
gewechselt werden.
Dieses kostet enorm viel Zeit, da der gesamte Prozessorkontext fuer den
Uebergang von Anwendung zum Kernel, sowie vom Kernel zum Netzwerkkartentreiber
gesichert werden muss.
-In einem monolitischen Design gaebe es nur einen Kontextwechsel von zum Kernel,
+In einem monolithischen Design gaebe es nur einen Kontextwechsel von zum Kernel,
welche das Netzwerkmodule enthaelt.
Somit muss man an dieser Stelle Performence und Sicherheit abwiegen und fuer
den konkreten Einzelfall entscheide welches wichtiger ist.