[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: //www.freelists.org/archives/hydrixos
Other related posts:
