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

[Steffen Dettmer]

* Volker Grabsch wrote on Wed, Apr 26, 2006 at 14:37 +0200:
> > Effizienter als ein memcpy für'n Bytebuffer?
> 
> Nein, Effizienter als er Umweg über Bytebuffer.
> 
> Momentan: Applikation A und B haben eine gemeinsame Datenstruktur,
> und kommunizieren.
> 
> Aktueller Vorgang:
>     * Serialisierung der Datenstruktur
>     * Memcopy
>     * Parsen
> 
> 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. Aber Du kannst sowas natürlich machen, und zwar sogar noch
ohne memcpy, in dem Du Deine Datenstruktur in shared memory ablegst.

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.

intel<->sparc geht also nicht (byte order)
windows<->linux geht also nicht (z.B: \ in Pfaden)

Dann kann es sein, dass /tmp/myfile zwei verschiedene Sachen sind, wenn
in der Struktur gar ein Filehandle steht, geht's erst Recht nicht.

Daher sowas wie ASN.1. Zur Laufzeit natürlich genau ein Serialisieren
und ein Deserialisieren, aber ich kann mir nicht vorstellen, wie man das
vermeiden und sauber bleiben könnte, ohne gleich auf serialisierten
(portablen) Strukturen zu arbeiten (was super bremst).

> > OK, schönes Beispiel! Aber nicht gerade Schnittstellen zwischen
> > verschiedenen Applikationen, oder? Ich mein, man ruft ja gethostbyname
> > auf und sendet keine XML Nachricht an /proc/get/host/by_name oder so.
> 
> Mag sein, aber es ist doch ein Unterschied, ob ich nur wissen brauche,
> was dort steht:
>     Liste von Feldern mit Einträgen processor, vendor_id, ...

Na ja, die dahinter stehende Kernel-Datenstruktur würdest Du dann
überhaupt nicht mehr verstehen:

24a22ea949b21822be4ca8f15e76e2845ff139ab2532ce54120e8c999c90ec9f

oder sowas? Die Länge und Bedeutung hängt natürlich mindestens von der
Kernel-Version ab ;)

> Und was "gethostbyname"... angeht: Klar sind das nette Funktionen,
> die man auch verwendet, aber nicht für alles. Du kannst doch nicht
> für jeden Eintrag in /proc einen neuen System-Call einführen, der
> Sinn und Zweck dieser "auch von menschen lesbaren" Formate ist doch,
> dass man darauf eben nicht angewiesen ist.

Na ja, ist aber langsam. Wenn ich z.B. ein /proc/current_pid hätte,
müsste ich open, read, close aufrufen. So rufe ich einfach getpid auf.
Ich denke, /proc ist zum einen für die, die sich noch richtig auskennen,
um "im Falle eines Falles" mal was spezielles nachgucken zu können, und
zum anderen für Spezifika wie Netzwerkschnittstelleneigenschaften. 

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.

oki,

Steffen

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