Short: Logging idea: Shared Library From: Christian Welzel <gawain@wh9.tu-dresden.de> Date: Wed, 21 Nov 2001 18:33:30 +0100 Type: Feature State: New Hai Lars! Wir hatten uns mal vor langer zeit ueber den driver und sein komisches logging unterhalten... du meintest, ein neues log-konzept waere noetig... heute hatte ich die idee, dass der driver ja in eine mysql-datenbank loggen koennte. problem ist natuerlich diese schwaeche im driver ... meine vorschlaege dazu: die logging-funs werden nicht mehr in den driver-kompiliert, sondern in eine externe shared-lib. diese kann man dann beim start des drivers per dlopen() oeffnen. dann gibt es drei neue funktionen: (sys)log_open(), (sys)log(), (sys)log_close(); eine neue config_option: (SYS)LOG_METHOD. (sys)log_open() laedt abhaengig von SYS)LOG_METHOD die entsprechende shared-lib, (sys)log() loggt die daten (in dem die bibliotheksfunktion aufgerufen wird) und (sys)log_close() schliesst die lib wieder... dazu wird bei (sys)log die syntax vom system-syslog genommen und auch dessen headerfile (im groben)... so kann das ausgabe-modul entscheiden, wo was wie hingeloggt werden soll... und man kann das logging an seine beduerfnisse einfach anpassen... was meinst du dazu ? --- It would be nice as additional feature. > Was mir so auf Anhieb in den Kopf kommt, sind zwei grundlegene Schwaechen > des derzeitigen Loggings: die Ausgaben sind ueber stdout, stderr, und ein > Logfile verstreut, und die Anbindung an die Mudlib ist sehr improvisiert. > Damit verbunden ist eine konfuse interne Schnittstelle. das waere mit meinem konzept elegant geloest... driverseite: der driver loggt alles mit seinem syslog(). Dieses bekommt ja informationen, wer loggt (facility) und was geloggt wird (level: warn, crit, etc). ausserdem noch den string um loggen und ob ungebuffert geschrieben werden soll... also: int syslog(int fac, int level, char *message, bool flush) die lib kann dann ein konfigfile bekommen, wo jeder mud-betreiber einstellen kann, welche fac und welches level wohin geloggt wird. jeder kann dass also nach seinen wuenschen anpassen. > Ganz loswerden will ich direkte Ausgaben auf stdio/Logfile nicht, da dies > ein sehr effizientes Mittel zur Fehlerdiagnose ist. Was fehlt, ist eine > Festlegung, welche Ausgaben wohin gehoeren, und eine einfache > Schnittstelle, die sowohl die Logfiles als auch die Mudlib bedient (und > dabei mit mehrzeiligen Eintraegen klarkommt). die ausgaben kommen alle in die externe lib, auch die string-ausgaben. dass hat nicht wirklich nachteile, fuehrt aber zu besser kapselung. man kompiliert also nicht mehr alles in den driver, sondern der driver hat halt std-maessig die lib dabei, die in die dateien loggt... wer was anderes moechte ersetzt einfach die lib, man koennte auch einfach sowas wie log-chains machen: erst loggt lib1, dann lib2,... zum schluss libx. wie gesagt, was wo hinkommt, kann der admin selbst konfigurieren... zur mudlib-schnittstelle: man koennte ne efun syslog_notify (oder so) einfuehren, die ein array/mapping uebergeben bekommt, in dem steht, bei welchen fac und welchen leveln ein driverhook aufgerufen wird. man setzt dann einfach nen driverhook HOOK_SYSLOG (oder so) und bekommt den vom driver aufgerufen, wenn der merkt, dass man das will... also (z.b.): (pseudocode :) setdriverhook(HOOK_SYSLOG, #'mysyslog(int fac, int level, string message)); syslog_notify(([F_MAIL: L_CRIT, F_DRIVER: L_ALL, F_SHELLS: L_CRIT])); was die leute dann damit machen, koennen sie selbst entscheiden... > Die Logausgaben zusaetzlich in eine Shared Library zu leiten ist eine gute > Idee, aber ich sehe das als optionales Feature. optional sollte sein, wer welche lib einsetzt, aber alle logmodule sollten als shared.lib implementiert sein. weil wenn ich nach mysql logge (oder sonstwohin), mag ich nicht auch noch in die files geloggt haben... und wenn doch, klemm ich zwei libs hintereinander und schon geht dass... ist ein sehr schoener flexibler ansatz :) --- Still: keep logs in driver, but make it possible to turn them off.
