Main Page | Namespace List | Class Hierarchy | Class List | File List | Namespace Members | Class Members | File Members | Related Pages

Libsmbios Concept/Design Review Presentation

Why libsmbios?

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:

Here is a brief description of each of the above problems, an example of the problem, and the ways in which libsmbios sets out to help with this problem.


Dependency Management

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:


Changing Requirements

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:


Rigidity

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:


Fragility

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:


Immobility

Problem: "Inability to reuse software from other projects or from parts of the same project."

Example:

How libsmbios helps:


Viscosity of Design

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:


Viscosity of Environment

Problem: When development environment is slow and inefficient. Long compile times, long checkin times, etc.

Example: ClearCase

How libsmbios helps:



Design Principles

The Open Closed Principle (OCP)

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:

The Dependency Inversion Principle (DIP)

Always depend on abstractions rather than concrete implementations.

How this is applied to libsmbios:

Package Architecture

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."

Package Coupling

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:

~1300 Raw LOC for SMBIOS table parsing

~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. :-)


Generated on Wed Apr 11 16:25:11 2007 for SMBIOS Library by doxygen 1.3.5