Universal module model

• US 8,484,616 B1
• Filed: 06/23/2009
• Issued: 07/09/2013
• Est. Priority Date: 06/23/2009
• Status: Active Grant

• Current Assignee: Emc IP Holding Company LLC (Dell Technologies Inc.)
• Original Assignee: EMC Corporation (Dell Technologies Inc.)
• Inventors: McCann, Peter J., Gould, Christopher M.
• Primary Examiner(s): Nguyen, Phillip H
• Application Number:
  US12/456,835
• Time in Patent Office: 1,477 Days
• Field of Search: 717120-123, 717/106, 717/107
• US Class Current: 717/120
• CPC Class Codes: G06F 8/20 Software design
• CPC Class Codes: G06F 8/30 Creation or generation of source code

Abstract

Described are techniques for processing a module. A module is generated for execution on a target operating system. The module includes four entry points and code portions associated with each of said four entry points. The four entry points correspond to four handlers invoked at different processing points in connection with a state associated with said module. The four handlers include a load handler, an unload handler, a start handler, and a quiesce handler. First processing is performed in connection with the module. The first processing including at least one of dynamically loading the module, dynamically unloading the module, starting module-specific processing performed by the module, and issuing a request to commence preparation for unloading the module. An appropriate one or more of the four handlers are invoked in accordance with the first processing performed.

Claims

1. A computer implemented method for processing a module comprising:

generating a module for execution on a target operating system, said module including four entry points and code portions associated with each of said four entry points, said four entry points corresponding to four handlers invoked at different processing points in connection with a runtime state associated with said module, said four handlers including a load handler invoked in connection with dynamically loading said module, an unload handler invoked in connection with dynamically unloading said module, a start handler invoked in connection with starting module-specific processing performed by said module, and a quiesce handler invoked in connection with a request to commence preparation for unloading the module;

performing first processing in connection with the module, said first processing including at least one of dynamically loading the module, dynamically unloading the module, starting module-specific processing performed by the module, and issuing a request to commence preparation for unloading the module; and

invoking an appropriate one or more of the four handlers in accordance with the first processing performed, wherein said module is dynamically loaded into an address space of a target container, said target container including code for managing a container module database of modules and associated module information of modules included in the target container, wherein said code for managing a container module database is executed prior to each invocation of any of the four handlers to perform processing at runtime when executing code of the target container to enforce rules of a runtime state model for the module thereby verifying that the module is in an allowable state for a requested transition to another state associated with one of the four handlers subsequently invoked in said each invocation, said runtime state model including valid transitions between runtime states associated with each of said four handlers, said code for managing the container module database acting as a proxy to facilitate invocation of any of the four handlers upon successfully verifying the module is in an allowable state for a requested transition.

2. The method of claim 1, wherein said module is an operating system specific module and the method further comprising:

dynamically loading said operating system specific module into an address space of a container; and

invoking said load handler.

3. The method of claim 2, further comprising:

determining a runtime state associated with the module at a point in time in connection with whether the module at the point in time is loaded, unloaded, quiesced, or started.

4. The method of claim 1, wherein said quiesce handler is invoked in connection with a request to have the module stop providing a service or performing work.

5. The method of claim 1, wherein said module is an operating system specific module and said generating the module further comprises:

analyzing a first code module to generate an operating system specific skeleton in accordance with the target operating system; and

generating the operating system specific module which includes code for the operating system specific skeleton and code for the first code module.

6. The method of claim 5, herein said operating system specific skeleton includes an operating system dependent portion and an operating system independent portion, said operating system dependent portion varying in accordance with whether the target container is a user space container or a kernel space container.

7. The method of claim 6, wherein, in connection with dynamically loading and unloading the operating system specific module into the address space of the target container and the target container is a kernel space container, the target operating system transfers control to the operating system dependent portion, code of the operating system specific dependent portion transfers control to the operating system independent portion, and code of the operating system independent portion transfers control to the code for managing the container module database to register addresses of the four handlers.

