lkml.org 
[lkml]   [2011]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET
On Mon, Apr 11, 2011 at 04:31:10PM +0800, Lai Jiangshan wrote:
> On 04/11/2011 01:12 PM, Paul E. McKenney wrote:
>
> > -static inline struct task_struct *next_thread(const struct task_struct *p)
> > -{
> > - return list_entry_rcu(p->thread_group.next,
> > - struct task_struct, thread_group);
> > -}
> > +/* Avoid #include hell for inlining rcu_read_lock(). */
> > +#define next_thread(p) \
> > + list_entry_rcu((p)->thread_group.next, struct task_struct, thread_group)
> >
>
>
> It is strange for me.
> The user of the API "next_thread(p)" must has two headers included, sched.h and rculist.h
>
> I know this is a very popular pattern of user space code, is it OK for kernel?
> I think a file(even a header file) uses API(Marco), it should includes the the corresponding
> headers, it reduces surprises(example, the name of "next_thread()" has no "rcu",
> it is not expected that rcuxxxx.h is required).
>
> I admit the work will become very much simpler if this pattern is allowed.

The guy who maintains much of sched.h suggested it. ;-)

Thanx, Paul

> man fcntl:
> #include <unistd.h>
> #include <fcntl.h>
>
> int fcntl(int fd, int cmd, ... /* arg */ );
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/


\
 
 \ /
  Last update: 2011-04-11 23:05    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site