Novell is now a part of OpenText

Requesting a KMP

Overview

The preferred method for enabling a product (e.g., the acme 7200 card w/ driver acme_7x for the new PoshBook-7) is to create a driver kit that contains all the drivers needed for the product. Therefore, rather than requesting a KMP, it is preferable to request a driver kit (Requesting Driver-level Product Enablement).

This separation of driver kit from KMPs has two advantages: It declutters the tracking of different KMPs from each other and from the kit creation proper, and it allows for reuse of KMPs from other driver kits while respecting the privacy needs of system vendors: we might already have a very current acme_7x driver, that we created for a Fiery Server (model 4711), yet Fiery ususally prefers Posh to not know which acme card models Fiery uses, and vice versa, before the systems are on the market.

Please see Requesting Driver-level Product Enablement for how to request a driver kit in order to deploy the KMPs for a specific customer context.

Definitions

Please see Driver Process Terminology.

How to Request a KMP

!!IMPORTANT!! - it is critical to follow the bugzilla format as described below in order to ensure proper and timely processing. Requests that do not provide the proper info may be closed as INVALID.

  • Classification should be "Partner Linux Drivers".
  • Product should be “Partner Linux Driver Packages --- Code 9” (for SLES 9, NLD 9, OES 1) or “Partner Linux Driver Packages --- Code 10” (for SLES 10, SLED 10, OES 2).
  • Component should be “Kernel Package” (or “Userspace Package” if appropriate).
  • Summary should contain the driver vendor name, driver name and driver version (example: "Intel e1000 7.1.9")
  • Description should contain the following information using this template (simply cut and paste this into bugzilla and replace data with your info):
		   Partner Name: (Your company name)             
  Package Name-Version: (example: intel-e1000-7.1.9)             
  Target Architectures: (examples: "all" or "i386, x86-64, ia64")          
Target Kernel Versions: (examples: "GA", "SP3", or 2.6.5-7.282)                        
		   Supported: ("Novell supported", "Reqestor supported", or "Unsupported")
["Target Kernel Versions" can be a specific kernel release if required, or simply "GA", or the service pack to target.]
["Supported" is optional but will be assumed "Unsupported" if not specified. See "Supported (U Taint flag)" text below. "Novell Supported" can only be set by Novell.]
Kernel Module Packages Manual for CODE 9, CODE 10, CODE 11].
  • Attachment - Attach the build.log file from a successful build of the package using the build tool from SUSE's build.rpm. This file can be found at $BUILD_ROOT/.build.log. (usually /var/tmp/build-root/.build.log). This file is necessary to understand that the package did build properly before being submitted to Novell.
  • Supported (U Taint Flag) - The "U" taint flag is a kernel flag set when an "unsupported" kernel module is loaded. This flag can invalidate any customer support commitments from Novell if it is set while customers are experiencing product functionality issues. If requestor desires the module to not reflect a U Taint Flag message when loaded, then an L3 support understanding between Novell and requester needs to be confirmed. This can be done in prior communication and/or through the bugzilla entry. By removing the U Taint Flag the module will then report the supported status of external. Driver Process L3 Support Understanding
  • Novell Partner Engineering will then evaluate the request and work with you to ensure that the source code is structured correctly to be placed into the partner module area of the SUSE Linux build system.
  • Novell Partner Engineering will process the request internally using the following steps:
    • Packager will be assigned the new bug request.
    • KMP will be built and signed by the assigned packager.
    • KMP structure will be validated by the packager then by the Build Manager.
    • KMP will be delivered by posting it on http://forgeftp.novell.com/driver-process/staging/pub/update/ and/or by sending directly to the partner for testing and validation.
  • Once the KMP has been delivered, please validate the KMP and post the results in the bugzilla so that the KMP can be placed into the correct driver kit.
  • Once the source code has been placed into the build system, the module(s) will be rebuilt with every new kernel release (SLES9) or for every new kABI kernel release (SLES10). Novell Partner Engineering will provide the rebuilt module(s) back to you for validation then update the appropriate kit(s) with the new modules.

© Copyright Micro Focus or one of its affiliates