Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)

Wie schon angekündigt, hab ich siginfo-ng praktisch von Grund auf neu geschrieben, jetzt mit Lua für Plugins, anstelle statisch einkompilierter C-Funktionen.

Beitrag

Präsentiere: siginfo-ng 0.1

*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…

gandro

23. Juli 2010 um 18:42

Ich bin allerdings mit der Plugin-Architektur noch nicht so ganz zufrieden, daher veröffentliche ich meinen Status-Quo (der abgesehen vom noch nicht zufriedenstellenden Plugin-System aber robust sein sollte) als Pre-Release. Das Ding bietet nicht alle Features der 0.1.xer-Serie, ist daher viel mehr zum ausprobieren und Feedback geben gedacht, wie man dass dann in der "finalen" 0.2.0er machen soll.

Dokumentation ist praktisch nicht existent zur Zeit. Für Plugins gilt grundsätzlich folgendes:

Es sind gewöhnliche .lua-Dateien, die an sich keine besonderen Anforderungen erfüllen müssen. Diese werden von siginfo-ng geladen und ausgeführt. Alle aus sicht des Plugisn globalen Variabeln befinden sich allerdings in einer separaten Table, und können in der Config-Datei dann so angesprochen werden. Beispiel:

-- Datei "plugin.lua"


local tmp = 21
illuminaten = tmp + 2


function random()
    return math.random(0, 100)
end

Lädt man diese Datei in der Konfigurationsdatei (config.lua) mit load_plugin("plugin", "plugin.lua"), dann kann man in der Konfigurationsdatei im Layout diese wie folgt verwenden:

siginfo.layout = {} -- neues, leeres Layout
siginfo.layout.row1 = { "Zahl der Illuminaten: ", plugin.illuminaten }
siginfo.layout.row2 = { "Zufallszahl: ", plugin.random }

Während plugin.tmp via Konfigurationsdatei nicht ansprechbar ist. Hoffe, das ist einigermassen verständlich.

Problem an der Architektur ist, dass zwar ständig ändernde Werte möglich sind (siehe plugin.random, diese Funktion wird bei jedem Update frisch aufgerufen), aber das bei vielen kleinen Werten sehr mühsam wird (siehe mem.lua). Daher wäre ich um Feedback froh.

Auch ein ungelöstes Problem ist es, wie und wo man die Plugins lädt. Zur Zeit gibt es in der Config-File zwei Funktionen: load_plugin(ns, file) und load_plugin_dir(file), erstere lässt einem bestimmen, wie das Plugin angesprochen wird, zweitere lädt einfach alle Plugins in einem Verzeichnis und gibt ihnen den Dateinamen als Namespace.

Grundsätzliche Lua-Kenntnisse sind allerdings schon von nöten, daher empfehle ich folgende Seiten:
Lua für Anfänger: Lua fr Anfnger
Programming in Lua (Buch, englisch): Programming in Lua, Second Edition
Lua 5.1 Sprachrefrenz (englisch): Lua 5.1 Reference Manual - contents

Der Rest sollte einigermassen fertig sein. HTTP-Support wurde komplett überarbeitet und fehlerbereinigt, auch wenn der HTTP-Parser nicht immer ganz standardkonform arbeitet, so reicht es wenigstens für siginfo.de. Die Portabilität wird vorerst etwas zurückgegangen sein, weil ich 2-3 POSIX-Funktionen mehr verwendet habe, und sogar eine GNU-Funktion, auf einem Linux mit dynamischer glibc wird es aber funktionieren. Während statisches reinkompilieren des Lua-Interpreteres unter
Arch zwar funktioniert hat, aber das Binarie danach nich lief. Daher auch Pre-Release.

Download wie immer auf GitHub: gandro's siginfo-ng at master - GitHub

Fürs Protokoll: Die Portabilität ist ggf. doch nicht so übel wie befürchtet, hab siginfo-ng ohne Änderung im Quellcode statisch kompiliert gekriegt, auf Basis der dietlibc.

Man muss die dietlibc zwar für libm patchen, damit es mit Lua läuft, und Lua selber braucht auch einen Einzeiler-Patch, dann läufts aber und man kriegt ein statisch gelinktes Binary, ohne jegliche Abhängigkeiten (anders als das alte siginfo-ng, was mit der glibc auch nicht komplett statisch kompilieren konnte, wegen DNS), und das ganze Programm ist nur 254 KBytes gross (inklusive HTTP und Lua).

Einzig io.popen() von Lua wird rausgeschmissen, weil "posix" ein zu generisches Target für Lua ist. Das kann man aber bestimmt wieder reinholen.

