Find the answer to your Linux question:
Results 1 to 5 of 5
Hello Everybody! I am working on a program that would benefit from having the ability to load plug-ins at run-time, giving it extra features. This is easily achieved with dynamic-linking ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Apr 2005
    Posts
    7

    Plug-in architecture for C programs in Linux


    Hello Everybody!

    I am working on a program that would benefit from having the ability to load plug-ins at run-time, giving it extra features. This is easily achieved with dynamic-linking (dlopen etc.). The problem I have is that the plugins are going to need access to various common functions provided by their host application. I am not sure what the best way to arrange the linking of the plugins with this common code is. Does anybody have any suggestions?

    I was thinking of providing these common functions in a shared library, but I do not know if the plugins will create a new library dataspace when they are linked (I don't want them to, I want one dataspace for the library common to the host app. and all the plugins). Also I would prefer to avoid going down the shared-memory, multi-threaded route if I can help it!

    Thanks in advance.

    Matt.

  2. #2
    Just Joined!
    Join Date
    Apr 2005
    Posts
    6
    Hi..

    If the common functions provided by your host are "stand-alone" (a set of helping functions that
    are sufficient by themself) you can use a shared lib to access common functions ..
    But if you want to access a host functionality dynamically you can try something:
    - When you "plug" your plugin, it's going to fill some function pointers and return them to host for further calls ..
    - But you can do the same thing in the other direction: the host can provide a set of function-pointers to the plugin that represents an "API"..

    I'm experiencing this architecture and it doensn't seem to cause problems.
    You can always uses some extra shared libs for the common "stand-alone" functions in parallel.

    this is a suggestion .. I'm aware of new ideas

  3. #3
    Just Joined!
    Join Date
    Apr 2005
    Posts
    7
    Hi Kabhal,

    Thanks for your thoughts. I have just this minute got the shared library solution I thought might work in my original post to do what I wanted. I simply put all common functions including common data variables that these functions access into a shared library. The library gets linked (and gains its data space) when the host app. starts up, then when the plugins are dynamically linked in, the shared library doesn't get linked (because it is already linked with the host app), and it turns out, a new dataspace for the library doesn't get created either (which in this application is a good thing). Thinking about it, it would actually be quite difficult for an OS to transparently manage a library running in a single process with multiple data spaces.

    Matt.

  4. #4
    Just Joined!
    Join Date
    Apr 2005
    Posts
    6
    I don't know your exact needs, but with this solution, you need to recompile the plugins each time the common library is modified. This is perhaps a constraint for the developers of your plugins.
    With solution I described, while the interface API provided by host doesn't change, you can keep your plugins as-is.

    What do you think about that ?

  5. #5
    Just Joined!
    Join Date
    Apr 2005
    Posts
    7
    I agree, your solution would be more appropriate if recompiling the plugins when I modify the common library was an issue, but luckily for me this time round, it is not!

    Thanks,

    Matt.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •