Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-10 Thread Andy Ritger
On Fri, Feb 10, 2017 at 06:50:50PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-02-03 08:49:24 [-0800], Andy Ritger wrote: > > > So your problem is simply that your non-GPL module can't link anymore > > > with -RT. Would it help you if I simply replace the export fo

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-02-03 Thread Andy Ritger
On Fri, Feb 03, 2017 at 04:54:34PM +0100, Sebastian Andrzej Siewior wrote: > On 2017-01-30 09:35:34 [-0800], Andy Ritger wrote: > > The problem is that various static inline functions such as > > reservation_object_fini() indirectly call mutex_destroy. On DEBUG_MUTEX > > kern

Re: [PATCH RT] Align rt_mutex inlining with upstream behavior

2017-01-30 Thread Andy Ritger
is patch aligns > > rt_mutex_destroy() with mutex_destroy() by using the same no-op inline > > technique. > > > > Signed-off-by: Alex Goins > > Reviewed-by: Andy Ritger > > So what is the problem? Why are we doing this? There is still a check to > see if th

Re: include/linux/rtmutex.h: NOOP rt_mutex_destroy if !CONFIG_DEBUG_RT_MUTEXES

2016-12-02 Thread Andy Ritger
This seems consistent with the spirit of DEBUG_MUTEX in non-RT kernels, so hopefully this is acceptable to the RT maintainers. Reviewed-by: Andy Ritger Thanks, - Andy On Tue, Oct 25, 2016 at 07:03:51PM -0700, Alex Goins wrote: > mutex_destroy is no-op inline when DEBUG_MUTEX is not enab