Contributing to the UDI Reference Implementation

We welcome contributions.  There are many ways you can help: new environments; new drivers; bug fixes;  adding missing features;  enhancing existing code; documentation updates and others.

    Coding Standards
    Environnmental Hazards
    Test Requirements
    Submitting Patches

Coding Standards

While attempts have been made to keep the code internally consistent, it's recognized that there are deviations from the guidelines below.   In general, we prefer a "when in Rome" approach; if you're editing a file that consistently uses a different convention, use that one. We're more concerned about consistency in common (shared) code than in osdep or driver code.

Environmental Hazards

Documentation Standards

(Yep.  We need some.)

The documentation for this project is all CVS controlled.   Changes to it are via commits to the tree, just like code.

Generated HTML (as from Netscape Composer) is adequate, though hand-edits on the files are probably more common for day-to-day changes.

License Requirement

By contributing modifications or additional source code or documentation ("CONTRIBUTED CODE") to the Project UDI reference implementation ("the REFERENCE IMPLEMENTATION"), the contributing party ("The Contributor") hereby agrees to the following terms.

Whereas the following parties, having contributed significantly to the REFERENCE IMPLEMENTATION, are empowered, singly or jointly, to publish and maintain current and future versions of the REFERENCE IMPLEMENTATION: Hewlett-Packard Company, The Santa Cruz Operation, Inc., Compaq Computer Corporation, International Business Machines, Interphase Corporation, Sun Microsystems, Inc., Intel Corporation, Software Technologies Group, Inc., and American Megatrends, Inc. (collectively, the "Maintainers");

The Contributor hereby grants to the Maintainers and their successors and assigns, a world-wide, unrestricted, perpetual, non-exclusive, fully paid-up and royalty-free right and license to (i) prepare and/or have prepared DERIVATIVE WORKS of such CONTRIBUTED CODE; (ii) internally use, execute, copy, reproduce, display, perform, modify and have modified, such CONTRIBUTED CODE and such DERIVATIVE WORKS; and (iii) to distribute and sublicense such CONTRIBUTED CODE and DERIVATIVE WORKS, in the form of Source Code, under the terms of the Project UDI Open Source License.

The Contributor retains sole ownership of its CONTRIBUTED CODE. Nothing in this Contributors Agreement shall be deemed to transfer ownership of any portion of such CONTRIBUTED CODE from one Party (or its suppliers) to another Party. Subject to the non-exclusive licenses granted in this Contributors Agreement or other written agreement between the Parties, the owning Party shall be free in all respects to exercise or dispose of any or all of its ownership rights in its own CONTRIBUTED CODE, without accounting to any other Party.

Test Requirements

Any patch to common code should be tested in more than one environment.  Typically a kernel and POSIX implementation  on the same operating system are OK if the change is in an area with coverage in POSIX.

If possible, you should ensure that your change will at least compile on another OS.   Shell accounts on Linux  and BSD systems are available through SourceForge's compilefarm facility.

The POSIX environment is a handy test fixture to allow debugging & development of code that doesn't require DMA or "real" interrupts as a user-space application.  A 'make torture'  delivers a suprising amount of coverage of env/common; over 85% last time it was checked.   It simulates things like memory allocation failures, regions being busy across a udi_mei_call, and control block reallocation on every channel operation.   When combined with a multiple CPU system (it uses POSIX threads) and an instrumented memory checking library like Electric Fence or that avilable in many mallocs, it can help find a number of problems that are hard to expose in kernel code.

Submitting Patches

We greatly prefer small, easily reviewable, self-contained patches for independent functionality over "monster patches". This makes them easier to analyze for correctness. If, for example, you were contributing a new environment, separating out patches for the tools vs. the environment vs. the mappers would be a good idea. Separate fixes and enhancements to common code from new files to make it easier to analyze for impact on other users of that code.
When you're ready to submit your change, please include Submit the patch to For information on joining the list, see the projectudi-patches info.

Return to UDI Home Page on Sourceforge

File last modified: 00:00 Thu January 1, 1970