Re: [PATCH] rcu: do not include rtmutex_common.h unconditionally

[Paul E. McKenney]

On Thu, Oct 19, 2017 at 08:15:05PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-10-18 13:42:59 [-0700], Paul E. McKenney wrote:
> > 
> > Builds for me on x86 and 0day test robot hasn't complained, but might
> > as well get it right.
> 
> So I checked you tree and there is this:
> 
> |$ git one bc2eecd7ecce40af43b6eb3d256b6076257df846
> |bc2eecd7ecce ("futex: Allow for compiling out PI support")
> |$ git describe bc2eecd7ecce40af43b6eb3d256b6076257df846 --contains
> |v4.14-rc1~162^2~57
> 
> so this exploded on my side because I applied it on top of v3.13, you on
> the other hand had it post v4.13-rc1 so it was all good.
> Now, that it is possible to include that header file with and without
> CONFIG_RT_MUTEX=y we could indeed move that include outside of that
> ifdef. Sorry for that.

Sounds like something I would do!  ;-)

> We could do that and move the two defines (rt_mutex_owner +
> rt_mutex_futex_unlock) to the rtmutex_common.h like in bc2eecd7ecce.
> This might look good, I don't know. If you want, I can prepare a patch
> for that, we could leave it as itâ

One advantage is that builds would go more easily, and things like
RCU that need to build either way wouldn't need their own splat-generating
definitions of the rt_mutex primitives.

On the other hand, this would lose the current build-time detection
of use of rt_mutux on architectures not providing it.

Given the choice, I would prefer the build-time detection.

Thoughts?

							Thanx, Paul

> >                        The new commits are:
> > 
> > a06f537e75ea ("rcu: do not include rtmutex_common.h unconditionally")
> > 4a0fb5d70bb2 ("rcu: Suppress lockdep false-positive ->boost_mtx complaints")
> 
> Okay, thanks.
> 
> > 							Thanx, Paul
> 
> Sebastian
>