Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======kmp_distribution_installation_and_status_check======

Once backported drivers have been [[:driver-backport:kmp_packaging_and_build|built into packages]], these packages need to be distributed to the "sysadmin" so installation works as easy as possible for him.

While the Linux user doesn't care too much about different installation methods accross distributions and there is some happy coopetition in this, the hardware vendor techsupport would strongly prefer to have distro agnostic diagnostic tools to check the driver status.

Also, the system and component vendors would prefer to have some distro agnostic base format to maintain their KMPs in, that's why they currently have their distro agnostic own support packs, pro packs and update express packs.

And the distros prefer to have reliable hardware agnostic methods to autodetect the hardware that actually is in the system and are looking for a good way to autoconfigure the right drivers from that information.
=====Contents=====

  * [[https://www.linuxfoundation.org/#Scope|1 Scope]]
  * [[https://www.linuxfoundation.org/#How_is_it_currently_done.3F|2 How is it currently done?]]
    * [[https://www.linuxfoundation.org/#Dell|2.1 Dell]]
    * [[https://www.linuxfoundation.org/#Fujitsu_Siemens_Computers|2.2 Fujitsu Siemens Computers]]
    * [[https://www.linuxfoundation.org/#HP|2.3 HP]]
    * [[https://www.linuxfoundation.org/#IBM|2.4 IBM]]
    * [[https://www.linuxfoundation.org/#Red_Hat|2.5 Red Hat]]
    * [[https://www.linuxfoundation.org/#SUSE|2.6 SUSE]]
    * [[https://www.linuxfoundation.org/#ubuntu|2.7 ubuntu]]
  * [[https://www.linuxfoundation.org/#possible_common_solutions|3 possible common solutions]]
  * [[https://www.linuxfoundation.org/#who_is_working_on_this|4 who is working on this]]

=====  Scope =====

  *  wrapping KMPs into a bundle
  *  providing the bundle to customers
  *  degree and method of automation in 'selecting the right driver'
  *  check wether 'the right drivers' are on this system
=====  How is it currently done? =====
====  Dell ====
====  Fujitsu Siemens Computers ====
====  HP ====
====  IBM ====
====  Red Hat ====
====  SUSE ====
====  ubuntu ====

Latest stable release of Ubuntu ships a tool called
"restricted-manager" (see [[https://launchpad.net/restricted-manager|project]] and [[http://people.ubuntu.com/~pitti/screenshots/restricted-manager/|some screenshots]]).

This provides (Gnome/KDE) desktop integration and an UI for installing
non-free hardware drivers, such as the nVidia/ATi graphics drivers, or
the Broadcom bcm43xx firmware. It checks for newly available drivers,
notifies the users about them, and provides single-click install. This
is just HW detection and UI, though, it relies on the normal
distribution packaging tools.

r-m is pretty Ubuntu specific, though. Currently I am working on a
generalization and rewrite so that it will become an upstream project
(see the [[https://wiki.ubuntu.com/DesktopTeam/Specs/RestrictedManagerRewrite|specification]]).  I recently discussed this with Jon Masters from RedHat, who had similar ideas, so we agreed on a design
which would make r-m suitable for all Linux distributions, in the
sense of setting up a central driver -> package mapping, and offering
an UI mode for managing free third-party drivers, too.

The [[http://codebrowse.launchpad.net/~pitti/+junk/r-m-upstream/files|rewrite]] has gotten quite far now. I have an abstract and distro/UI agnostic backend with full test coverage, a GTK
implementation (KDE is in the works by a contributor), and an
implementation of the OSLib class (which abstracts the distro specific
details such as package queries/installation) [[http://codebrowse.launchpad.net/~pitti/+junk/r-m-ubuntu/files|for Ubuntu]], as well as some working example custom handlers (for the proprietary nVidia drivers ATM).

The biggest problem that I have with it ATM is that it does not have a
proper name yet. It's currently called 'driver-manager' but that might
be too generic to be palatable for distros. Some random (and not
utterly appealing IMHO) ideas were 'driver monkey', 'driverkit'
(SCNR), and 'Threepio' (a protocol druid which interacts with humans
fits the idea quite nicely, doesn't it?) I greatly appreciate
suggestions here, so that I can create a real project page on
Launchpad and fix the code to have the final directories, etc.

Now I need to port the smaller features of restricted-manager, such as
the notifications, firmware installation dialogs, etc. This should not
take too long any more.

To answer the specific points above:

  *  wrapping KMPs into a bundle

That should be done with normal packaging, i. e. ship the KMPs into
.rpm/.debs and put them into a distro repository. There's no point in
reinventing the wheel, distribution channels, package authentication,
certification, etc.

  *  providing the bundle to customers

That's done with the UI described below. In Ubuntu we only use the
tool for non-free drivers, though, since we believe we should not
promote third-party free drivers. However, the rewritten
driver-manager has all three modes (non-free only, free only, any).

Since d-m has an abstract UI, it's easy to provide a CLI for servers,
too.

  *  degree and method of automation in 'selecting the right driver'
  *  check wether 'the right drivers' are on this system

d-m does HW detection by scanning /sys and mapping the modaliases to
an instance of 'Handler'. This is a Python class which provides the
glue for handling a particular driver and enabling/disabling it in the
system. For most drivers this will be an instance of a standard
'kernel module' handler, but there are modules where more work is
required (like modifying xorg.conf for X.org graphics drivers) or
which are not kernel modules (like winmodem and printer drivers).

Currently the mapping to kernel modules is done locally with modalias
files, but Jon and I are designing a central database where d-m can
query for additional or updated drivers online.

Since every distro needs to do certification checking and QA, the
driver db entries are per-distro and per-release. Thus every distro
can put the prefered driver there. d-m just presents the first
matching driver which is available, to avoid confusing the user with
alternatives. Thus distros can provide an ordered list of possible
driver, sorted by preference.
=====  possible common solutions =====

driver-manager is explicitly designed to be a common solution for distributions.
=====  who is working on this =====

  *  [[https://launchpad.net/~pitti|Martin Pitt]]: driver-manager implementation
  *  Jon Masters: [[http://www.drivertool.org|http://www.drivertool.org]] shared driver DB
Wiki

User Tools

Site Tools

Page Tools
