OHM - Open Hardware Manager
Executive Summary
attachment:ohm-logo.png |
OHM is a small open source systems daemon which sits above HAL and abstracts out common hardware management tasks such as system wide inhibit action control and controlling heat dissipation on embedded devices. OHM is built using a lightweight plugin architecture. Each plugin can query data from HAL or execute methods on HAL devices and expose preferences for session programs to modify. OHM is product and vendor neutral and is currently being developed by a small team of developers. |
OHM : Resistance is futile
Contact Information
Please join the OHM Development [http://lists.freedesktop.org/mailman/listinfo/ohm-devel Mailing List] or just send email to ohm-devel@lists.freedesktop.org
News
We gave a [http://www.fosdem.org/2007/schedule/events/embedded_open_hardware_manager talk at FOSDEM] and got some great feedback, thanks. Grab the [attachment:ohm-pres-fosdem.pdf slides] if you missed it.
Use Cases
See UseCases
OHM inputs and outputs
See InputOutputs
OHM plugins and features
Overall Description
OHM is a small open source systems daemon which sits above HAL and abstracts out common hardware management tasks such as:
- System wide power management statistics (for instance calculating hysteresis of battery curves).
- Managing system wide inhibit actions (using locks on HAL), for instance system firmware updating.
- Controlling heat dissipation on embedded and PC devices.
OHM is built using a plugin architecture with a low-overhead messaging structure. This gives a very configurable base system that can be configured in many different ways. Each plugin can query data from HAL or execute methods on HAL devices and expose preferences interfaces for session-space to use.
attachment:ohm-structure.png
OHM is LGPL licensed to allow proprietary licensed plug-ins to be used where absolutely required. It is also uses the minimum of memory and processor requirement to fulfill the task. This makes it suitable for use on the latest smart-phones, the OLPC device or any other embedded products such as set top boxes.
OHM comprises:
- The ohmd system daemon which co-ordinates the rules and acts as a keystore for multiple users.
- The interface specification which outlines core ohmd functionality.
- A method for plugins to request notification when keys change, for example when the system AC state is changed.
- The test suite which tests functionality.
OHM is very suitable for embedded devices that need to manage power, heat and other critical tasks early in the boot sequence. Using HAL, it provides an abstract method for all plugins to be written in a generic way, not tied to the specific implementation of the device.
What OHM is not:
- A power saving daemon. It is not doing power saving specifically, it is just doing device specific rules that manage power and heat dissipation and other hardware specific stuff.
- An abstraction of HAL. HAL acts as the input and the output of OHM, and OHM enforces policy for HAL.
- A huge daemon with lots of dependencies.
- API or ABI stable. Expect the ABI and API to change on a regular basis until we ship 1.0.0.
- Targeted to a particular architecture or platform.
- Produced by any one vendor. There are many contributors helping to get this done.
Why not do everything in a session daemon?:
- Sometimes we need to start very early in the boot sequence.
- We don't want to die if X dies.
- On a server with 100 logged in users we don't want an instance for each user.
- We need to apply policy at boot-up or before X starts.
Using HAL
HAL has traditionally been seen too heavyweight for use on an embedded device. While this was once true, there have been very many developers working on adding conditional compilation to parts of HAL, and to reduce memory usage. This can be seen with the startup speed of 0.5.9 being 40% than of 0.5.8. Context switching has been reduced, and memory pressure on coldplug has been reduced for devices with a small amount of devices. It is expected that hald will start in the few hundred millisecond range and consume less than half a megabyte of RAM at coldplug.
Using HAL allows us to use a common framework for hardware management, which means plugins designed for one architecture or chip will work on any other system. Working together is the best way to get high quality, maintainable code rather than all the hacky systems we have now.
OHM Core Values
The OHM daemon with all management modules suitable for the platform loaded should:
- not have a binary size of over 200k in size
- start in less than 200ms on 100MHz ARM
- use less than 200k of private memory
- be platform neutral, i.e. use HAL wherever possible
- be plug-able so proprietary code can be used where required.
- be secure so system policy cannot be changed
- not rely on any odd toolkits or high level programming frameworks
- be efficient enough to do complex rule processing with minimum CPU load
- be bug free and have no memory leaks so the daemon will never crash
- be an open and supported project, rather than a quick custom hack
Dependencies
OHM is lightweight.
- GLib 2.10.0 (required)
- DBUS 0.70 (required)
- HAL 0.5.8 (required)
PolicyKit (optional)
DBUS Session Access
attachment:ohm-dbus-access.png
Frequently Asked Questions
How does OHM fit in with other session policy agents?
OHM is initially targeted to embedded devices rather than desktop frameworks with multiple logged in users.
Why not just do a specific device hack for all the different embedded hardware?
As lots of manufacturers are hacking the same thing, over and over. We need some sort of central common framework.
So it's LGPL... does that mean some of the code is closed source?
No. It just means that code protected by intellectual property laws can be used by manufacturers, but OHM works really well without any non-free stuff.
Can I install the latest stable code?
No, at the moment it is proof of concept and only really useful for hard core developers. Feel free to look at the code and spec and give feedback, but please don't expect anything to actually work well yet.
What is the release date plan for OHM?
Currently we are aiming at a 2 month stakeholder involvement prototype period, and then 10 months of code polishing and maturing. That gives an approximate release date of January 2008
Do you need to use system GConf for the system preferences?
No. We plan to use a flat file for minimum dependencies and speed, and also each file is going to be really small and simple.
Is OHM using XML to define the policy rules?
No, as we don't need to. We are using compiled logic for speed and low dependencies.
Why include a session layer for embedded appliances?
Devices can omit the session layer, and talk directly to OHM on the system bus if user preferences are not required.
Should all the keys be exposed in a single hash table?
Plugins have to query to state of other plugins. To store the state of each plugin in itself, we would have to do inter-plugin methods, and expose the SetKey and GetKey methods on every plugin. We can also optimise the global keystore for a fast hash lookup to avoid scalability problems. This also makes it easier to code as the keystore can just be a compiled .o object rather than a shared library.
Will OHM break if I restart messagebus or hald?
Yes. Please restart your device if you want to restart these daemons.
Can I execute shell scripts from OHM on an event?
Well you can, but you really don't want to. Executing a shell takes a long time on an embedded system, and OHM provides (deliberately) no methods to easily launch scripts. A critical design feature of ohmd is that it is fast and lightweight, with policy written in compiled modules, and so writing stuff in shell is very discouraged.