Präsentiere: siginfo-ng 0.1

Zitat von Wynton

(obwohl ich als Programmiersprachen-Noob davon ausgehe das man siginfo-ng zu 80% umschreiben dürfte.).

Problem ist Netzwerk (also HTTP) und der ganze Kram, den gibts in C nicht plattformunabhängig, ohne besondere Bibliothek. Und die Plugins selber müssen um an die Infos ranzukommen direkt Linux-Funktionen verwenden. Plugins muss man also so oder so auch für Windows neu schreiben.

Ansonsten dürfte man siginfo-ng ohne Plugins vermutlich mit einer POSIX-kompatiblen Umgebung wie cygwin unter Windows kompileren können. Unter OSX kompiliertes ja angeblich.

Zitat von Blue-Fox

Was ich gut finden würde, wenn gandro mir verraten würde, wie das mit den Makefile krams ist, oder sonstige Implentierungen in siginfo-ng, damit ich mein Plug-In so implrntieren kann, wie ich mir das vorstelle.

Als Pluginentwickler brauchst du nicht an der Makefile rumzufummeln, lediglich wenn es dich interessiert, wie das intern läuft, aber dazu musst du so ne Makefile auch lesen könne, um das zu verstehen.

Kleines Beispiel-Plugin:

#include <stdio.h>


#include "../plugin.h"
#include "../siginfo-ng.h"


void myplugin_funktion(plugin_t *self) {
    int variable = 42;
    set_value(self, &variable, T_INTEGER);
}


void myplugin_init() {
    register_plugin("MY_PLUGIN", myplugin_funktion);
}

Beachten: #include "../plugin.h"#include "../siginfo-ng.h"

Wird benötigt für die Funktionen und Datentypen die man als Plugin braucht. Dass man die <stdio.h> einbinden muss, ist mehr ein Bug den ich gerade gefunden habe.

Wichtig: Der Dateiname (hier myplugin.c) muss auch in den Funktionen verwendet werden. Wenn du also im "plugins" Ordner eine "myplugin.c" erstellst, muss in dieser Datei eine Funktion myplugin_init() vorhanden sein.

Diese Funktion wird beim Starten von siginfo-ng bei allen Plugins aufgerufen, in dieser Funktion meldest du deine "Hooks" an. Im obigen Beispiel soll beim Hook "MY_PLUGIN" (in der Konfigurationsdatei dann {MY_PLUGIN}) die Funktion myplugin_funktion bei jedem Update aufgerufen werden.

Die Funktion muss einen Parameter als Pointer von Typ plugin_t sein. In diesem Beispiel, heisst der self. Jetzt kannst du in der Funktion tun und lassen was du willst, das Resultat, welches am Ende in der Signatur angezeigt werden soll, gibst du dann über die Funktion set_value(plugin_t *plugin, const void *value, type_t type) zurück.

Den Wert hinter dem Pointer *value (in diesem Falle &variable) kannst du danach wieder löschen/freigeben, er wird kopiert. Als Datentyp kannst du momentan Strings (T_STRING), Ganzahlen (T_INTEGER), Gleitpunktzahlen (T_FLOAT)) oder lange Ganzzahlen (T_LONG) zurückgeben.

Die fertige Datei kommt wie gesagt mit richtigem Dateinamen ins "plugins"-Verzeichnis. Danach machst du im Hauptverzeichnis (da wo die Makefile liegt) sicherheitshalber erstmal ein "make clean", danach ein "make config", wo du dein Plugin jetzt mit Y aktivieren kannst. Danach compilieren mit "make".

Ein Tippfehler: int [b]variablbe[/b] = 42;

Noch ein Flüchtigkeitsfehler: Du hast den Hook in deinem Quellcode BOFH_PLUGIN und nicht BOFH genannt.

Überigens, falls das Ding dann läuft und du mehr machen willst, schau dir die Ausgabe von Strings & Co evtl. das Beispiel-Plugin von weiter vorne an:

https://www.winhistory-forum.net/71451-post36.html

Hast du auch neu kompiliert?

Hast du auch dran gedacht, dass das möglicherweise installierte siginfo-ng nicht dem eben gerade kompilierten ./siginfo-ng entspricht?

*push*

Das Plugin-Framework von siginfo-ng 0.1 an sich ist ein bisschen unpraktisch, abgesehen davon, dass Blue-Fox und Blue, afaik die beiden einzigen die noch bisschen daran rumbasteln, nur C-Basiskenntnisse haben, ist es mühsam, die Binary jedes mal neu zu kompilieren für andere Plugins.

Ich hab mir überlegt, das ganze Pluginsystem mit dynamischen Libraries zu machen (.so-Dateien über dlopen() und Co), das gibt allerdings viel zu tun, und macht im Grunde nichts einfacher, im Gegenteil, nur vieles komplizierter, dafür müsste nur nicht mehr so oft kompilieren.

Daher ist mein Gedanke, einen Lua-Interpreter in siginfo-ng 0.2 einzubauen. Würde heissen: Man schreibt Plugins zukünftig nicht mehr in C, sondern in Lua. Dessen Standard-Bibliothek kann zwar nur wenig mehr als Dateien und Prozesse öffnen und Strings parsen, aber für 95% der existierenden Plugins machen ja genau das.

Das coole an Lua ist, dass es wirklich überall läuft (überall wo ANSI-C läuft, also wirklich überall) und nicht zwingend eine Abhängigkeit darstellt, da man die ganze Sprache inkl. Standardbibliothek direkt ins Binary mit einkompilieren kann, sind nur rund 120KB.

Vorteil ist: Man kann Plugins als Scripte schreiben, zur Laufzeit laden, muss nur einmal kompileren und hat ne einfachere Programmiersprache.

Frage ans Publikum ist jetzt daher, ob die Leute, die siginfo-ng nutzen bzw. daran basteln, Interesse haben das einzubauen, oder ob sie lieber mit dem alten statischen C-Müll bleiben wollen, daran werd ich aber in naher Zukunft nichts tun.