Wolfram, Great proposal! I'm glad to see this, as I think it addresses an important area of work and enablement in the kernel.
I wish you had used the template, though. :-) I've put the proposal on the wiki at: http://elinux.org/Improve_devm_*_and_get_rid_of_boilerplate_code -- Tim On Tuesday, October 01, 2013 5:46 AM, celinux-dev-boun...@lists.celinuxforum.org [celinux-dev-boun...@lists.celinuxforum.org] On Behalf Of Wolfram Sang [w...@the-dreams.de] wrote: > >Summary >======= > >Clean up, consolidate and improve the managed devices of the Linux kernel >(devm_* functions) and make their usage more consistent. That also enables to >remove boilerplate code and strings in drivers. > > >Proposer >======== > >Wolfram Sang <w...@the-dreams.de> > > >Description >=========== > >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. > _______________________________________________ Celinux-dev mailing list Celinux-dev@lists.celinuxforum.org https://lists.celinuxforum.org/mailman/listinfo/celinux-dev
