(Redhat) Linux Important Stuff (81)

8/6/2019 (Redhat) Linux Important Stuff (81)

1/21

Driver Update Program

Jon Masters, Tim Burke

October, 2007 v1.5


2/21

2

Overview

Experience from RHEL2.1, 3, 4

Program objectives

Features / Capabilities Customer benefits

Hardware certification implications

Driver provider benefits

Future possibilities Additional information


3/21

3

Experiences from RHEL2.1, 3, 4

Prior to RHEL5, there was no officially sanctioned, standardized process for

adding 3rd party Linux Kernel Modules to Red Hat Enterprise Linux systems.

Less favorable experiences could include: The kernel module build processes were not always well documented.

There was no standardized, documented, packaging and delivery strategy:

Resulting in each 3rd party driver supplier having a different process.

Resulting in an inconsistent customer experience installing drivers.

Users had to reinstall 3rd party drivers on kernel maintenance errata:

Not necessitated by corresponding changes to the kernel.


4/214

Objectives

Note: This program is an additional feature present in RHEL5. It does not

preclude the use of any alternative kernel packaging or delivery process

used by 3rd parties. Instead, it adds an additional option to those available.

Improve the end customer Linux Kernel Module installation experience by

providing 3rd parties (IHV/OEM/etc.) with a standardized packaging process.

Publish an official, defined set of RHEL5 kernel external stable interfaces.

Implement mechanisms to allow 3rd

party kernel modules to continue to functionacross kernel errata (asynchronous security errata or RHEL5 minor release).


5/215

Features / Capabilities

Published RHEL5 kernel symbol whitelists (per arch and kernel variant):

Published publicly .

Itemizes kernel routines/global variables endorsed for use by 3rd

parties. Collaboratively defined via partner input and Red Hat engineering review.

Functionality subsystem groupings:

Examples: scsi, VM, VFS, networking, block devices, arch specific, etc...

Per subsytem checksum signature of routines and global variables. Ensures matching kernel modules with compatible kernel, in RPM.


6/216

Whitelist construction rationale

RHEL5 kernel is complex, based upon community developed kernel

Contains over 8000 symbols, many not intended for use by external modules.

Whitelists initially formed from known third party and ~3000 standard symbols. Lists reviewed by our kernel engineering team, some symbols removed.

Examples of removed symbols:

tcp_hashinfo and tcp_parse_options functions that our Networking

Maintainers considered to be internal only due to ongoing work in the TCP

networking subsystem. Alternative higher level mechanisms exist.

Infiniband and most Xen symbols rapidly evolving.

SATA mostly low level internal interfaces used between 2 halves in RHEL.


7/217


Driver development tools:

Composed detailed whitepaper with examples

Lead efforts among IHVs, and other Linux distributions to yield commondevelopment practices, community interest and open discussion.

RPM command enhancements to enable representing kernel interface

dependencies as regular Linux package dependencies.

Enables packaging and delivery of kernel modules to be consistent with the

paradigm used in the rest of the distribution. No need to re invent the wheel.

Kernel packaging enhanced to allow it to declare provided subsystem

checksums to validate compatibility. Easy to determine compatibility.

Driver Update Disks now use Driver Update RPMs, in RHEL5.1.


8/218


Modules are built as external RPM packages.

One RPM per type (variant) of RHEL kernel (10 types total).

e.g. kmod ipw3945 for i686, i686xen, x86_64, etc. Build process simple and documented

Standard RPM package (template example available).

Symbol information automatically added to package.

Only build for architectures you use e.g. Don't need to build for s390x if

you're not shipping for mainframe systems.

RPM dependencies track module compatibility

Automatically ensures correct architecture and kernel variant matches

Automatically ensures compatibility of required interfaces is preserved.


9/219



10/2110

Customer benefits

Simplifies customer installation experience:

Utilizes conventional package installation mechanisms.

Install is a single RPM command: rpm ivh kmod ipw3945 1.0 4.7.el5.i686.rpm

Provides a consistent customer installation experience:

vs prior ad hoc procedures, varying from one distributor to the next..

Allows kernel module installations to not be disrupted by kernel errata.

Validates correct pairing of kernel module to kernel variant.

Allows designation of prioritization order of modules.


11/2111


The following affects only official Red Hat certification and support. This

program does not alter any pre existing RHEL certification processes.

Red Hat may itself elect to use this Driver Update Program on a limited basis to

ship new RHEL5 drivers between minor releases:

Potentially for specific driver bug fixes.

For new hardware enablement prior to the next RHEL minor release.

Drivers must meet usual RHEL inclusion criteria (upstream, reviewed, etc). These drivers will be subsumed in the next minor release of RHEL.


12/2112


Inlimitedcircumstances Red Hat may allow hardware certification involving

platforms which require updated drivers.

Making it possible to support and certify somehardware platforms in between

minor releases. (The driver is subsumed in the next minor release.) This practice will only be utilized in limited cases where Red Hat ships the

updated driver package. We intend to initially prove the capability with a small

number (ie 5) per minor release.

Certification will not be granted if 3rd party drivers are required.


13/21

13


14/21

14

Package Delivery

How are RPM packages containing driver modules distributed?

Red Hat may deliver our driver updates via RHEL Supplementary CD RHN

channel.

3rd parties must provide their own Driver Update delivery mechanism, such as:

Their own website.

Or other support delivery mechanism.

Red Hat is not currently planning RHN channels for 3rd party kernel modules

however we are interested in feedback on driver package distribution.

In other words, the Driver Update Program provides the mechanism

needed to build and install Linux Kernel Modules, but not delivery.


15/21

15

Next steps...

It is important to test your own kernel modules can be packaged:

Verify all necessary kernel symbols are on the Red Hat whitelists.

Use the online ABI checker at http://www.driverupdateprogram.com/

File a Red Hat Enterprise Linux 5 Bugzilla entry, against the driver

update program with full outputfull outputfrom the script if it reports missing

symbols. Full output includes kernel versioning information tags.

Produce test packages, following the published documentation (the official

technical whitepaper and examples available from the project website).

Further information is available from your Red Hat Partner Manager:

Including contacts and updated information as it becomes available.

Refer to the driverupdateproject.com website for downloadable material.
http://www.driverupdateprogram.com/http://www.driverupdateprogram.com/


16/21

16

What if you need a symbol not on the whitelists?

The majority of symbols not on the official Red Hat whitelists were purposely

excluded as they have been deemed too low level or volatile to change.

What if I need one of these purposely excluded symbols?

Packaging/Installation will fail due to missing package dependencies.

You are unable to take advantage of the Driver Update Program. You can

continue using your prior kernel module addition approach, at the risk of

symbols not on the whitelist changing, necessitating rebuilds.

Some symbols are absent from the whitelists as we were unaware of their usage.

It is occasionally possible to add these symbols in a RHEL5 minor release:

This is accomplished by creating special new subsystem groupings.

Propose additions via a Feature Request in the Red Hat Bugzilla.


17/21

17

Kernel Tainting

It is common when referring to 3rd party kernel modules to use the term

taint in describing the effect on the Linux kernel, however the term can

have different meanings, depending upon the context in which it is used.

The Linux kernel community describes a kernel as tainted if it uses non GPL

kernel modules or those for which source code is not generally available. This isthe flag that is set in system log files whenever such modules are used.

Red Hat support may also describe a kernel as tainted if it uses kernel modules

not supplied as part of the RHEL5 installation. This means 3 rd party modules. Red

Hat supplied Driver Update Program modules will not taint the user's system and

will be fully supported by the Red Hat support organization whenever required. Systems using 3rd party modules may be supported by Red Hat, depending upon

the existence of Co operative Support Agreements (CSAs), etc. Refer to the

previous support/certification discussion.


18/21

18

Future possibilities

Note: these enhancements to the Driver Update Program are under consideration.

This slide does not constitute commitment.

Short Term (ie, in RHEL5 minor release)

Addition of a small number of new symbols to the kernel symbol whitelists.

Additions or clarifications to developer's whitepaper (based on feedback).

Increased tool automation:

Tools to validate whitelist compliance

Tools to submit whitelist dependency information to Red Hat

Externally accessible whitelist database


19/21

19

Future possibilities

Note: these enhancements to the Driver Update Program are under consideration.

This slide does not constitute commitment.

Longer term (not RHEL5):

Automated detection of hardware and determination of correct driver.

Locate and automatically download third party drivers.

Automatically upgrade drivers as required.

All driven through entirely GUI interface.

Track third party symbol use entirely automatically, report data to Red Hat

using automated systems and allow whitelists to be automatically updated.


20/21

20

References / Additional Information

The project website for the RHEL Driver Update Program:

http://www.driverupdateprogram.com/ The project website for various community efforts:

http://www.kerneldrivers.org/

File technical bugs using our bug tracking system

http://bugzilla.redhat.com/.

Use the driver update program component.
http://www.driverupdateprogram.com/http://www.kerneldrivers.org/http://bugzilla.redhat.com/http://bugzilla.redhat.com/http://www.kerneldrivers.org/http://www.driverupdateprogram.com/


21/21

21

Program Feedback

Technical feedback can be sent to an appropriate engineering contact.

Jon Masters is leading the engineering effort on the

Driver Update Program. He can answer technical questions relating to the

whitepaper and to the implementation of the Driver Update Program.

Additional contacts

Your pre existing Red Hat Partner Manager can supply other details.
mailto:[email protected]:[email protected]

(Redhat) Linux Important Stuff (81)

Documents

Transcript of (Redhat) Linux Important Stuff (81)