From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48F888A2.7010404@domain.hid> Date: Fri, 17 Oct 2008 14:44:18 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20081016154620.320953568@domain.hid> <48F884EE.2030801@domain.hid> In-Reply-To: <48F884EE.2030801@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [PATCH 00/12] Generic fast xnsynch support & more List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org 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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux