Symantec Developer Group

 View Only
Expand all | Collapse all

FAQ: Why do we have a concept of static plugin agents in these platforms?

  • 1.  FAQ: Why do we have a concept of static plugin agents in these platforms?

    Posted Aug 15, 2011 03:00 AM

    Here's a question that we received in our Dev Team group email, and thought it was a good discussion thread to share:

    Why do we have a concept of static plugin agents in these platforms? If I am correct, there is no such concept for Windows platforms. Why does the NS agent on linux and unix unload a plugin agent if it isn't static?



  • 2.  RE: FAQ: Why do we have a concept of static plugin agents in these platforms?
    Best Answer

    Posted Aug 15, 2011 12:11 PM

    Please find comments inline below.

    > Why do we have a concept of static plugin agents in these platforms?
    The static plugins is a special type of plugins that are meant to be loaded when the agent starts up and typically never allow unloading themselves. The examples of such plugins include Task Scheduler, Package Server and Policy Manager.

    You may specify that your plugin is static by completing two steps:

    1. Specify that the plugin should load at startup during plugin registration with aex-helper (-s option).
    2. Refuse non-forced unload requests in your plugin implementation class.

    > If I am correct, there is no such concept for Windows platforms.
    Yes, you are correct. There is no such concept for Windows platforms.

    > Why does the NS agent on linux and unix unload a plugin agent if it isn't static?
    Plugin Manager will periodically query the plugin whether it can be unloaded. When a plugin is unregistered or marked for upgrade, Plugin Manager calls RequestUnload() to find out whether the plugin can be unloaded. If the plugin agrees or if unload is forced, Plugin Manager:

    1. Disables incoming remote requests for plugin.
    2. Disables incoming local requests for plugin.
    3. Waits until all existing requests into the plugin complete processing.
    4. Destroys the plugin object obtained from PluginMain.
    5. Physically unloads the plugin module from memory.
    The 4th step may take significant time. For this reason the RequestUnload() function is suggested to set some flag that would be checked in request processing functions and abort their execution.