[hydrixOS] : Re: HydrixOS Treibermodell - Kritik gesucht :-)

  • From: Friedrich Gräter <webmaster@xxxxxxxxxxx>
  • To: hydrixos@xxxxxxxxxxxxx
  • Date: Sat, 31 Aug 2002 00:34:26 +0200

Folgendes, kannst du in deinem Mail-Programm Qouted-printable versuchen 
auszuschalten, dann gibts weniger Probleme - so muss ich Sonderzeichen 
und Zeilenumbrüche von Hand wiederherstellen und das Quoting schaut 
danach aus wie ein explodierter Mixer :-).

Tarik Yildirim schrieb:
> 
> "welche statt das urspr=FCngliche System aufzurufen"
> 
> Das Problem ist hierbei, dass Du die Routinen von verschiedenen 
 > Betriebssystemen auf HydrixOS patchen must. Solche patches sind
 > aufwendig zu realisieren, da es kommerzielle Systeme gibt, die
 > nicht so weiteres zu patchen sind.
>

Für Windows z.B. kann ich den größten Teil (alles?) dadurch ersetzen, 
dass ich wichtige DLL-Dateien neu schreibe (kernel32.dll, user32.dll 
etc.). Sicher ist es aufwendig, aber es ist von der Leistung her und von 
der Tatsache, dass dies die einzige legale Methode ist (im anderen Fall 
müsste man ja das ganze Original-Betriebssystem aufsetzen lassen), m.E. 
sinnvoller.

Wenn es andere Methoden gibt an die API des Systems, als wie unter 
Windows einfach "nur" DLL-Dateien zu ersetzen, zu gelangen, z.B. 
Softwareinterrupts (MS-DOS) oder Unterprogrammaufrufe (C-64) muss man 
eben diese umlenken bzw. mit eigenen Routinen abdecken.

> Wenn man die Hardware-Schnittstelle direkt emuliert ist es klar, dass es 
 > langsamer ist, als wenn man direkt darauf greift. So ist es ja auch 
bei der
 > CPU-Emulation.

Man greift ja nicht direkt auf die Hardware zu, sondern auf den 
jeweiligen Treiber, der die Hardware im Dateisystem als Datei 
abstrahiert oder als normaler Server über eine Schnittstelle 
abstrahiert. Wobei ich das Modell "Abstraktion der Hardware als Datei"
eher schätze, da man so einen einheitlichen Zugriffsmechanismus über 
Dateifunktionen (open, read, write usw.) hat.

> 
> Ein System zu erstellen, dass auf jeder Plattform binärkompatibel ist UND
> noch so schnell, dass es nur für dieses System erstellt worden ist, ist 
 > nicht so weiteres möglich.
> 

Klar. Eine 100%ige Kompatibilität bekommt man auch leider nicht hin, 
wenn das System nicht lahmen soll wie ein Dreirad. Aber wie gesagt, die 
meisten Systeme bieten Abstraktionen wie Dateien und 
Verzeichnisstrukturen schon von Grund auf an und können somit diese im 
Rahmen anderer Systeme auch Nutzen (siehe Wine unter Linux).

> Da ist eh ein Kompromiss nötig. Bisher habe ich HydrixOS so gesehen, dass
> wir kompatibel und auf JEDEN Rechner lauffähig ist. Insbesondere Software,
> für die es keine Systeme mehr gibt.

Das würde es auch werden - da alle nötigen Dinge durch die Abstraktion 
von Seiten der Treiber verborgen wird. Es greift ja kein Programm direkt 
auf die Hardware zu, sondern auf den Treiber, der die Hardware abstrakt 
anbietet.

> Ausserdem bin ich der Meinung, dass Sicherheit vor Geschwindigkeit geht.
> Wenn wir die Festplatte emulieren, dann ist es egal, ob das System wirklich=
>  von Festplatte läuft.

Wir müssen nur nicht die ganze Festplatte emulieren, es kümmert sich ein 
Treiber darum, der die Festplatte steuert. Auf diesen Treiber setzt ein 
Dateisystemtreiber auf, der wiederum den Zugriff auf die Platte abstrakt 
über eine Schnittstelle anbietet. D.H. wie die Festplatte/Dateisystem im 
Detail arbeitet, ist für das Programm egal - nur der Treiber muss sich 
darum kümmern.
Würden wir hingegen das Gerät der Festplatte emulieren, wäre das nur 
eine Zwischenschicht, die so nicht nötig ist, denn der Treiber bietet ja 
bereits eine abstrakte Schnittstelle zur Festplatte an.

> Es könnte ja auch vom RAM aus laufen, ohne das das System etwas davon mit=
> bekommmt.
> Es denkt, er hat eine Festplatte.

Das Treiber-Prinzip würde folgendes ja erzielen:

Der Festplatten-Treiber bietet ein Interface für einen Datenträger an. 
Der Dateisystemtreiber baut auf diesem Interface auf und bietet selbst 
wieder eines für Dateizugriff auf. Ob nun der Festplattentreiber auf 
eine Festplatte von XY zugreift, oder auf einen RAM-Baustein ist dem 
Dateisystemtreiber wiederum egal.

(Kann es sein, dass wir das gleiche meinen, nur unterschiedliche 
Begriffe benutzen?)

> Wie der Aufbau genau aussieht, ist unerheblich. 

Im Prinzip ja: Allerdings wollte ich das nur jetzt schon festlegen, 
damit nicht später ein Benennungschaos losläuft. Im Moment entsteht wie 
gesagt, das ominöse HydrixOS-Handbuch und in dem steht bereits etwas 
über das Dateisystem, damit wir wissen nach was sich die API-Entwicklung 
ausrichten muss.

[Assign]

Gute Idee. Umsetzbar durch Umgebungsvariablen - ich würde das allerdings
vor den Vermittlungsdienst hängen, da es sonst normale 
Dateisystemzugriffe abbremsen würde.

> 
> Bei Linux habe ich acuh einen grossen Nachteil festgestellt. Wenn man 2 
> Partitionen hat, 
 > dann verteilt Linux zwischen den beiden wie es ihm beliebt.
 > Ich wollte eigentlich System und Daten trennen, jedoch hat sich das
 > System überall eingenistet. Und ich konnte nicht mehr nachvollziehen 
welches
 > Verzeichnis auf welcher Partition hängt.
 >

Kommt auf die Konfiguration an. Wie auch immer unter HydrixOS hat 
(derzeit) jeder Dateiserver, der sich an das Dateisystem einhängt, einen 
Verzeichnispunkt, der ihm alleine gehört - d.h. "/home" kann nur zu 
einem Dateisystemdienst gehören. (Untergeordnet natürlich nicht 
"/home/hans" kann zu einerm Dienst, "/home/franz" zu einem anderen gehören)

> Nun, ich will nicht sagen das mein (muss ich zu geben das ich an dem System=
>  h=E4nge:) ) Amiga das Nonplusultra
> ist. Ich m=F6chte nur das alle guten Eigenschaften aller System in HydrixOS=
>  einfliesst. Damit wir nix mehr zu
> n=F6rgeln haben. Und dann wieder ein neues System erschaffen m=FCssen :(
> 

Schon klar. Dafür ist ja die Mailingliste da :-).

> 
> Ist mal wieder lang geworden. Ist aber ein sehr interessantes Thema.
> 

Kein Problem.

cu

FG

-- 
HydrixOS Developers Mailing List

Administration: webmaster@xxxxxxxxxxx 
Archive: http://www.freelists.org/archives/hydrixos

Other related posts: