Ubuntu Wiki

• Launchpad Entry: kernel-maverick-reducing-dkms-packages-required-for-hardware-enablement

• Created:

• Contributors: colin-king

• Packages affected:

Summary

Aim: To reduce the number of DKMS packages being used in hardware enablement projects.

The aim is to define a clearly define procedure to migrate kernel fixes that land in DKMS packages into the current release kernel as SRU sauce patches and also ultimately into the mainline kernel. Once a fix is in the release kernel then the corresponding fix inside a DKMS package can be removed.

Open for discussion:

1. The process of informing the kernel hardware enablement engineers that a DKMS package has been created

2. The method of tracking DKMS packages with specific bugs

3. How to flag that a fix is now migrated into the kernel via the SRU process and hence that a DKMS package is now redundant

4. Deficiencies in the current process and how to improve them.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.

Rationale

Hardware enablement requires a fast turnaround in identifying and fixing kernel related bugs. However turning a quick fix into a patch that is accepted upstream can take a several weeks or even months depending on the nature of the fix and the speed it can be upstreamed. Getting a patch into the kernel as a SRU sauce patch and through the proposed and released pipeline takes time and cannot meet the fast turnaround time required for hardware enablement.

The current solution is to place hardware enablement patches into DKMS packages. However the fixes need to be passed over to the kernel hardware enablement team and then possible re-worked to get them into the kernel either as a SRU sauce patch and to upstream the code where possible.

Example Scenario

1. An new device has audio enabled using upstream ALSA. A quick fix is to release the fix as an ALSA DKMS package. A bug report is created detailing the bug and the quick fix, where the DKMS package is located and this is then passed to the kernel hardware enablement team to handle. The bug is then investigated at a deeper level and a few line fix is discovered in the Intel HDA driver patch sources. This is then submitted as a fix as a SRU sauce patch to the kernel team where it is ACKd and then passes through the SRU process. Once the kernel is released the DKMS package workaround can be removed.

2. A new device with a new PCI id being enabled and a hardware specific bug is discovered. A workaround is found and a fix is put into a DKMS package. Again, this is reported in a bug and passed over to the kernel hardware enablement team. The bug is discussed with upstream and after several weeks of iteration with the driver maintainer a suitable upstream patch is realized. This is then cherry picked and passed into the kernel via the normal SRU process. Once the kernel is released the DKMS package workaround can be removed.

Assumptions

Design

You can have subsections that better describe specific parts of the issue.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec