Re: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET

[Lai Jiangshan <laijs@cn.fujitsu.com>]

On 04/22/2011 04:10 PM, Peter Zijlstra wrote:
> On Fri, 2011-04-22 at 15:19 +0800, Lai Jiangshan wrote:
>>
>> What is the solution you prefer to?
>>
>> I insist on the solution which split rcupdate.h into 2 parts,
>> the first part is rcupdate_defs.h which only contains:
>> 1) struct rcu_head
>> 2) MACRO rcu_dereference*
>> 3) MACRO rcu_access_pointer rcu_access_index rcu_assign_pointer RCU_INIT_POINTER
>> 4) rcu_*_lock_held() which is required by 2)
>>
>> All of these is required by sched.h, it is all about 450 lines of code.
>>
>> It does not just separate struct rcu_head out only, because rcu_dereference*()
>> and APIs in rculist.h are required by in sched.h or headers included by sched.h.
> 
> The only usage of rculist.h in the whole of sched.h is that _one_
> list_entry_rcu, of which we already have a macro user, so why not make
> that one a macro too and safe ourselves a ton of grief?
> 
> You're just making stuff harder than it needs to be.
> 

No, opposite.
the more things(except rcu_read_[un]lock*()) are moved to rcupdate_defs.h the more easy.
the less things are moved to rcupdate_defs.h the more hard.

example, if rcu_dereference* is not moved to rcupdate_defs.h,
I have to do 2 more things:
1) convert inline functions next_thread() to macro.
2) find all .c which uses next_thread()/next_task() and ensure they all have rcupdate.h included.
3?) handle the complaints from LKML and told them should convert their new APIs to macro
    and should also do the same work like 2)

I'm just expressing my thinking, I will accept your requirement and make things progress.

Thanks,
Lai