[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel Images for Xenomai



On Wed, 2014-01-15 at 12:25 +0100, Leopold Palomo-Avellaneda wrote:
> Dear people,
> 
> 
> there's a project Xenomai [1] that patching the kernel source and providing a 
> library transform a non-realtime system as GNU/Linux into a realtime (hard) 
> system.
>
> In debian, we have packaged that [2]. The user, to get the realtime must patch 
> the kernel, configure it build it. There are several guides to do that, for 
> instance [3]. However, configure a Xenomai system it's not easy, because 
> there's a lot of issues that the "normal" user unknown, or are too specific 
> for a developer that need a realtime program.
> 
> One of the Xenomai developers (Gilles Chanteperdrix) provided some linux 
> images, and other people (myself for example) too. However, in the xenomai 
> list [4], commented about the packages I asked:
> 
> > Really, it's possible to provide a Xenomai patched kernel for the 95% of the
> > users/hardware?
> 
> and the Gilles answer was interesting:
> 
> > Yes. Starting with the I-pipe core patches, definitely. And if not, I
> > think this is something we should work on. Because in the long run, if
> > users installed pre-packaged kernels and did not have to follow the
> > traditional trial-and-error process of configuring kernels for xenomai,
> > we would have less questions on this subject on the mailing list.
> 
> 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.

We already provide realtime kernel images using the PREEMPT_RT patch
series.  Two types of realtime kernel would be an extravagance.  But as
Xenomai apparently runs on top of PREEMPT_RT now, that might not be a
problem.

> I ask it to the debian kernel maintainers with the lack of knowledge that what 
> it implies, because for example:
> 
> - xenomai doesn't work in all architectures than debian.

That doesn't matter.

> - 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.)

> - who maintain it?
>
> However, I think that we can have interested people to work on that, and could 
> be affordable.

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.

Ben.

-- 
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                               - John Lennon

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: