Revision as of 21:29, 2 October 2013

Contents

Description

This project intends to clean up, consolidate and improve the managed devices of the Linux kernel
(devm_* functions) and make their usage more consistent. It should also enable
removing boilerplate code and strings in drivers.

Managed devices have a great potential to make writing device drivers easier
and less error prone. The basic mechanisms are there, yet using these
mechanisms has gone a bit wild and there is no maintainer to keep an eye on it.
This project aims to improve the situation by:

Fix the callers

Fix the kernel tree to clearly represent the best-practices in using devm functions.
This will usually remove code from the kernel.

Cleaning up

Remove superfluous or too shim devm-functions to have a well-known basic set of
functions. This will remove code from the kernel.

Consolidate

On top of these functions, add convenience functions which combine typical
procedures into seperate functions. An already existing example is
devm_ioremap_resource() which does devm_request_mem_region() and
devm_ioremap{_nocache} with proper error checking and giving proper error
messages. This will remove code and *lots* of inconsistent error strings from
the kernel. Also, most devm functions themselves use a similar pattern.
Refactoring might be worth in that area, too.

Remove subtle issues

There are some devm functions missing. So for some subsystems, resource
allocation is additionally done by hand. This can cause subtle bugs, especially
in exit paths, since manually allocated resources might be not available
anymore when devm allocated resource would still need them. Adding those
functions will get things right. Also, the already existing action mechanism
might be used to do things on removal which are otherwise often forgotten.

The huge bonus of such a cleaned up devm interface is that devices drivers will
be smaller in size, easier to write, and less error-prone since typical
patterns are outsourced to a trusted mechanism. And maintainers will spend less
time reviewing because resource allocation is a neverending source of mistakes.

Scope

I think the main ideas can be discussed and implemented in 120 hours effort.
If the duration is 1 or 2 months depends on how discussions with upstream go.

Contractor candidates

Given that I already started digging into the topic, have some designs sketched
and already submitted initial patches, I recommend myself. I also think I have
enough upstream experience to deal with such a major task.