From 3965f9292da17ad9de0fe43a85996c1c56a7af3b Mon Sep 17 00:00:00 2001 From: Jan Klemkow Date: Tue, 8 Jan 2013 10:55:58 +0100 Subject: Fix style and spell errors. --- document.asciidoc | 25 ++++++++++++------------- 1 file 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. -- cgit