8. The method of claim 5, wherein said code for managing a container module database of modules performs processing including maintaining a module table of module information for each module of said target container, said module information including a runtime state of said each module, resource information for said each module, and addresses of handler entry points for said each module, said handler entry points being addresses of the four handlers.

9. The method of claim 8, wherein said code for managing the container module database performs processing to enforce valid state transitions in accordance with said run state model and state information included in the module table.

10. The method of claim 8, wherein said resource information for a module includes an indication as to whether resources are currently allocated and in use by the module.

11. The method of claim 1, wherein processing for dynamically loading the module includes a first portion for physically loading the module into the address space of a target container and a second portion for performing logical load processing, said logical load processing including invoking the load handler.

12. The method of claim 1, wherein processing for dynamically unloading the module includes a first portion for physically unloading the module into the address space of a target container and a second portion for performing logical unload processing, said logical unload processing including invoking the unload handler.

13. The method of claim 1, wherein said module is being dynamically loaded into an address space of a kernel space container, and the method includes transferring control to a helper module executing in user space, said helper module executing an operating system native call to dynamically load the module into the kernel space container.

14. The method of claim 13, wherein the kernel space container includes first code which maintains module information about modules of the kernel space container, the first code being invoked by the operating system as a result of executing said operating system native call to dynamically load the module, the first code updating module information to include addresses of the four handlers.

15. A non-transitory computer readable medium comprising executable code stored thereon for processing a module, the non-transitory computer readable medium comprising executable code stored thereon for:

generating a module for execution on a target operating system, said module including four entry points and code portions associated with each of said four entry points, said four entry points corresponding to four handlers invoked at different processing points in connection with a runtime state associated with said module, said four handlers including a load handler invoked in connection with dynamically loading said module, an unload handler invoked in connection with dynamically unloading said module, a start handler invoked in connection with starting module-specific processing performed by said module, and a quiesce handler invoked in connection with a request to commence preparation for unloading the module;

performing first processing in connection with the module, said first processing including at least one of dynamically loading the module, dynamically unloading the module, starting module-specific processing performed by the module, and issuing a request to commence preparation for unloading the module; and

invoking an appropriate one or more of the four handlers in accordance with the first processing performed, wherein said module is dynamically loaded into an address space of a target container, said target container including code for managing a container module database of modules and associated module information of modules included in the target container, wherein said code for managing a container module database is executed prior to each invocation of any of the four handlers to perform processing at runtime when executing code of the target container to enforce rules of a runtime state model for the module thereby verifying that the module is in an allowable state for a requested transition to another state associated with one of the four handlers subsequently invoked in said each invocation, said runtime state model including valid transitions between runtime states associated with each of said four handlers, said code for managing the container module database acting as a proxy to facilitate invocation of any of the four handlers upon successfully verifying the module is in an allowable state for a requested transition.

16. The non-transitory computer readable medium of claim 15, wherein said module is an operating system specific module and the non-transitory computer readable medium further comprising executable code for:

dynamically loading said operating system specific module into an address space of a container; and

invoking said load handler.

17. The non-transitory computer readable medium of claim 16, further comprising executable code for:

determining a runtime state associated with the module at a point in time in connection with whether the module at the point in tune is loaded, unloaded, quiesced, or started.

18. The non-transitory computer readable medium of claim 15, wherein said quiesce handler is invoked in connection with a request to have the module stop providing a service or performing work.

19. The non-transitory computer readable medium of claim 15, wherein said module is an operating system specific module and said executable code for generating the module further comprises executable code for:

analyzing a first code module to generate an operating system specific skeleton in accordance with the target operating system; and

generating the operating system specific module which includes code for the operating system specific skeleton and code for the first code module, wherein said operating system specific module is dynamically loaded into an address space of a target container, said target container including code for managing a container module database of modules and associated module information of modules included in the target container, wherein said module is a binary and the first code module is a source code module.