Hallo lieber Linux-Freunde,
ich bin hier noch neu und habe mit Linux eigentlich fast nie etwas zu tun gehabt. Ich habe die letzten 10 Jahre in einer Firma als Programmierer (unter Windows) gearbeitet. Mittlerweile arbeite ich nicht mehr in dieser Firma. Daher ist der Hintergrund dieses Thema nicht kommerziell. In den letzten drei Jahren erkannte ich dann so langsam, was hier fehlt: ein nicht improvisiertes Ereignisprotokoll.
Im Laufe dieser drei Jahre ist dieses Konzept nun immer mehr gewachsen und nun stelle ich mir die Frage, ob so etwas nicht eigentlich in das Betriebssystem gehört. Das Ziel ist es, sofern der Programmierer an eine Fehlerquelle gedacht hat, dort auftretene Fehler auch immer mit korrektem Sachbezug anzuzeigen. Hier mal eine kurze Beschreibung meiner Idee:
Es wird ein kleines Shared-Memory-Dateisystem implementiert, zu dem der Anwender prinzipiell keinen direkten Zugang erhält. Dadurch können dann in den Pfaden Binärzeichen als Steuerzeichen verwendet werden. Dies ist wichtig, damit man dem Anwender keine Einschränkungen bei der Zeichenwahl für solche Felder wie Auftragsname, Teilename usw. auferlegen muß. Dieses Dateisystem dient nur der Speicherung sicherungstechnisch noch nicht relavanter Daten. Ereignisse sind darin dann Dateien (oder Blätter) und der ErrorCode ist der Dateiname. Solche Dateien sind dann Dateien eines ganz speziellen Typs. Es können in diesem Dateisystem natürlich auch Dateien anderen Typs abgelegt werden. Die Objekte, die der Anwender/Supporter kennt, sind dann die Verzeichnisse. In einer gesunden Firma mit einem vorhandenen Application-Framework stellt dieses dann die programminterne Seite und dieses Dateisystem mit seinen Meldungen die programmexterne Seite des Software-Systems dar. In diesem Dateisystem hat jeder Thread dann ein CurrentDir, wo er gerade in diesem Dateisystem steht. Das Programm muß sich dann in diesem Baum entsprechend der gerade bearbeiteten Daten mit relativen/absoluten Sprüngen bewegen. Dies läuft dann ähnlich dem cd-Befehl von DOS.
Zu jeder Datei dieses Dateisystems gibt es dann immer einen Absender, der diese Datei angelegt hat. Dieser Absender steht mit den Threads dann in einer 1-1-Beziehung. Dieser Absender wird erst mit dem Löschen der letzten von ihm stammenden Datei gelöscht. Er überlebt also die Terminierung des Threads/Prozesses.
Der ErrorCode besteht in meinem Konzept dann aus folgenden Informationen:
Ereignistyp: Fehler, Warnung oder Information
Codesystem: eine ID, die die Integration unterschiedlicher ErrorCode-Systeme verschiedener Firmen/Software-Systeme ermöglichen soll.
Vorzeichen: Das Vorzeichen des ErrorCodes; manche Firmen/Software-Systeme verwenden negative ErrorCodes
Module-ID: Die ID des Moduls, zu dem der ErrorCode gehört (1-basiert).
Class-ID: Die ID der Klasse (1-basiert)
ID: dies ist dann nur noch eine ID innerhalb der Klasse (1-basiert).
Je nach Implementierung eines Codesystems können die letzten drei Felder auch als ein einziges Feld zusammengefaßt werden, in dem dann der absolute ErrorCode gespeichert ist. Dieses dreistufige ID-System soll einfach nur eine leichte Programmierung ermöglichen. Da als ErrorCode aber nur ein 32-Bit-Integer zur Verfügung steht, werden diese ganzen Felder als Bitdatenfelder in C deklariert.
Um dieses Dateisystem nun in das Betriebssystem integrieren zu können, müßte jedes Programm seine eigenen statischen Tabellen, über die den ErrorCodes ein Text zugeordnet werden kann, im Betriebssystem registrieren können. Der zurückgelieferte Zugriffscode für diese Tabellen muß dann im Feld CodeSystem abgelegt werden. Um die Menge der dynamisch erzeugten ErrorCodes gering zu halten, reserviert man in diesem Codesystem dann einige spezielle Werte für das Betreibssystem und für den Hersteller, der das EXE und die dazugehörigen Bibliotheken vertreibt. Auch für Standard-Bibliotheken wie C-Runtime und ähnliches kann man wohl feste Werte reservieren. Die dynamisch erzeugten ErrorCodes haben dann nur für Hersteller von speziellen Bibliotheken Bedeutung (z.B. Combit). Dies alles wird mit einem 32-Bit-ErrorCode wohl nur unbefriedigend zu realisieren sein. Ein 64-Bit-ErrorCode hingegen sollte dafür problemlos ausreichen.
Das Ziel dieses Konzepts ist es, nur noch eine einzige Ausgabe-Adresse für Meldungen zu haben. So war es ja bis in die 70er Jahre. Durch das Aufkommen grafischer Oberflächen ist diese Konsole als Ausgabeadresse für die Programme inakzeptabel geworden. In der Firma, wo ich gearbeitet habe, gibt es bis zu sechs Ausgabeadresse, die teilweise sehr speziell sind. Die einzigen universellen Ausgabeadressen sind die LOG-Datei und die Konsole, die ja unter Windows je nach Art der Anwendung (Konsolenanwendung) angezeigt wird.
So wie ich das bisher beobachtet habe, haben dieses Problem eigentlich alle Software-Systeme, mit denen ich bisher zu tun hatte. Windows gibt auch immer nur ErrorCodes als einfachen Integer-Wert zurück und der Sachbezug zum ErrorCode fehlt auch machesmal. Auch hat Microsoft mehrere inkompatible ErrorCode-Systeme (GetLastError, ODBC-ErrorCodes) in Verwendung. Gleiches gilt für List&Labels (ein Reporting-Tool) von Combit. Und in der Linux-Welt sieht es meines Wissens nach auch nicht so viel besser aus. In den Vorlesungen zu Betriebssysteme an der UNI Bremen sah das Vorgehen im Fehlerfall auch eher dem von Microsoft ähnlich. Und was die Konsequenz eines solchen Vorgehens ist (einfach eine fortlaufend durchnummerierte ID), ist klar: wenn man einen Fehlerfall nicht auf richtiges Verhalten hin überprüft hat und diese Möglichkeit eher zu den selten vorkommenden Fällen gehört, so wird der Anwender mit Meldungen der Art "Fehler: 0x34535" usw. immer wieder konfrontiert werden. Bei Sun's "VirtualBox" hatte ich vor kurzem eine solche Situation. Und vor ca. 10 Jahre hatte ich auch mal in einem Buch von einer ähnlichen frustrierenden Meldung eines Programms gelesen.
Dieses Konzept habe ich in einer Dokumentation, die fast 1MB umfaßt, detailierter beschrieben.
Wenn jemand mit dem hier gesagten nichts oder nur wenig anfangen kann, aber jemanden kennt, der sich dort auskennt, so bitte ich um Vermittlung. Wenn jemand ein Forum kennt, das besser für diesen Beitrag geeignet ist, hätte ich gerne die Adresse.
ich bin hier noch neu und habe mit Linux eigentlich fast nie etwas zu tun gehabt. Ich habe die letzten 10 Jahre in einer Firma als Programmierer (unter Windows) gearbeitet. Mittlerweile arbeite ich nicht mehr in dieser Firma. Daher ist der Hintergrund dieses Thema nicht kommerziell. In den letzten drei Jahren erkannte ich dann so langsam, was hier fehlt: ein nicht improvisiertes Ereignisprotokoll.
Im Laufe dieser drei Jahre ist dieses Konzept nun immer mehr gewachsen und nun stelle ich mir die Frage, ob so etwas nicht eigentlich in das Betriebssystem gehört. Das Ziel ist es, sofern der Programmierer an eine Fehlerquelle gedacht hat, dort auftretene Fehler auch immer mit korrektem Sachbezug anzuzeigen. Hier mal eine kurze Beschreibung meiner Idee:
Es wird ein kleines Shared-Memory-Dateisystem implementiert, zu dem der Anwender prinzipiell keinen direkten Zugang erhält. Dadurch können dann in den Pfaden Binärzeichen als Steuerzeichen verwendet werden. Dies ist wichtig, damit man dem Anwender keine Einschränkungen bei der Zeichenwahl für solche Felder wie Auftragsname, Teilename usw. auferlegen muß. Dieses Dateisystem dient nur der Speicherung sicherungstechnisch noch nicht relavanter Daten. Ereignisse sind darin dann Dateien (oder Blätter) und der ErrorCode ist der Dateiname. Solche Dateien sind dann Dateien eines ganz speziellen Typs. Es können in diesem Dateisystem natürlich auch Dateien anderen Typs abgelegt werden. Die Objekte, die der Anwender/Supporter kennt, sind dann die Verzeichnisse. In einer gesunden Firma mit einem vorhandenen Application-Framework stellt dieses dann die programminterne Seite und dieses Dateisystem mit seinen Meldungen die programmexterne Seite des Software-Systems dar. In diesem Dateisystem hat jeder Thread dann ein CurrentDir, wo er gerade in diesem Dateisystem steht. Das Programm muß sich dann in diesem Baum entsprechend der gerade bearbeiteten Daten mit relativen/absoluten Sprüngen bewegen. Dies läuft dann ähnlich dem cd-Befehl von DOS.
Zu jeder Datei dieses Dateisystems gibt es dann immer einen Absender, der diese Datei angelegt hat. Dieser Absender steht mit den Threads dann in einer 1-1-Beziehung. Dieser Absender wird erst mit dem Löschen der letzten von ihm stammenden Datei gelöscht. Er überlebt also die Terminierung des Threads/Prozesses.
Der ErrorCode besteht in meinem Konzept dann aus folgenden Informationen:
Ereignistyp: Fehler, Warnung oder Information
Codesystem: eine ID, die die Integration unterschiedlicher ErrorCode-Systeme verschiedener Firmen/Software-Systeme ermöglichen soll.
Vorzeichen: Das Vorzeichen des ErrorCodes; manche Firmen/Software-Systeme verwenden negative ErrorCodes
Module-ID: Die ID des Moduls, zu dem der ErrorCode gehört (1-basiert).
Class-ID: Die ID der Klasse (1-basiert)
ID: dies ist dann nur noch eine ID innerhalb der Klasse (1-basiert).
Je nach Implementierung eines Codesystems können die letzten drei Felder auch als ein einziges Feld zusammengefaßt werden, in dem dann der absolute ErrorCode gespeichert ist. Dieses dreistufige ID-System soll einfach nur eine leichte Programmierung ermöglichen. Da als ErrorCode aber nur ein 32-Bit-Integer zur Verfügung steht, werden diese ganzen Felder als Bitdatenfelder in C deklariert.
Um dieses Dateisystem nun in das Betriebssystem integrieren zu können, müßte jedes Programm seine eigenen statischen Tabellen, über die den ErrorCodes ein Text zugeordnet werden kann, im Betriebssystem registrieren können. Der zurückgelieferte Zugriffscode für diese Tabellen muß dann im Feld CodeSystem abgelegt werden. Um die Menge der dynamisch erzeugten ErrorCodes gering zu halten, reserviert man in diesem Codesystem dann einige spezielle Werte für das Betreibssystem und für den Hersteller, der das EXE und die dazugehörigen Bibliotheken vertreibt. Auch für Standard-Bibliotheken wie C-Runtime und ähnliches kann man wohl feste Werte reservieren. Die dynamisch erzeugten ErrorCodes haben dann nur für Hersteller von speziellen Bibliotheken Bedeutung (z.B. Combit). Dies alles wird mit einem 32-Bit-ErrorCode wohl nur unbefriedigend zu realisieren sein. Ein 64-Bit-ErrorCode hingegen sollte dafür problemlos ausreichen.
Das Ziel dieses Konzepts ist es, nur noch eine einzige Ausgabe-Adresse für Meldungen zu haben. So war es ja bis in die 70er Jahre. Durch das Aufkommen grafischer Oberflächen ist diese Konsole als Ausgabeadresse für die Programme inakzeptabel geworden. In der Firma, wo ich gearbeitet habe, gibt es bis zu sechs Ausgabeadresse, die teilweise sehr speziell sind. Die einzigen universellen Ausgabeadressen sind die LOG-Datei und die Konsole, die ja unter Windows je nach Art der Anwendung (Konsolenanwendung) angezeigt wird.
So wie ich das bisher beobachtet habe, haben dieses Problem eigentlich alle Software-Systeme, mit denen ich bisher zu tun hatte. Windows gibt auch immer nur ErrorCodes als einfachen Integer-Wert zurück und der Sachbezug zum ErrorCode fehlt auch machesmal. Auch hat Microsoft mehrere inkompatible ErrorCode-Systeme (GetLastError, ODBC-ErrorCodes) in Verwendung. Gleiches gilt für List&Labels (ein Reporting-Tool) von Combit. Und in der Linux-Welt sieht es meines Wissens nach auch nicht so viel besser aus. In den Vorlesungen zu Betriebssysteme an der UNI Bremen sah das Vorgehen im Fehlerfall auch eher dem von Microsoft ähnlich. Und was die Konsequenz eines solchen Vorgehens ist (einfach eine fortlaufend durchnummerierte ID), ist klar: wenn man einen Fehlerfall nicht auf richtiges Verhalten hin überprüft hat und diese Möglichkeit eher zu den selten vorkommenden Fällen gehört, so wird der Anwender mit Meldungen der Art "Fehler: 0x34535" usw. immer wieder konfrontiert werden. Bei Sun's "VirtualBox" hatte ich vor kurzem eine solche Situation. Und vor ca. 10 Jahre hatte ich auch mal in einem Buch von einer ähnlichen frustrierenden Meldung eines Programms gelesen.
Dieses Konzept habe ich in einer Dokumentation, die fast 1MB umfaßt, detailierter beschrieben.
Wenn jemand mit dem hier gesagten nichts oder nur wenig anfangen kann, aber jemanden kennt, der sich dort auskennt, so bitte ich um Vermittlung. Wenn jemand ein Forum kennt, das besser für diesen Beitrag geeignet ist, hätte ich gerne die Adresse.
