Improve devm * and get rid of boilerplate code

From eLinux.org
Revision as of 09:44, 1 October 2013 by Tim Bird (talk | contribs) (Reformat to page to standardized template.)
Jump to: navigation, search

Improve_devm_*_and_get_rid_of_boilerplate_code

Summary
Improve_devm_*_and_get_rid_of_boilerplate_code
Proposer
Wolfram Sang <wsa@the-dreams.de>

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.


Related work

First steps have already been done:

Remove unneded checks with devm_ioremap_resource: http://article.gmane.org/gmane.linux.drivers.driver-project.devel/38106

And bugs are found on the way, too:

Fixing wrong devres allocation in the PWM subsystem: http://lkml.org/lkml/2013/6/3/589

Fixing up wrong devm-conversions: http://thread.gmane.org/gmane.linux.kernel/1495010

Cleaning up copy&paste mistake in the GPIO subsystem: http://lkml.org/lkml/2013/6/4/436

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.

Comments