ARMNattyUserlandSubarchDetection

Summary

Currently, there is no standardized mechanism in userland to determine which specific subarchitecture we are on, and at least three different and unique implications of said detections. This spec moves towards moving a standardized detection method into the base installer, usable by any script.

Release Note

Ubuntu now provides, for packages that require it, a standardized method of detecting the subarchitecture at runtime. Subarchitectures are variants of a primary architecture, such as powerpc+ps3, or armel+omap.

Rationale

As it currently stands, there are three independent implementations of subarch detection that are independent of each other; two in flash-kernel (specifically: flash-kernel-installer and flash-kernel), plus additional architecture detection code in libdebian-installer (in C). These detection methods vary in which boards they detect, and sometimes in the specific detection methods used. This also increases the number of changes that has to be made on each board we enable. By decreasing the code-duplication, the enablement process is streamlined, there is less chance of errant behavior on new boards, and less of a maintenance nightmare.

User stories

  • Alpha is an Ubuntu packager, and wants to provide a warning that their package only works on armel+omap4, and specifically wants to disable an upstart boot script if the subarchitecture is off.
  • Beta is a vendor who wishes to provide in-archive support for their specific board. Once in place, the board will automatically work on the generic support already built into subarch detection, and simply needs a whitelist entry to turn off the dire warnings vs. having to edit 4-7 packages to add their new board even if it is built around a supported SoC.
  • Delta is a vendor who provides acceleration drivers for a specific SoC, and wishes to cause a warning/error to occur when installing on an incompatible subarch, and to prevent their runtime scripts from executing, which are bound to error out, load an incompatible kernel module, or even crash. Delta also doesn't have to reinvent the wheel again and write new detection code, thus increasing the cruft and bloat of their packages.

Assumptions

  • libd-i is the best place for the subarch code
  • If subarch code is refactored, there will be no objection from Debian (should the change need to be pushed upstream).

Design

The design of this spec overlaps with Improved ARM subarch support, please see that https://wiki.ubuntu.com/Specs/ARM/ImprovedSubarchitectureDetection for information on how the actual detection works.

I'm generally interested in simply moving the pre-existing archdetect binary into userland, and having it part of ubuntu-standard (possibly ubuntu-minimal?); it may also be a good idea to refactor the libd-i subarch code into an independent libsubarch-detection (or similar) micro library. This can be done without an ABI break if we are careful.

Implementation

The debian-installer userland has a special tool called archdetect which spits out a string with the architecture and subarch detected (such as "armel/dove". This tool links against libdebian-installer (which is available in deb and udeb versions). It is also present in live images as part of ubiquity. Ideally, we should add a new package to the hw-detect source package to create a standard deb which should then be seeded in the natty platform seed.

Once archdetect is present in the standard userland, tools that do per-subarch specific actions should call archdetect to determine their subarch instead of relying on the patchwork of detection methods scattered across multiple packages; if per-board specific action is required, then that should be done after using archdetect to determine the specific subarch. Known packages that will need modification: flash-kernel, flash-kernel-installer, ubiquity, base-installer(?), others(?).

UI Changes

N/A. Changes are below a usable visible level.

Code Changes

hw-detect:

  • Creation of new deb to put archdetect in a normal deb
  • Possibly add a --help to archdetect

flash-kernel/flash-kernel-installer:

  • Migration to archdetect

base-installer:

  • Already uses archdetect partially.

jasper:

  • Post-processing for each SoC (currently only omap and omap4)

ubiquity:

  • No migration, already uses archdetect

Subarchitecture specific packages:

  • None currently in archive, though some will land in archive in natty. These should grow subarchitecture specific checks to insure proper warnings/sane behavior.

Migration

No migration, old code is only used during installation. There is some per-board/per-SoC specific code in /etc/flash-kernel.conf; care must be taken when new code is written to use the pre-existing variable names, and augment or convert what's there.

Test/Demo Plan

Test all currently supported boards to confirm that they are still properly detected. Installer testing at milestones will also confirm that installer-based modifications should also be fully tested, including upgrades from maverick->natty.

Unresolved issues

  • Maybe a standardized way to determine the specific board we're on? (is this even useful enough to care about?)

BoF agenda and discussion

Things to discuss:

  • Packages that will benefit from this
  • Best approach to moving archdetect
  • Is using libd-i directly the best method, or should we refactor the subarch code into its own library

Notes: 

purpose:
    need to sort tool (ubiquity, flash-kernel, base-installer, libdebian-installer).

"archdetect" is alnreeady used, but we can sort naming later

colin agrees with general strategy and suspects the debian-boot team wouldn't block

provides use-case for imoproved subarch support code block in Debian

can cut redundant code and allows easily extensible framework

simplifies board enablement

new archdetect.deb from source as archdetect.udeb

libdebian-installer (28K) becomes installed in all environments

libdebian-installer extra contains link list code and Release parser

most of the changes are in libdebian-installer

ACTION: Colin to determine naming

ACTION: Colin to deploy as userspace tool

ACTION: Michael to clean up flash-kernel

base-installer needs no changes

ACTION: Colin to handle trivial packaging changes in ubiquity

ACTION: Michael to investigate kernel postinst scripts

ACTION: Emmet to prepare best-practice examples for use in maintainer scripts

intel-microcode is an example of a package that fails awkwardly because of lack of information (not fixed by this spec, but sample for justification)

image build tools should handle special cases, rather than using in-package hooks.  mandb is a handy example, using debconf to determine this rather runtime detection

ACTION: Michael to ensure build tools have a means to declare environment

ACTION: Colin to seed new package

CategorySpec

Specs/ARMNattyUserlandSubarchDetection (last edited 2010-11-17 15:30:46 by 82-69-40-219)