Ich hab über das Problem in letzter Zeit auch nachgedacht, und bin mir nicht sicher, ob das so ohne Probleme klappt. Die Plugins existieren ja in separaten Modulen, und ein direkter Zugriff auf die Exporte eines anderen Plugins sollte eigentlich nicht möglich sein...
VDR lädt die Plugins über dlopen() und ohne RTLD_GLOBAL, daher sind die exportierten Symbole der Plugins nur über dlsym() erreichbar. Umgekehrt erbt das Plugin natürlich alle Symbole von VDR.
Und auch der Zugriff über dlsym() von einem Plugin zum anderen ist verwehrt, da VDR das Modul-Handle nicht ohne weiteres heraus rückt. Man könnte natürlich das andere Plugin nochmal in den Kontext des ersten Plugins einbinden, müsste dazu aber den Pfad zur Datei kennen. Leider ist auch cPluginManager::directory privat.
Es wäre auch möglich, den kompletten Code für die gemeinsamen Funktionen in beiden Plugins einzubinden, nicht nur die Header. Dann wäre der Programmcode aber doppelt vorhanden, und ich bin mir nicht sicher, ob die entstehenden Objekte dann auch noch wirklich den gleichen Typ haben.
Ganz katastrophal wird es natürlich, wenn die Plugins nicht exakt die gleiche Quelltextversion verwenden. Wenn sich der Speicheraufbau geändert hat, ist das Chaos vorprogrammiert.
Einen Trick hab ich aber noch ausgemacht: cPlugin::SetupParse() ist Public, kann also auch von anderen Plugins aufgerufen werden. Da liesse sich ein Interface durchtunneln. Und da unbekannte Setup-Variablennamen normalerweise ignoriert werden, kann noch nicht mal etwas schief gehen, wenn das angesprochene Plugin das Interface nicht unterstützt.
Klasse wäre es natürlich, wenn VDR so ein Interface von sich aus anbieten würde, in etwa virtual bool cPlugin::CustomInterface(char *InterfaceName, void *Data).
Gruß,
Udo