Nachtrag: Das mit popen ist Blödsinn, das ist drin wenn man POSIX macht. Man muss es nur auch nutzen.

Werd mir das was überlegen, wie man das etwas automatisieren kann.

Drittes Pre-Release ist oben (siginfo-ng 0.2.0pre3)
 16 files changed, 575 insertions(+), 221 deletions(-)

Es existiert nun ein Plugin-API. Plugins müssen mit using "VAR" bestimmen, welche Template-Variablen sie verwenden wollen, und können diese dann nach belieben auffüllen. Dazu gibt es jetzt vier Helfer-Funktionen: siginfo.ng.loadplugin (einzelnes Plugin laden), siginfo.ng.loadfolder (ganzes Verzeichnis voller Plugins laden), siginfo.ng.readexec (Befehl zu String) und siginfo.ng.readfile (Datei zu String).

Ein bisschen stolz bin ich auf die neue Makefile, mit der man jetzt Lua direkt mit einkompilieren kann, so dass das Binary nicht mehr Abhängigkeiten hat, als 0.1.x. Einfach mit make include-lua bauen, und er saugt sich die Sourcen von Lua mit wget und baut sie.

Dazu gab es weitere Verbesserungen in der Makefile, für Non-GNU-Systeme etc.

Plugins habe ich alle neu geschrieben und paar hinzugefügt, was jetzt allerdings noch fehlt, ist ne Idee wie man das jetzt für die verschiedenen Architekturen machen will mit den Plugins.

Zur Zeit können Plugins zwar ihr Laden verhindern, wenn sie während der Initialisierung ein "false" zurückliefern, aber das könnte unübersichtlich werden.

Ein Plugin sähe dann in etwa so aus:

--[[
    Beispielplugin
]]


using "GPU"


if __init__ then
     -- überprüfe ob das System überhaupt kompatibel ist
     -- ansonsten 'return false'


     -- einmaliges Setzen einer Variable
     GPU.MODEL = getGPUModel() 


     -- ... usw
end




-- diese Variable hingegen wird bei jedem Update durchgeparst, 
-- weil nicht im __init__-if drin.
GPU.MEMORY.FREE = getGPUFreeMemory()

Man kann mit LUA_PREFIX das wget'en und entpacken umgehen, in dem man sagt, wo er die entpackten Dateien herkriegt.

make LUA_PREFIX=/pfad/zu/den/lua/sourcen include-lua

0.2.0pre4 ist oben. Nur wenig neues, einzig das Problem mit plattformabhängigen Plugins sollte jetzt gelöst sein. Das ganze funktioniert so:

Das plugins/ Verzeichnis wird ab sofort von der Makefile erzeugt. Dazu holt es die Plugin im Quelltext aus dem platform/-Verzeichnis und kopiert die nach plugins/ - alle nicht lauffähigen Plugins werden also gar nicht erst kopiert.

Dieses ist wie folgt aufgebaut: platform/OS/ARCH/plugin.lua

OS und ARCH sind hierbei Platzhalter, OS wird mit `uname -s` ersetzt, ARCH mit `uname -m` - wobei ARCH je nach dem etwas normalisiert wird (hab ich ausm Linux-Kernel geklaut, den Code).
Beispiel:

• Ein Plugin, was nur auf einem 32bittigen x86 Linux läuft, liegt in platform/Linux/i386/ - hierbei ist es egal ob `uname -m` nun i386 oder i686 zurückgibt, die Makefile normalisiert dies.
• Ein Plugin was nur auf OSX läuft, aber sowohl auf PPC als auch x86, würde dann im Verzeichnis /plattform/Darwin/ liegen.
• Alle Plugins, welche direkt in platform/ liegen, haben auf jedem POSIX-kompatibel Systen lauffähig zu sein (zur Zeit uname.lua und harddisk.lua).

Anzeigen kann man die normalisierte Architektur (aus mipsel wird mips, aus i686 wird i386) und das Betriebsystem mit "make echo".

Die Werte ARCH und OS können auch innerhalb von siginfo-ng ausgelesen werden, über die Lua-Variablen siginfo.ng.arch und siginfo.ng.os - das bringt bei Plugins was, die bis auf wenige Details auf verschiedenen Plattformen identisch sind. /platform/Linux/cpuinfo.lua ist so ein Fall zur Zeit, da wird zur Laufzeit geschaut ob die Kiste ne x86er oder SPARC-Kiste ist und setzt die Variablen dementsprechend anders. Plugins können nach wie vor ihr Laden zur Laufzeit noch verhindern, in dem sie 'return false' im __init__-Block machen.