Re: [Xenomai-core] (Not yet) Xenomai 2.5.5.

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> Am 16.09.2010 20:51, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Am 16.09.2010 10:17, Gilles Chanteperdrix wrote:
>>>> Hi,
>>>>
>>>> I would like to make that next release of Xenomai, especially since the
>>>> fix for the I-pipe on x86_32 with grub2 has been available for some time
>>>> now, and has not yet been in a stable release.
>>>>
>>>> So, I have a few minor questions:
>>>> - Wolfgang, Alexis, it seems we have a few warnings when compiling
>>>> rtcan/analogy tools with recent versions of gcc (4.4.1 from
>>>> codesourcery). You will find the logs here:
>>>> http://sisyphus.hd.free.fr/~gilles/pastebin/KVSBtb
>>>> we are not in a hurry to fix this, so simply tell me if the fix is easy
>>>> or not.
>>>> - Alexis, from the mailing list discussions, you probably have some
>>>> commits ready in the analoty branch, would it be possible to have a pull
>>>> request for these?
>>>> - Jan, where are we with CLOCK_HOST_REALTIME, are the I-pipe ready?
>>>> Should I merge Wolfgang's patches, or the I-pipe/Xenomai interface has
>>>> changed following the discussions with Philippe?
>>> I've a ready-to-use version that should address all of Philippe's
>>> remarks in my 2.6.35 queue [1]. The plan was to push it along this line,
>>> but then things got stuck due to the 32-bit boot hang report by Ed
>>> Hoffman (still waiting for further information from him). Also my KVM
>>> patches in that queue do not work yet, but they will likely be postponed.
>>>
>>> Besides that, I've longer queue of fixes and enhancement to Xenomai [2]
>>> that partially depends on [1]. I already sent pull requests, but then
>>> did not refresh it due to the dependency.
>>>
>>> Unfortunately, I'm "a bit" short on time the next weeks, so we need to
>>> find the cheapest way of getting the most important stuff merged for
>>> 2.5.5 I guess. I already started backporting the critical sync fixes for
>>> I-pipe to 2.6.34 [3], just sent no pull request yet.
>> Ok. I would like to be able to merge at least before the middle of next
>> week so as to validate a bit the result before releasing, hopefully,
>> before the end of next week.
>>
>> I had a look at the patches you pushed. I find it a bit dangerous to
>> merge quickly such patches, which fiddle with the nklock, without
>> extensive testing.
> 
> This is first of all xenomai-head stuff, nothing that shall be
> unconditionally backported. But even for head, we can perfectly skip the
> debugging part. Important are the fixes. I've reordered and shortened my
> queue already.
> 
>> The risk is that on SMP machines, the cpus start
>> dumping stack traces concurrently, resulting in an unreadable mess (we
>> have seen this in the past actually), whereas, correct me if I am wrong,
>> if the output takes place on the serial port, which is the current
>> preferred debug setup with Xenomai, we do not have to schedule klogd to
>> get an output, so we do not have to release the nklock.
> 
> I will have to check this again, but I bet the need for dropping nklock
> came from the fact that more than the serial port was configured (that's
> default here). Then some other console driver may have locked things up
> while walking the write handlers. Moreover, I would like to get more
> data in case the user did not yet prepare for catching a Xenomai panic.
> But, of course, dump regressions must be avoided.

We could use a separate lock to prevent multiple panics at the same time
from talking at the same time. But now that I think about it, panic
probably alread takes care of this.

> 
>> I also do not understand the game with panic. It looks to me there is a
>> risk of breaking compatibility with older Adeos patches, whose panic was
>> not as solid as the one of the current releases.
> 
> Do you have some versions in mind? Something in the early 2.6.20th or
> younger?

Not much of an issue finally. Except stubborn newcomers, people using
old patches probably have been using them for a long time and do not
have much kernel panics debug to do.

-- 
					    Gilles.