Messages in this thread | | | Date | Mon, 11 Apr 2011 14:02:23 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [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/
| |