Re: [patch 2/3] RCU move trace defines to rcupdate_types.h

[Mathieu Desnoyers <compudj@krystal.dyndns.org>]

* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> > 
> > On Thu, 16 Apr 2009, Jeremy Fitzhardinge wrote:
> > 
> > > I don't think this helps.  rcupdate_types.h uses preempt_disable/enable, but
> > > doesn't include linux/preempt.h for them - but someone's going to have to, so
> > > you've got an implicit dependency on the user to #include the right headers in
> > > advance.
> > 
> > Would including linux/preempt.h in rcupdate_types.h be a problem?
> > 
> > -- Steve
> > 
> 
> I did not include preempt.h in rcupdate_types.h because rcupdate.h did
> not include it, so I thought it had a special status such a kernel.h.
> However, I notice the rcupdate.h includes spinlock.h, which in turn
> includes preempt.h, so we would need to include preempt.h in
> rcupdate_types.h.
> 

Hrm, well, the actual question is :

given rcupdate_types.h only defines macros, and given we won't want to
include all the headers that implement all the content of these macros,
does it make sense to typically require people to either include
rcupdate.h directly if they want to have the full includes required to
expand the macros ?

If we do that, then including preempt.h in rcupdate_types.h is not
necessary. However, tracepoint.h should now include preempt.h, because
it would be cumbersome to require from every tracepoint.h users to
include preempt.h.

One way or another, we will have to include preempt.h under
tracepoint.h, but I don't see it as a roadblock, given that preempt.h is
quite slim.

Mathieu

> But I think preempt.h is pretty much only type definitions. I don't
> think that would be a problem, but maybe Jeremy knows better.
> 
> Mathieu
> 
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68