svn commit: r241889 - in user/andre/tcp_workqueue/sys: arm/arm cddl/compat/opensolaris/kern cddl/contrib/opensolaris/uts/common/dtrace cddl/contrib/opensolaris/uts/common/fs/zfs ddb dev/acpica dev/...

[Andre Oppermann]

On 30.10.2012 03:25, Attilio Rao wrote:
> On Tue, Oct 30, 2012 at 1:38 AM, Attilio Rao <attilio at freebsd.org> wrote:
>> On Sun, Oct 28, 2012 at 5:42 PM, Attilio Rao <attilio at freebsd.org> wrote:
>
> [ trimm ]
>
>>>
>>> BTW, the mtx_sysuninit() introduction can be avoided by using this other trick:
>>> #define MTX_SYSINIT(name, mtx, desc, opts)                              \
>>>          static struct mtx_args name##_args = {                          \
>>>                  (mtx),                                                  \
>>>                  (desc),                                                 \
>>>                  (opts)                                                  \
>>>          };                                                              \
>>>          SYSINIT(name##_mtx_sysinit, SI_SUB_LOCK, SI_ORDER_MIDDLE,       \
>>>              mtx_sysinit, &name##_args);                                 \
>>>          SYSUNINIT(name##_mtx_sysuninit, SI_SUB_LOCK, SI_ORDER_MIDDLE,   \
>>>              _mtx_destroy, __DEVOLATILE(void *, &(mtx)->mtx_lock))
>>>
>>> I'm just not sure that I would like the use of __DEVOLATILE() even if
>>> it would help in this case when introducing MTX_SYSINIT_UNSHARE()
>>> because we will just need to reuse the same code.
>>>
>>> Also, the more I think about this the more I feel convinced that
>>> mtxlock2mtx() should be static in kern_mutex.c. I can simply add a
>>> note to _mutex.h as a reminder for it.
>>
>> Here is the patch that does both things and the one I would like to commit:
>> http://www.freebsd.org/~attilio/mtx_decoupled3.patch
>
> BTW, I've updated the patch in order to make use of __containerof()
> rather than the manual frobbing. I had no idea that this method was
> existing, many thanks to andre@ and mdf@ for signaling it.
> Please refresh the patch.

Thank you for the updated patch.  I have no objections to the patch,
though I'm not really qualified to have a final say on changes to the
mutex code.

-- 
Andre