Re: Kernel Images for Xenomai
On 01/15/2014 05:15 PM, Leopold Palomo-Avellaneda wrote:
> Hi,
>
> first of all please CC to me because I'm not in the kernel list. I saw the
> message in the web interface.
>
>>>
>>> So, what about to create a linux-image package, with a kernel packaged
>>> with xenomai?
>>
>> All kernel featuresets should be temporary, with the project aiming to
>> get their changes merged upstream.
>> http://www.xenomai.org/index.php/Xenomai:Roadmap doesn't say anything
>> about doing that, and if that isn't planned then I will reject this
>> proposal.
>
> well, Gilles could answer better than me, but Xenomai works with the adeos
> patch and the linux kernel is just another task. I don't know if it could be
> mixed, they are two different things. One is an kernel with the scheduler
> modified to try to do realtime features and another is an subkernel on Linux
> kernel run as a task.
That settles it then, it has been made very clear a long, long time ago that
the Adeos patch would never be merged into mainline.
> Another thing is if they will converge with the PREEMP_RT patches from Ingo
> Molnar and Co.
>
>> We already provide realtime kernel images using the PREEMPT_RT patch
>> series. Two types of realtime kernel would be an extravagance.
>
> One is a "Soft" realtime and another "Hard" realtime. Although in my area
> (robotics), the 95% of the applications could be perfect with the PREEMPT_RT
> version, there's another areas that could be benefit this option, so IMHO it's
> not an extravagance. I can say more, if Debian could have a group of packages
> that work on a hard realtime subset, specially on ARM, it would be a good plus
> to the project; better, we are towards the "world domination" ;-)
No, PREEMPT_RT is hard real-time as well, the two approaches are simply
different and both have their strengthes and weaknesses. You will find
a comparison between the various approaches for getting real-time
services with Linux here:
http://www2.hs-augsburg.de/informatik/vorlesungen/echtzeit/script/system/linux_rt01.html
The Adeos/Xenomai approach corresponds more or less to section 6.
>
>> But as
>> Xenomai apparently runs on top of PREEMPT_RT now, that might not be a
>> problem.
>
> I don't think so. I don't apply the PREEMPT_RT patch to use Xenomai. Gilles,
> I'm right?
The idea with the next (currently unreleased) branch of Xenomai is to
offer users the choice of the kernel they want to use. The aim of
Xenomai is not to provide real-time services using a particular
approach or another, but to help porting application from proprietary
RTOSes, such as vxworks, psos, etc... to a real-time Linux-based
system. The particular approach used to get real-time services is
secondary.
>>> - it has patches for previous versions of the linux provided by debian.
>>
>> There is only one version of Linux in each suite, and this is not likely
>> to change. So if Xenomai doesn't keep up with upstream development then
>> it would have to be disabled at times. (We currently do this with the
>> 'rt' featureset on odd-numbered Linux versions.)
>
> Ok, Gilles, would be possible to be sync and have a Adeos patch for the stable
> version included in debian?
AFAIK the version of Linux in debian stable is 3.2, and we already have
an Adeos patch for 3.2. Or are you talking about the Linux version
available for stable in debian backports?
>> There needs to be a nominated maintainer for each featureset. (In
>> practice I've been looking after the 'rt' featureset, but I'm not
>> offering to do that for anything else.) The maintainer will need to be
>> ready to resolve patch (and semantic) conflicts whenever the Linux
>> upstream version is updated, including stable updates.
>
> Well, Roland have done a good job with the xenomai package, and AFAIK some
> xenomai upstream and debian user, and I can help for this of course.
No question here that the one who would maintain the xenomai-patched
linux image would have to be familiar with xenomai.
--
Gilles.
Reply to: