Re: AW: [Xenomai-core] Fundamental Questions

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

Christopher Stone wrote:
> I do not have specific plans. 
> 
> I am working on something I am currently calling the Xen Loadable Module or
> XLM. It is an Xenomai application that when loaded, turns the Linux kernel
> into a Xen compatible hypervisor. For the rationale behind it see here:
> http://www.openembedded.biz/content/view/36/27.
> 
> When it is ready, in 6 to 8 weeks, I am prepared to contribute it. It is a
> significant work, but, is an Xenomai application, so I don't know if you
> guys want it. It does fit with your goals with respect to industrial grade
> Linux. 
> 
> I think that XLM actually illustrates a key point that people forget when
> they compare rt-preempt to Xenomai. I believe that in the industrial grade
> Linux world, the ability to support multiple OS's is key, especially in
> light of the emerging dual core CPU's. Due to ADEOS, Xenomai has the
> infrastructure to support doing things like running eCos on one core and
> Linux on the other, or eCos and Linux, side by side, on the same CPU. XLM is
> designed to make this easy. Rt-preempt has no such capability. 

Sounds interesting, especially when considering future systems with
hardware support for virtualisation, thus removing the need to patch the
guest OS (there are still people with the desire to run Windows aside
the RTOS core for visualisation etc.). And if your approach have real
advantages over Xen, specifically on embedded systems or in combination
with hard real-time, this could become really great.

> 
> I am not trying to discredit rt-preempt. It is a significant and useful
> piece of work and contains some pretty smart coding. However, in my view,
> rt-preempt is just part of the solution required for industrial grade linux.
> Things like rt-preempt, Xenomai, and hopefully XLM will all be pieces of a
> comprehensive industrial grade linux solution.
> 
> If XLM is not a suitable contribution to Xenomai, then, I can contribute

Let's wait for some code first so that things like intrusiveness etc.
can be analysed.

> other ways such as other feature development or bug fixing. I would need
> some direction from the leaders in order to contribute in that way.

It's often best to pick a domain you are interested in on your own. This
can drive the overall development application-oriented in a very
constructive way. When you are using Xenomai for some projects, you may
happen to stumble over rough edges or lacking features.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]