 |
 |
On Feb 15, 2012, at 7:19 AM, Andrew Hanushevsky wrote: > On Tue, 14 Feb 2012, Brian Bockelman wrote: > >> It'd be nice to write the policy about loadable modules - I've noticed the OSS and GSI interfaces have migrated a bit in trunk. It would make me a lot happier if there was a more deterministic way to tell if a module is compatible with a given version of Xrootd than to load it and watch for segfaults... > There is. We introduce a plug-in version number. Two ways come to mind: > 1) Non-disruptive: we look for a defined symbol called, say, XrdxxxPlugInVersion that holds the version number of the plugin and we verify that it is compatible. If no such symbol is found we just do what we do toay and possible segfault. > > 2) Disruptive: We define a required method in each plugin that returns a version number. We verify that. Of course, means that everyone will have to redo their plug-ins. > > That said, we do try really hard to maintain ABI compatability. If tht failed, we could try to fix it before adding to the stable branch. Anyway, which of the above methods would people prefer? > Hi Andy, I suppose either would do - I'd slightly prefer (1), as it makes the transition easier. Unfortunately, neither would work with RPM's auto-dependency resolver, so we'd still be stuck writing specific version numbers into the plugin RPMs. My ultimate dream is to make the RPMs incompatible at build time in a human-free manner: I assume that if there's a chance for me to mess things up, I likely will… Can't think of any elegant ideas on how to do this, however. Brian ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1