DeviceManagerSpec

Differences between revisions 1 and 2
Revision 1 as of 2006-11-10 23:25:32
Size: 1130
Editor: 207
Comment: Small dump of short BOF
Revision 2 as of 2006-11-23 20:32:07
Size: 3839
Editor: 67
Comment: Initial crack at full spec.
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * '''Packages affected''': hal-device-manager  * '''Packages affected''': hal, gnome
Line 11: Line 11:
There is currently no user-friendly way to manage devices, drivers and modules. If a user has to tune (via module params for example) a driver, this has to be done by manually editing files.

The purpose of this spec is to define methods for userspace to handle this better, and to develop a GUI for user control of these methods.
Line 12: Line 16:

With Linux being used more and more by average Joe's and Jane's, requiring them to manually edit files to get a working system is not following the definition of usability that we are aiming for.
Line 15: Line 21:
 * Bubba has two bt878 based audio chipsets in his desktop. He wants one to use the normal Alsa driver, and the other to use the multimedia driver (for use with the Tv capture card that accompanies it). Using the device manager, he sets each device to the proper driver.

 * Bobby Joe buys a new SATA controller for his computer. He finds that the driver included with his version of Ubuntu detects the card, but doesn't work properly with it. He inserts the IHV's driver disk, installs the new driver, and uses the device manager to tell the system to use the new driver instead of the one included with his system.

 * Sally Sue has an old computer, with an ISA card that is supported by a driver in her Ubuntu system. However, the hardware is not well spec'd, which means the driver isn't always correct in how to initialize it. She uses the device manager to set some module parameters for this particular module so it works properly with her card.
Line 16: Line 28:

Basic implementation is to take hal-device-manager and create a new package with it. This is already a familiar interface and available on our desktop. It's written in Python/Glade.

The reason for creating a new package is that hal-device-manager is part of hal, and as such is supposed to be OS independent. The extensive changes needed to handle very Linux-centric functionality justifies the fork.

There may need to be kernel changes in order to accommodate some of the preferred logic.
Line 19: Line 37:
 * Ability to disable a device (using unbind in sysfs).
 * Use udev rules to apply configuration.
 * New PCI ID's forced for drivers.
 * (low prio): Allow user to set params for modules.
 * Allow user to select driver for device in the case of multiple drivers being available. Issues with this, we cannot address.
 * Disabling USB (ehci)2.0.
 * Pseudo drivers.
 * NIC bonding GUI.
 * Some features can be for Google Summer of Code.
 * Functionality required:

   * Detect drivers associated with devices retrieved from hal.
   * Determine list of modules that provide drivers for a specific device.
   * Read meta-data (modinfo) associated with the module for that driver.
   * Allow admin to assign new defaults to these module params, or accept defaults.
   * Ability to disable/enable a device (bind/unbind).
   * Ability to associate a specific driver with a device.
   * For drivers which allow it, enable the ability to force bind a device to a driver (e.g. new_id for PCI devices and drivers).

 * Generic system wide options:

   * Enable/Disable USB2.0 (ehci driver).
   * Driver profiles, to allow rebooting with different configurations?
Line 31: Line 54:
Basic implementation covered in Scope and Design sections.
Line 33: Line 58:
=== Data preservation and migration === Most code will be implemented in the new linux-device-manager package. Other code may be needed in the kernel. The interaction with udev may require some tweaking there as well.
Line 37: Line 62:
== BoF agenda and discussion ==  * The kernel currently has no mechanism to stop from binding a device to an already loaded driver. Upstream suggests unbinding after noticing this, and binding to the preferred driver. This is not ideal, and is the portion that is likely to require kernel changes.

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

There is currently no user-friendly way to manage devices, drivers and modules. If a user has to tune (via module params for example) a driver, this has to be done by manually editing files.

The purpose of this spec is to define methods for userspace to handle this better, and to develop a GUI for user control of these methods.

Rationale

With Linux being used more and more by average Joe's and Jane's, requiring them to manually edit files to get a working system is not following the definition of usability that we are aiming for.

Use cases

  • Bubba has two bt878 based audio chipsets in his desktop. He wants one to use the normal Alsa driver, and the other to use the multimedia driver (for use with the Tv capture card that accompanies it). Using the device manager, he sets each device to the proper driver.
  • Bobby Joe buys a new SATA controller for his computer. He finds that the driver included with his version of Ubuntu detects the card, but doesn't work properly with it. He inserts the IHV's driver disk, installs the new driver, and uses the device manager to tell the system to use the new driver instead of the one included with his system.
  • Sally Sue has an old computer, with an ISA card that is supported by a driver in her Ubuntu system. However, the hardware is not well spec'd, which means the driver isn't always correct in how to initialize it. She uses the device manager to set some module parameters for this particular module so it works properly with her card.

Scope

Basic implementation is to take hal-device-manager and create a new package with it. This is already a familiar interface and available on our desktop. It's written in Python/Glade.

The reason for creating a new package is that hal-device-manager is part of hal, and as such is supposed to be OS independent. The extensive changes needed to handle very Linux-centric functionality justifies the fork.

There may need to be kernel changes in order to accommodate some of the preferred logic.

Design

  • Functionality required:
    • Detect drivers associated with devices retrieved from hal.
    • Determine list of modules that provide drivers for a specific device.
    • Read meta-data (modinfo) associated with the module for that driver.
    • Allow admin to assign new defaults to these module params, or accept defaults.
    • Ability to disable/enable a device (bind/unbind).
    • Ability to associate a specific driver with a device.
    • For drivers which allow it, enable the ability to force bind a device to a driver (e.g. new_id for PCI devices and drivers).
  • Generic system wide options:
    • Enable/Disable USB2.0 (ehci driver).
    • Driver profiles, to allow rebooting with different configurations?

Implementation

Basic implementation covered in Scope and Design sections.

Code

Most code will be implemented in the new linux-device-manager package. Other code may be needed in the kernel. The interaction with udev may require some tweaking there as well.

Unresolved issues

  • The kernel currently has no mechanism to stop from binding a device to an already loaded driver. Upstream suggests unbinding after noticing this, and binding to the preferred driver. This is not ideal, and is the portion that is likely to require kernel changes.


CategorySpec

DeviceManagerSpec (last edited 2008-08-06 16:17:04 by localhost)