Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Here comes a significantly reworked patch series to improve fast mutex
>> support of Xenomai.
>> This approach now introduces a generic fast xnsynch core and converts
>> the existing POSIX implementation over. It also comes with a second
>> user, the Native skin. Additionally, it improves xeno_get_current via
>> a TLS variable and addresses the issue that threads in secondary mode
>> acquiring an uncontended mutex need to be migrated first.
>> At this chance, the TLS optimization is also applied on self-lookups of
>> task handles (Native, VRTX and VxWorks). And I included my
>> SMP-by-default patch for user libs which is highly recommended to reduce
>> the risk of accidental code breakage on SMP with the new mutex code.
> A minor remark. This is the third round of patches for fast mutexes, and
>  each round, you submit even more changes to review than the previous
> round. If I doubted of your honesty, I could think that you are trying
> to dilute some questionable changes into more changes so that they get
> unnoticed.

May I recall the changelog of this round? In short:

 - generic xnsynch
 - fixed prio-inversion when coming from secondary mode

These are major changes, addressing specifically the NACKs of the
previous rounds.

If you find "questionable changes", please point them out. So far I only
recall the discussion about lockcnt maintenance policy, and I will try
to sort that one out.

> Could we focus on a small set of changes, reach consensus, merge them,
> and then move to the next set of changes?

No problem. Maybe I missed or forgot the clear OK for patches 1..4 to
commit them, but I will now soon. Moreover, I just felt uncomfortable
with merging patch 5 without having written to following ones.


Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Xenomai-core mailing list

Reply via email to