Für solche Fälle kann man auch select() oder poll() oder epoll() oder kqueue nutzen. Du kannst ja nicht nur auf zu schreibende, sondern auch auf zu lesende Daten warten. Ursprünglich funktionierte das nur mit Sockets, inzwischen kannst du diese libc-Funktionen auch auf Dateihandles anwenden. Es sei denn, ich irre mich gerade gewaltig.
Gut, das klingt so als wenn das nicht immer so war? Mir geht es darum, das diese "Dateien" im Kernel also speziell behandelt werden, das aber hinter einer Datei versteckt wird.
Sockets sind keine Dateien. Diese API wurde anfangs nur für Sockets zugelassen, weil sie Teil des Netzwerklayers war. Inzwischen ist es möglich, diese API auch auf Dateien anzuwenden (select(2) gibt als Beispiel stdin an), einfach weil sie deinen Anwendungsfall (der recht häufig ist), gut lösen kann, gut getestet ist und vor allem für beides funktioniert.
Ansonsten müsstest du eine File Notification API erfinden und nutzen, was auch geht - und wenn ich mich recht entsinne, gibt es sowas unter POSIX zusätzlich auch. Die WinSock erlaubt select()/poll() nur für Sockets, nicht für Dateien.
Du könntest z.B. mehrere verschiedene Versionen dieses "call´s" haben mit verschiedenen Parametern und wenn ein altes Programm nicht alle Parameter übergibt, dann werden in die restlichen Standardwerte reingeschrieben.
Warum nicht einfach alle Felder "mandatory" machen und die Anwendung mit Standardwerten operieren lassen?
Wie gesagt, es vereinfacht den Userspace ungemein, wenn du nicht irgendwelche API-spezifischen Headerdateien einbinden musst, sondern es mit der Standard-libc erschlagen kannst.
Das ist aber genauso gut möglich wenn die Verzweigung in die einzelnen APIs noch in der libc drin ist, solange die allgemeinen Headerdateien erstmal reichen sehe ich da keine Probleme.
Ich meinte ja auch die Schnittstelle zwischen Anwendungen und Kernel, wo diese Philosophie halt echt gut funktioniert, einfach und gleichzeitig mächtig ist.
Wie du die Schnittstelle zwischen Kernel und Treiber gestaltest, spielt (für mich) an der Stelle garkeine Rolle. Genausowenig, ob du diesen Wrapper (Kernel und Anwendung kommunizieren über Dateien) nun im Kernel/VFS oder in der libc versteckst.
XML ist ein Gerüst der Hölle.
Aha, dafür schwören aber ne Menge Leute auf XML.
Guck dir mal übliche, auf XML aufsetzende Netzwerkprotokolle an (MSN Messenger, ...). Da werden teilweise Binärdaten roh mitgeschickt, teilweise mit Base64 encodiert und dann hat man XML mit Base64 ENcodiert. Das sind grausame Protokolle, die da unterwegs sind. XML ist nur solange gut, wie man ein gut durchdachtes Protokoll dahinter ansetzt, wo man sich vorher Gedanken gemacht hat.
Und genau dann braucht man kein extensibles Textprotokoll wie XML mehr.
Wer auf Anhieb eine XML-Implementation fehlerfrei hinkriegt, der ist entweder ein Genie oder ein Lügner.
oder er hat sich auf das wirklich benötigte beschränkt.
Da hab ich aber schon andere Sachen gehört und gelesen...
Das geht binär genau so gut und ist leichter zu parsen/interpretieren.
Aber, binär legst du auch die Reihenfolge fest und wie willst du es machen einen neuen Parameter hinzuzufügen ohne das es Probleme mit alten Programmen gibt. Auch wäre es so kein Problem wenn sich irgendwelche IDs ändern würden (z.B. bei Syscalls) weil man ja den direkten Namen nimmt.
Ob dein Service nun "VFS_Handle_File_Open" oder "142" heißt, spielt keine Rolle. IDs ändern sich übrigens auch nicht von alleine, wenn du die vorher festlegst - genausowenig wie Namen.
Der Unterschied ist, dass dir bei Zahlen niemand den Text-Parser kaputtmachen muss - und dass ein Cast auf int einfach schneller ist, als ein Textparser, der am Ende eh nur ein Handle hinten rauswirft...
Gruß,
Svenska
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken