Re: [RFC] rfkill: rewrite

[Ivo van Doorn <ivdoorn@gmail.com>]

On Sunday 29 March 2009, Johannes Berg wrote:
> This patch completely rewrites the rfkill core to address
> the following deficiencies:
> 
>  * all rfkill drivers need to implement polling where necessary
>    rather than having one central implementation
> 
>  * updating the rfkill state cannot be done from any context,
>    forcing drivers to use schedule_work and requiring lots of
>    code
> 
>  * rfkill drivers need to keep track of soft/hard blocked
>    internally -- the core should do this
> 
>  * the rfkill API has many unexpected quirks, for example being
>    asymmetric wrt. alloc/free and register/unregister
> 
>  * rfkill can call back into a driver from within a function the
>    driver called -- this is prone to deadlocks and generally
>    should be avoided
> 
>  * rfkill-input pointlessly is a separate module
> 
>  * drivers need to #ifdef rfkill functions (unless they want to
>    depend on or select RFKILL) -- rfkill should provide inlines
>    that do nothing if it isn't compiled in
> 
>  * the rfkill structure, despite containing almost only internal
>    variables, is not opaque -- and drivers need to initialise it
>    correctly (lots of sanity checking code required) -- instead
>    force drivers to pass the right variables to rfkill_alloc()
> 
>  * the documentation is hard to read because it always assumes
>    the reader is completely clueless and contains way to many CAPS
> 
>  * the rfkill code needlessly uses a lot of locks and atomic
>    operations in locked sections
> 
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> ---
> RFC only because I haven't fixed all drivers yet, still missing are
> toshiba, thinkpad, wimax and tosa.
> 
> Let the flames begin! (or if you like it feel free to chime in too)

Just for the record, as long as you (or somebody else) takes over maintainership
over rfkill after these changes, I have no objections against the changes. Luckily
you already updated the Maintainers entry, so I'm happy. :)

I know rfkill was poorly designed and I simply lacked the time (and perhaps
some interest as well) to continue with it. The changes you propose sound
reasonable so I hope it will turn rfkill really into something which it was supposed
to be from the start.

Ivo