UbuntuWiki:UnsupportedKernelModules

来自Ubuntu中文
Oneleaf留言 | 贡献2007年5月15日 (二) 05:09的版本 (New page: {{From|https://wiki.ubuntu.com/UnsupportedKernelModules}} {{Languages|UbuntuWiki:UnsupportedKernelModules}} ''Please check the status of this specification in Launchpad before editing it....)
(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳到导航跳到搜索

{{#ifexist: :UbuntuWiki:UnsupportedKernelModules/zh | | {{#ifexist: UbuntuWiki:UnsupportedKernelModules/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UnsupportedKernelModules|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UnsupportedKernelModules|1|-1|}} | zh | | }}


Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Not all kernel modules that we build need to be fully supported. It is desirable to keep providing as many modules as possible, while limiting the among of coverage the kernel team needs to worry about.

Rationale

The Linux philosophy is that all modules are best colocated in the kernel. This way, they can be protected against API and ABI breakage over security updates and can be maintained by the community if the driver developer runs out of time, finds a significant other, or discontinues support for a product.

In Ubuntu, we've tried to enable as many modules as possible in our kernel builds. This is important for a couple of reasons:

  • According to DapperStandardsBase, we do not consider systems with a custom kernel to still be "Ubuntu"
  • Providing the modules to people is a nice courtesy.

However, this increases the burden for the kernel team and commercial support teams but providing unlimited support for features in the kernel.

Use cases

  • The kernel team does not have a test environment for debugging NCP over Appletalk. They cannot support this configuration. Appletalk and NCP are so rare now, that bugs are unlikely to be triaged and fixed as a priority and this should be clearly stated.

Scope

The kernel package and packages in main will have to be lined up to make sure that depended on modules aren't marked as unsupported.

Design

There are two possibilities for the packaging:

  • Put the extra modules in a package in universe.
  • Create a kernel-modules-unsupported package that's in main, but depended on by the main kernel package. This might address an Unresolved issue, but potentially hides the fact that modules aren't supported.

Also we can consider marking the modules as tainted in some way so that it's clear that there are unsupported modules in the kernel.

Implementation

Code

Data preservation and migration

Unresolved issues

  • Updating to a the new distro could result in some needed modules not being present if they're no longer supported.

I'm not sure how this is a different case than dropping other packages from main, with the advantage that at least with this transition, they can run the old kernel until they've switched to a supported configuration - JeffBailey

BoF agenda and discussion