Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> 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. > > The problem is that it took me about one hour reviewing your 12 patches > (I know, I am a slow guy), and that I am not even sure that I saw all > the changes.
I appreciate your effort very much, and you already provided valuable input. But I feel it is much better to have the full picture instead of scattered bits. And this 12 patches belong together until none of their features are merged. > > The lockcnt change in patch 8 for instance is not even mentioned in the > patch comments, and it is only because I originally did not understand > the change in rt_cond_wait_inner that I now know about this change. Sorry for that, but it fell under the table on which all the other significant changes were already lying. Moreover, I originally felt it was only a minor cleanup as I simply aligned the code to the POSIX implementation in this regard. Nevertheless, the next posting will contain a separate patch for this. >>> 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. > > I think Philippe should merge the patches. Also fine. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
