Many systems management applications require access to data stored in the system SMBIOS table. Some sort of uniform mechanism is needed by diverse groups across Dell to access SMBIOS information. Currently there are numerous disjoint libraries within Dell used by various groups to get this information. This is not acceptable because we are collectively duplicating work instead of solving the underlying problem.
In this presentation, I have attempted to list all of the various reasons I have seen for the existing lack of code reuse and sharing in Dell in this specific area. I have then listed the specific ways in which libsmbios has sought to address each of these problems. Most of the existing implementations of code to obtain information from SMBIOS present one or more of the following difficulties:
Problem: Bringing in one small piece of code necessitates bringing in a pile of supporting code just to use the one component you want. Developers become hesitant to bring in code due to this. Some projects have tight space/depencency requirements that others may not have. Libs that do not target lowest common denominator are likely to be shunned.
Example: DUP/SVM: managing compatibility against N prior versions of Disney because they have to work with existing installed version of Disney.
How libsmbios helps:
Problem: Code originally written for one project may not be suitable for another project due to differences in requirements between the projects. For example, one project might assume a static install on a target system, while another assumes that it must run with zero-install footprint. Obviously the latter will have great difficulty using the former, depending on the assumptions made by the former.
Example: Autry/SVM cannot rely on existing, installed version of Disney to gather data, neither can they rely on Disney _not_ being installed and use their own because Disney lacks a contention resolution mechanism. Catch-22 results.
How libsmbios helps:
Problem: "Tendency for software to be difficult to change, even in simple ways." For example, if the software does not have a clear and concise way of extending the code to support future systems, then people will be confused about how to add this support when it is needed. They may attempt to do it the "wrong" way, degrading the design.
Example: Existing code for SMBIOS parsing from almost everywhere has no automated unit test framework to back up changes to the code. Every change to the code must undergo an extensive, manual unit test phase to ensure that problems are caught on every system, from legacy to yet-to-be released systems. If there are holes in the manual unit test plan, then there are potential "test escapes".
How libsmbios helps:
Problem: "Tendency of software to break in many places each time it is changed." Closely related to Rigidity. This describes that aspect of software engineering where adding a new feature breaks previously-working features, or fixing a bug in one configuration breaks another configuration.
Example: Everybody can supply their own example here where a change in one spot of the code broke a completely unrelated module. :-)
How libsmbios helps:
Problem: "Inability to reuse software from other projects or from parts of the same project."
Example:
How libsmbios helps:
Problem: When "design preserving" methods of change are harder to employ than design-destroying methods of change.
Example: Disney code to get System ID. One 300-line C function that covers all platforms. Developers adding a new system to this function are faced with the daunting task of figuring out _how_ to do this with no concrete way of knowing that their change broke no legacy platforms.
How libsmbios helps:
Problem: When development environment is slow and inefficient. Long compile times, long checkin times, etc.
Example: ClearCase
How libsmbios helps:
We should write our modules so that they can be extended, without requiring them to be modified.
We want to be able to change what the modules do without changing the source code of the modules.
How this is applied to libsmbios:
Always depend on abstractions rather than concrete implementations.
How this is applied to libsmbios:
The Release Equivalency Principle (REP) "The granule of reuse is the granule of release"
The Common Closure Principle (CCP) "Classes that change together, belong together"
The Common Reuse Principle (CRP) "Classes that are not reused together should not be grouped together."
The Acyclic Dependencies Principle (ADP) "The dependencies between packages must not form cycles."
The Stable Dependencies Principle (SDP) "Depend in the direction of stability."
How this is applied to libsmbios:
Statistics:
~800 Raw LOC for SMBIOS CMOS Token parsing/manipulation
~700 Raw LOC for XML-Enhanced SMBIOS Parsing
~400 Raw LOC for common
~450 Raw LOC for Memory access (Linux/Windows)
~500 Raw LOC for CMOS access (Linux/Windows)
credits:
there isn't anything else here. go back to the main page and look at the pretty pictures. :-)