[linux-l] Plan9-Konzepte (was: VCS)

[Steffen Dettmer]

* Volker Grabsch wrote on Thu, May 04, 2006 at 13:44 +0200:
> On Wed, Apr 26, 2006 at 08:48:31PM +0200, Steffen Dettmer wrote:
> > * Volker Grabsch wrote on Wed, Apr 26, 2006 at 14:37 +0200:
 [...] 
> > > Mein Vorschlag:
> > >     * Memcopy der Datenstruktur
> > 
> > Ein memcpy von einem Windows-PC zu einer Sparc-Linux-Workstation? Das
> > funktioniert ja nichtmal zwischen zwei Applikationen wg. virtuellen
> > Addressraums.
> 
> Neinnein, so war das auch nicht gemeint.
> 
> Ich meinte, dass die Prozesse sich gegenseitig Datenstrukturen
> austauschen, über irgendeine einheitliche API. 

Ja klar, read(2) und write(2). Implementieren etliche Unixe lokal sehr
effizient, remote dann via TCP oder so, macht XLIB doch schon?

> Liegen beide Prozesse in der selben Maschine, gibt's nen Memcopy.
> Anderenfalls wird Serialisiert.

Serialisieren musst Du in jedem Fall. Bei Intel und genau C geht es
manchmal, eine Struktur um ein Vielfaches von vier byte zu verschieben,
aber nicht z.B. um eines. Sobald ein Pointer drin ist bzw. drauf zeigt,
geht eh nix mehr. Da man eigentlich immer einen Pointer drin oder drauf
hat, geht das in der Praxis so gut wie nie. Und wenn, kann man ja shared
memory nehmen, da gibt's ne POSIX-API zu, oder memory mapped files, aber
das geht nur lokal und man will es nicht :)

> Aber ohne dass die Applikationen das wissen müssen. Welcher der beiden
> Wege begangen wird, entscheidet dann das System.

Die Applikation muss wissen, wie sie die andere erreicht; sei es ein
Socket, ein File oder ein shared memory identifier. Gibt libs, die da
helfen.

> > memcpy geht ja nur, wenn die "hardware" und ich sag mal "das OS"
> > anhähernd gleich sind. Also Byteorder passt, das gethostbyname (oder so)
> > hat auf verschienen Platformen die gleiche Bedeutung.
> 
> Gut, unter gleichartigen Systemen könnte man dann ebenfalls statt der
> Serialisierung die Datenstrukturen direkt durchs Netz via TCP/IP jagen,

Nein, kann man nicht. Beziehungsweise so gut wie nie.

> > Warum Tools /proc benutzen, ist mir persönlich allerdings nicht klar;
> > vielleicht, weil /proc da war und funktioniert hat, also einfach,
> > schnell und pragmatisch ist.
> 
> Ich finde, das ist ein sehr guter Grund. Wieso sollte mein Programmcode
> 'zig verschiedene Funktionen aufrufen, die es vielleicht gar nicht auf
> jedem System gibt, statt einfach /proc lesen zu lernen. 

Na ja, aber /proc ist ja auch kein Standard, oder? 

> Wären die Einträge in /proc auch noch stärker standardisiert, wäre es
> sogar noch leichter, entsprechende System-Info-Tools zu schreiben.

Du kannst natürlich nur standardisieren, was gleich ist. Wenn Dein OS
keine Gruppen oder User kennt, oder pids strings und keine ints sind,
oder die Hardware ein neuronales Netz ist, wo sowas wie ein Prozess oder
eine uarea keinen Sinn macht (ok, das letzte Beispiel knallt mit allem
lol)...

> Was ist daran nicht erstrebenswert?

Haste ein altes oder embedded Linux, fehlt irgendwas, merkste es dann
zur Laufzeit oder gar nicht, das ist sehr schlecht.  

Fehlt ne API in einer embedded libc, merkt das spätestens der Linker,
das ist viel besser :)


oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.