Requesting Driver-level Product Enablement

Overview

When partners wish to provide their kernel-space products in a manner integrated with the SLES installation and update utilities, they need driver-level product enablement.

Requesting driver-level product enablement can also be described as requesting a driver kit. Requesting a driver kit is the preferred entry point into the Partner Linux Driver Process. The following sections describe how to request a driver kit from Novell. Partners may also choose to create their own driver kits, as detailed in Driver Kit Do-It-Yourself.

Please note that driver kits (as defined here) are only for SLES/SLED 10. Partners who wish to provide PLDP drivers for SLES 9 should request individual kernel module packages (KMPs) as detailed on Requesting a KMP.

Definitions

Please see Driver Process Terminology.

Rationale - i.e., "Why not simply hand out the driver packages (KMPs)?"

Simply handing out KMPs may make customers' systems work now, but it will not ensure that their systems continue to work in the future. Providing driver kits (rather than just drivers) will ensure long-term success by allowing partners and Novell to:

push updates for KMP bugs to the customer

Enterprise Linux customers expect proactive maintenance updates. Individual per-system distribution channels allow very granular, per-system type maintenance, giving customers the maintenance they expect while containing retesting efforts to exactly the systems that need the update.

manage driver version dependencies based on contexts

products are released one after the other, not simultanously, so they usually have been tested with different snapshots in time of the linux drivers. In many enterprise scenarios even the same chipset release will get a different driver, depending e.g. on the attached storage switch or storage system. Driver kits ease distribution and selection of the right driver versions to different systems and contexts: they wrap exactly the drivers for that specific certified usage context.

flexibly integrate with YaST mechanisms to select hardware-related packages

In theory, drivers can be built and restricted to fit only one very specific hardware type. If an older driver shows problems, Novell's customers for testing purposes prefer the flexibility to use a newer driver without needing a rebuild. So the drivers for customer felxibility should overlap in the pciids they support. The driver kit then gives the context which of the many possible drivers to use: the customer will attach each system only to the kits for that specific system.

provide customers with smooth transitions to new kernels (e.g., Service Packs)

wrapping the driver in a driver kit allows the system management software to migrate the driver alongside the base product. the KMP itself does not provide the necessary context information.

Things to Consider before Requesting a Driver Kit

Is there a need to provide an online update site? I.e., will the drivers in the kit ever need to be updated on the customers' systems?
Will the online update site be hosted at Novell (GPL drivers only) or at the partner site?
What types of installation media will be needed? Which drivers will be needed during the SLES installation and thus require Driver Update Disks (DUDs)? Overall, what will be the general process that a customer will use to install the drivers in this driver kit?
What modifications (e.g., documentation, etc.) will need to be made to the kit before providing it to customers?
How will customers be informed of the existence of this driver kit? Novell will provide a document on its support site; will additional information be provided on the partner site?

How to Request a Driver Kit

Create a new bug request at https://bugzilla.novell.com (Novell PartnerNet login required)
- Classification should be "Partner Linux Drivers"
- Product should be "Partner Linux Drivers - Code 9" or "Partner Linux Drivers - Code 10"
- Component should be "KMP Distribution"
- There needs to be a "Context" which this driver kit applies to. This is typically a product model or series. "Vendor-Context" should be unique.
- Description should include the following:

         Vendor:  (Example:  FSC)          
         Context:  (Example:  "Celsius-W360", or "Primergy")          
         Target OS Version:  (Example:  SLES10 SP1)           
         Repository location:  (Novell / Partner / No update site needed)            
      
         List of KMPs that should be in the kit:               
          (Example: intel-e1000-7.6.5)               
          (Example: fsc-megaraid_sas-00.00.03.12)                     


               ...

Note: If the individual KMP do not yet exist, Novell will work with the appropriate partner to create the KMP request bugzillas and build the drivers.

Note: Unless otherwise specified driver kit repository name will be <vendor>-<context>. ISO image name will be <vendor>-<context>-<target OS version>.iso

After the Driver Kit Request is Submitted

Novell Partner Engineering will review the driver kit request and will file the necessary KMP bug requests to obtain builds of the drivers in the kit. Novell Partner Engineering will then gather the necessary KMPs, build the installation media and the repository structure for the online update site, and provide the driver kit back to the requestor. After the kit has been approved by the requestor/partner, Novell will place the repository on its online update site (if requested) and inform Customer Support about the kit.

Examples of Novell published driver kits: