HardwareActivation

Differences between revisions 11 and 12
Revision 11 as of 2005-11-01 18:05:55
Size: 1754
Editor: 209
Comment: add udev
Revision 12 as of 2005-11-02 18:07:38
Size: 6797
Editor: 209
Comment: draft this spec
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
Our current boot process has parts that rely on certain pieces of hardware being available, such as networking, bluetooth, sound and printers. We should instead provide a means to activate these when the hardware is detected rather than assuming it exists, and move the startup scripts into activation scripts instead.
Once hardware has been detected it needs to be configured and activated, for example networking needs to be enabled on manually configured network cards; bluetooth devices need to be associated with the bluez stack; sound cards may need initialisation and mixer settings uploading, etc.

We should ensure that this activation during the boot sequence is reliable, and performed after the device has been detected. We also need to ensure that devices are correctly activated when plugged in after the boot sequence has been completed, for example hot-pluggable network devices.
Line 13: Line 16:
Solve the problem that coldplugging needs to complete before carrying on. This completing must be based on kernel events. Race conditions during the boot sequence, where detection and activation are happening side-by-side, lead to unreliable hardware and often requiring manual reconfiguration after startup. This leads to user frustration and unhappiness.
Line 15: Line 18:
Specifically, this spec does NOT cover activating various services based on kernel events. This is too invasive for the Dapper release. Hardware not being activated when plugged in leads the user to believe it just doesn't work, when it may simply require a manual activation step which shouldbe done automatically.
Line 19: Line 22:
 * Colin's laptop sound-card always starts with the volume muted unless otherwise configured. ALSA can take care of restoring the previous mixer settings, but needs to be run after the sound card module has been loaded.

 * Jeff's server contains two network cards that he has manually configured. This manual configuration needs to take place after the modules have been loaded otherwise it will fail.

 * Martin's laptop has no internal wireless card and he instead uses a USB device that he plugs in after the system has booted. He has a manual configuration for the network device, and networking should be brought up automatically.
Line 22: Line 30:
Devices that are detected by initial coldplugging for which the activation takes place later in the boot sequence are within the scope of this specification.

Hotpluggable network devices for which there is a manual configuration in `/etc/network/interfaces` are also within the scope of this specification. Those which are not manually configured may be automatically configured under the NetworkMagic specification instead.

Other kinds of hotpluggable devices are out of scope of this specification for the `dapper` time-frame as we need to keep the changes as non-invasive as possible. For `dapper+1` we can consider moving activation out of the main boot sequence and into a more event-drivel model, within this release we will rely on the existing systems (`alsa`, `bluez`, etc.) handling
Line 24: Line 38:
New Initramfs: Cold-plugging of hardware during the initial boot sequence will be done in a synchronous manner, blocking the boot sequence until it has finished. This ensures that any activation scripts further down will be able to rely on a system largely without parallel events.
Line 26: Line 40:
o Create base device nodes
o Start udevd
o Load modules from /etc/mkinitramfs/modules (and other force_load calls)
This is not completely true with, for example, the USB, SCSI and Bluetooth subsystems which may discover devices some time after the bus initialisation has been completed; however support for those devices is deferred to `dapper+1` where we can make the move invasive changes necessary.
Line 30: Line 42:
** Note: without udevstart, something needs to correct permissions, or we need to provide the rules. Synchronosity doesn't come for free; cold-plugging is performed by userspace writing to `uevent` files in the `/sys` filesystem which cause the kernel to re-issue the event across the uevent netlink socket. This event is then captured and queued by the udevd daemon and processed at the earliest opportunity.
Line 32: Line 44:
o Walk the sysfs tree for harddrive devices and tickle uevents for those
o Walk the ide, scsi, and i2o busses
o Attempt hibernate recovery
o Walk the pci sysfs tree for usb controllers
In order to ensure the udevd daemon has finished processing the event, we need to know what events it is currently procesing. To find this out we will add support for a "scoreboard" file that will list all of the events in the queue, one `DEVPATH` per line. When the queue is empty, this file will be unlinked.
Line 37: Line 46:
User-space can then request uevents and simply wait for `udevd` to finish processing them by checking for the existance of this file.
Line 40: Line 50:
Update to UDEV 071.
Add scoreboard to udevd.
Track scoreboard status during coldplug by looking for existance of /dev/.udev_scoreboard.
We create the file initially, and udev will unlink it.
Implementation relies on various parts of the UdevRoadmap specification, those parts that affect this specification in particular are defined below.
Line 47: Line 54:
=== Data preservation and migration === `udevd` will be modified such that when a new event is queued, the `/dev/.udev_scoreboard` file will be created when necessary and a line containing the `DEVPATH` of the event appended. When an event is removed from the queue, after processing has completed, the line will be removed from the file and if the queue is empty, the file is unlinked.
Line 49: Line 56:
== Outstanding issues == A new `udevplug` tool will be implemented to walk specified parts of the `/sys` filesystem and request events by writing to any `uevent` file it finds. Before doing this it will wait for the scoreboard file to no longer exist, and after sending the requests, again wait for the file to no longer exist. In order to ensure that events aren't confused, it will perform this waiting by watching `inotify` events rather than using inherently racey `stat()` calls.
Line 51: Line 58:
== BoF agenda and discussion == To reduce overhead for maintaining the scoreboard file, it will be placed under `/dev` and modified by using `mmap()` so that the overhead is simply that of directly modifying a page of memory.

=== Use of udevplug ===

The `initramfs` scripts will be modified to start `udevd` and then use this tool to create the base device nodes and walk the IDE, SCSI, i2o and USB buses to activate sufficient pieces of hardware to enter real user-space.

Cold-plugging in user-space will also use this tool and will request all uevents, including those that may have been already requested in the `initramfs`. This is necessary to assign permissions to the created devices, and to process any rules not present in the `initramfs`.

The second will ensure basic modules and support are available, such as the `psmouse`

=== Policy ===

In order to ensure reliable activation, the following policy for `udev` rules will be established.

 * Names and permissions must be assigned in different rules files, so that the names can be applied in `initramfs` where it is not possible to assign permissions.

 * No `RUN` rule may depend on the `/usr` filesystem being mounted, whether directly by running a program in it, or indirectly by running a program that does.

 * Programs in `RUN` rules must function correctly if called multiple times. They may choose to do nothing if the configuration does not require changing.

 * Rules may communicate with daemons located under `/usr` (for example, `hal`) by using socket rules. Those daemons must perform their own discovery of existing devices when they start.

Summary

Once hardware has been detected it needs to be configured and activated, for example networking needs to be enabled on manually configured network cards; bluetooth devices need to be associated with the bluez stack; sound cards may need initialisation and mixer settings uploading, etc.

We should ensure that this activation during the boot sequence is reliable, and performed after the device has been detected. We also need to ensure that devices are correctly activated when plugged in after the boot sequence has been completed, for example hot-pluggable network devices.

Rationale

Race conditions during the boot sequence, where detection and activation are happening side-by-side, lead to unreliable hardware and often requiring manual reconfiguration after startup. This leads to user frustration and unhappiness.

Hardware not being activated when plugged in leads the user to believe it just doesn't work, when it may simply require a manual activation step which shouldbe done automatically.

Use cases

  • Colin's laptop sound-card always starts with the volume muted unless otherwise configured. ALSA can take care of restoring the previous mixer settings, but needs to be run after the sound card module has been loaded.
  • Jeff's server contains two network cards that he has manually configured. This manual configuration needs to take place after the modules have been loaded otherwise it will fail.
  • Martin's laptop has no internal wireless card and he instead uses a USB device that he plugs in after the system has booted. He has a manual configuration for the network device, and networking should be brought up automatically.

Scope

Devices that are detected by initial coldplugging for which the activation takes place later in the boot sequence are within the scope of this specification.

Hotpluggable network devices for which there is a manual configuration in /etc/network/interfaces are also within the scope of this specification. Those which are not manually configured may be automatically configured under the NetworkMagic specification instead.

Other kinds of hotpluggable devices are out of scope of this specification for the dapper time-frame as we need to keep the changes as non-invasive as possible. For dapper+1 we can consider moving activation out of the main boot sequence and into a more event-drivel model, within this release we will rely on the existing systems (alsa, bluez, etc.) handling

Design

Cold-plugging of hardware during the initial boot sequence will be done in a synchronous manner, blocking the boot sequence until it has finished. This ensures that any activation scripts further down will be able to rely on a system largely without parallel events.

This is not completely true with, for example, the USB, SCSI and Bluetooth subsystems which may discover devices some time after the bus initialisation has been completed; however support for those devices is deferred to dapper+1 where we can make the move invasive changes necessary.

Synchronosity doesn't come for free; cold-plugging is performed by userspace writing to uevent files in the /sys filesystem which cause the kernel to re-issue the event across the uevent netlink socket. This event is then captured and queued by the udevd daemon and processed at the earliest opportunity.

In order to ensure the udevd daemon has finished processing the event, we need to know what events it is currently procesing. To find this out we will add support for a "scoreboard" file that will list all of the events in the queue, one DEVPATH per line. When the queue is empty, this file will be unlinked.

User-space can then request uevents and simply wait for udevd to finish processing them by checking for the existance of this file.

Implementation

Implementation relies on various parts of the UdevRoadmap specification, those parts that affect this specification in particular are defined below.

Code

udevd will be modified such that when a new event is queued, the /dev/.udev_scoreboard file will be created when necessary and a line containing the DEVPATH of the event appended. When an event is removed from the queue, after processing has completed, the line will be removed from the file and if the queue is empty, the file is unlinked.

A new udevplug tool will be implemented to walk specified parts of the /sys filesystem and request events by writing to any uevent file it finds. Before doing this it will wait for the scoreboard file to no longer exist, and after sending the requests, again wait for the file to no longer exist. In order to ensure that events aren't confused, it will perform this waiting by watching inotify events rather than using inherently racey stat() calls.

To reduce overhead for maintaining the scoreboard file, it will be placed under /dev and modified by using mmap() so that the overhead is simply that of directly modifying a page of memory.

Use of udevplug

The initramfs scripts will be modified to start udevd and then use this tool to create the base device nodes and walk the IDE, SCSI, i2o and USB buses to activate sufficient pieces of hardware to enter real user-space.

Cold-plugging in user-space will also use this tool and will request all uevents, including those that may have been already requested in the initramfs. This is necessary to assign permissions to the created devices, and to process any rules not present in the initramfs.

The second will ensure basic modules and support are available, such as the psmouse

Policy

In order to ensure reliable activation, the following policy for udev rules will be established.

  • Names and permissions must be assigned in different rules files, so that the names can be applied in initramfs where it is not possible to assign permissions.

  • No RUN rule may depend on the /usr filesystem being mounted, whether directly by running a program in it, or indirectly by running a program that does.

  • Programs in RUN rules must function correctly if called multiple times. They may choose to do nothing if the configuration does not require changing.

  • Rules may communicate with daemons located under /usr (for example, hal) by using socket rules. Those daemons must perform their own discovery of existing devices when they start.

HardwareActivation (last edited 2008-08-06 16:36:55 by localhost)