[Xenomai-core] Future of fusion

[Xenomai-core] Future of fusion

[Marco Cavallini]

Hello,
I'd like to know (if is possible) the future plans and task schedule of 
fusion into xenomai project.
TIA

Marco Cavallini
=====================================================
Koan s.a.s. - Software Engineering
Linux and WinCE solutions for Embedded and Real-Time Software
Klinux : the embedded distribution for industrial applications
  - Atmel AT91 ARM Third Party Consultant
  - Intel PCA Developer Network Member
  - Microsoft Windows Embedded Partner
Via Pascoli, 3  - 24121 Bergamo - ITALIA
Tel. (++39) 035-255.235 - Fax (++39) 178-223.9748
http://www.koansoftware.com  -  http://www.klinux.org
===================================================== 

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

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

Marco Cavallini wrote:
> Hello,
> I'd like to know (if is possible) the future plans and task schedule of
> fusion into xenomai project.

Unless I don't misunderstand your question: Xenomai _is_ fusion. Take a
look at the code base, the main difference between fusion-0.9.1 and
current Xenomai SVN is the renaming (besides a lot of bug fixes).

Regarding the roadmap: browse the xenomai-core archive, there were
already a few postings about potential future directions.

HTH

Jan

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

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Marco Cavallini wrote:
> Hello,
> I'd like to know (if is possible) the future plans and task schedule of 
> fusion into xenomai project.
> TIA

There are things already going on "under the surface" right now, and others that 
would depend on everyone's input in order to start them or not. The roadmap will 
clearly depend on the combination of both aspects. I will give some details 
shortly about the current or next-to-be-started efforts, but the feedback part 
is important too, so here is the call for discussion once posted to this list:

--

I propose that we start discussing along the following lines, going into deeper 
detail as needed, but in any case, please remember that we don't have infinite 
resources to do everything at once, and that we need to keep an organisation 
that fits our abilities to manage it, so let's keep it modest and efficient. If 
I missed some important issues, please jump in. After that initial work, we 
should be able to define a sensible roadmap.

- Regular automated benchmarking: What is Xenomai currently capable of, how 
stable is it, do we progress or regress over time and releases, arch by arch?

- Documentation effort, dissemination: I'm a potential new user, do I have some 
unambiguous source of information available to get my feet wet with Xenomai?

- Architecture ports: There is life beyond x86.

- Kernel ports: Is there still room for a 2.4 port?

- Configuration, building and packaging issues: Could we make this easier?

- Linux integration issues: Tools we should interface with, features we should 
make more seamless.

- Scalability: Is Xenomai scalable enough? What's missing?

- Drivers: Now that we have a deeply integrated port of RTDM, what's next? Field 
busses and other industrial gizmos anyone?

- Current interfaces: Are we happy with them?

- New skins: Any new colors for the "chameleon"?

-- 

Philippe.

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Philippe Gerum wrote:

> Marco Cavallini wrote:
>> I'd like to know (if is possible) the future plans and task schedule of 
>> fusion into xenomai project.
>
> There are things already going on "under the surface" right now, and others 
> that would depend on everyone's input in order to start them or not. The 
> roadmap will clearly depend on the combination of both aspects. I will give 
> some details shortly about the current or next-to-be-started efforts, but the 
> feedback part is important too, so here is the call for discussion once 
> posted to this list:
>
[...]
> I propose that we start discussing along the following lines, going into 
> deeper detail as needed,

[...]
> - Drivers: Now that we have a deeply integrated port of RTDM, what's next? 
> Field busses and other industrial gizmos anyone?

That's an interesting avenue for all our machine control oriented realtime
applications. But this avenue is full of incomplete or non-free
specifications and interfaces...

[...]
> - New skins: Any new colors for the "chameleon"?
"Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
among other things, that the interference problem with the Posix thread
library (libraries) under Linux is solved.

Herman

--
   K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Herman Bruyninckx wrote:
 > On Thu, 13 Oct 2005, Philippe Gerum wrote:
 > 
 > [...]
 > > - New skins: Any new colors for the "chameleon"?
 > "Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
 > among other things, that the interference problem with the Posix thread
 > library (libraries) under Linux is solved.

What is wrong with the current implementation ? For me, the current
POSIX skin is close to final, in term of functionalities (on my todo
list, remain shared memories, implementation of mq_notify, and maybe
barriers, rwlocks and spinlocks, which are not a big deal). Of course,
some improvements are needed, such as a "process level" cleanup, which
would allow to reclaim automatically the memory used by anonymous
objects at the process death, or real-time signals, since for the
moments signals are handled in secondary mode, and an implementation of
message queues using shared memory, to avoid copies. But I assumed the
interference with the posix thread library was solved. Could you
elaborate a bit more on the issues you observed ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:

> Herman Bruyninckx wrote:
> > On Thu, 13 Oct 2005, Philippe Gerum wrote:
> >
> > [...]
> > > - New skins: Any new colors for the "chameleon"?
> > "Perfect POSIX" is, to me, more important than new skins. "Perfect" means,
> > among other things, that the interference problem with the Posix thread
> > library (libraries) under Linux is solved.
>
> What is wrong with the current implementation ? 
[...]
> But I assumed the
> interference with the posix thread library was solved. Could you
> elaborate a bit more on the issues you observed ?

Well, if this problem is solved, I'm very happy :-) And maybe I look at the
wrong places, but where do I find a succint explanation of the solution?

Herman
--
   K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:
> 
>> Herman Bruyninckx wrote:
>> > On Thu, 13 Oct 2005, Philippe Gerum wrote:
>> >
>> > [...]
>> > > - New skins: Any new colors for the "chameleon"?
>> > "Perfect POSIX" is, to me, more important than new skins. "Perfect" 
>> means,
>> > among other things, that the interference problem with the Posix thread
>> > library (libraries) under Linux is solved.
>>
>> What is wrong with the current implementation ? 
> 
> [...]
> 
>> But I assumed the
>> interference with the posix thread library was solved. Could you
>> elaborate a bit more on the issues you observed ?
> 
> 
> Well, if this problem is solved, I'm very happy :-) And maybe I look at the
> wrong places, but where do I find a succint explanation of the solution?
> 

Well, what's your question first? :o>

-- 

Philippe.

Re: [Xenomai-core] Future of fusion

[Herman Bruyninckx]

On Thu, 13 Oct 2005, Philippe Gerum wrote:

> Herman Bruyninckx wrote:
>> On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:
>> 
>>> Herman Bruyninckx wrote:
>>> > On Thu, 13 Oct 2005, Philippe Gerum wrote:
>>> >
>>> > [...]
>>> > > - New skins: Any new colors for the "chameleon"?
>>> > "Perfect POSIX" is, to me, more important than new skins. "Perfect" 
>>> means,
>>> > among other things, that the interference problem with the Posix thread
>>> > library (libraries) under Linux is solved.
>>> 
>>> What is wrong with the current implementation ? 
>> 
>> [...]
>> 
>>> But I assumed the
>>> interference with the posix thread library was solved. Could you
>>> elaborate a bit more on the issues you observed ?
>> 
>> 
>> Well, if this problem is solved, I'm very happy :-) And maybe I look at the
>> wrong places, but where do I find a succint explanation of the solution?
>> 
>
> Well, what's your question first? :o>
>
Sorry if that was not clear.

The question is: how is the following problem solved? Where the problem is
as follows: using Posix threads in realtime requires another library than
the standard NPTL library that Linux uses (at least, I think you require
another library), but how do you make sure to link to the correct library?
Or is NPTL realtime safe?

Herman

--
   K.U.Leuven, Mechanical Eng.,  Mechatronics & Robotics Research Group
     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 322480

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

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

Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
> [...]
> 
>> - Drivers: Now that we have a deeply integrated port of RTDM, what's
>> next? Field busses and other industrial gizmos anyone?
> 
> 
> That's an interesting avenue for all our machine control oriented realtime
> applications. But this avenue is full of incomplete or non-free
> specifications and interfaces...
> 

Indeed, but we cannot solve all problems at once. Let's start with those
devices which are more or less open (and there are already a lot). Let's
also try to propagate the message that RTDM is the prefered way to
provide real-time drivers. And if someone comes up with a new driver,
check if its interface is generic enough to implement it for similar
devices as well (=>generic device profiles).

Far from being perfect, but there are first efforts for such profiles:
Serial (as it comes with Xenomai), process image (see the Hilscher
Interbus driver I once announced), or CAN (yet a bit in flux, but things
slowly stabilises here). Plans exist to go the same way for low level
access to FireWire or USB. And you can even map whole protocol stacks
onto RTDM, like UDP/IP (RTnet) or also CANopen. The enables thrilling
combinations without the need to rewrite your application.

The interest in such progress is there, not yet on the vendor side, but
on the user side - including many industrial users. And they can push
things forward as well, finally making at least some vendors more
cooperative, too.

Jan

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

Re: [Xenomai-core] Future of fusion

[Paul]

Hi Philippe

On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
> - Regular automated benchmarking: What is Xenomai currently capable of, how
> stable is it, do we progress or regress over time and releases, arch by
> arch?

Have a couple of x86 development boxes running 24/7 - Could set one up as a 
compile farm for running automated builds. Also have a PowerPC thin client 
that I would like to utilise, but could really do with some help in setting 
up the tools for cross-compiling the base system under Debian.

> - Configuration, building and packaging issues: Could we make this easier?

Anything that involves patching/compiling kernels is bound to cause trouble 
for new users. Perhaps some tests for kernel options known to cause trouble 
(such as APM & REGPARM) that print out large warnings during the config stage 
might help..

Gilles already has a tarball of the Debian rules I used for packaging fusion. 
With minor changes, these could be used for a Xenomai package. One 
possibility is to use the rules and the compile farm to produce "ready to 
run" kernel/Xenomai Debian packages.


Regards, Paul.



-- 
From the Klingon book of C:
Klingon function calls do not have 'parameters' - they have 'arguments' - and
they ALWAYS WIN THEM.

Re: [Xenomai-core] Future of fusion

[Philippe Gerum]

Paul wrote:
> Hi Philippe
> 
> On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
> 
>>- Regular automated benchmarking: What is Xenomai currently capable of, how
>>stable is it, do we progress or regress over time and releases, arch by
>>arch?
> 
> 
> Have a couple of x86 development boxes running 24/7 - Could set one up as a 
> compile farm for running automated builds.

That would be great, thanks. Let us know if we could help.

  Also have a PowerPC thin client
> that I would like to utilise, but could really do with some help in setting 
> up the tools for cross-compiling the base system under Debian.

What about DENX's ELDK?

> 
> 
>>- Configuration, building and packaging issues: Could we make this easier?
> 
> 
> Anything that involves patching/compiling kernels is bound to cause trouble 
> for new users. Perhaps some tests for kernel options known to cause trouble 
> (such as APM & REGPARM) that print out large warnings during the config stage 
> might help..
> 

Ok, I have something rather highly ranked on my TODO list (which ends up by 2117 
or so), which is about allowing to build all Xenomai's in-kernel support 
statically in the Linux kernel. The rationale behind that is about making more 
straightforward and efficient embedded setups; straightforward because modules 
add more complexity than they would solve in typical embedded systems, and 
efficient since loading modules in a running kernel doesn't come for free.

To do that, portions of the Xeno build system which are currently 
autoconfiscated should move to the target kernel, so that we would only keep the 
autoconf infrastructure for what it's good at, i.e. building the user-space 
support. The basic idea is that we would then have a kernel extension part 
either buildable statically or as modules using Linux's Kconfig/Kbuild 
infrastructure, and a user-space support package providing the various interface 
libraries, headers, tools and scripts, ala glibc.

The immediate advantages would be:

- The core of the Xenomai support would be statically embeddable in the Linux 
kernel;
- No need for a Kconfig duplication like we have now; most of the options 
currently presented by Xeno's Kconfig sub-system concern the kernel portions, 
and very few actually concern the user-space stuff. We would then get rid of the 
former, and rely on the vanilla Linux's one instead.
- Centralizing Xenomai's kernel-related options with Linux's ones would make 
easier defining sanity checks (e.g. APM stuff and so on), since we could use the 
Kconfig language to enforce them in order to obtain sane configurations "by 
construction" (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's Kconfig 
is not aware of the kernel settings, so the checks are performed afterwise by 
the configure script instead.
- Removing the module compilation logic from the autoconfiscated Makefiles would 
be a significant simplification of the Xeno build system, and would make it less 
dependent on the kernel build system.
- This build process is still fully automatable.
- LKML people among my co-workers (Hi Stelian!) would start talking to me again, 
since I would stop pretending that autoconf is a sane way of controlling builds 
for kernel-based code. :o>

The way I see a typical build process would then be along these lines:

$ tar jxf xenomai-*
$ mkdir xeno-build && cd xeno-build && ../xenomai-*/configure 
--kernel=/usr/src/linux --some-option-only-for-uspace-stuff --prefix=<install-dir>
....
(the configure script would then prepare the autoconf _and_ make the necessary 
links from the target kernel to the Xenomai source tree to connect the modules 
to the kernel's Kbuild/Kconfig infrastructure.
....
$ cd /usr/src/linux
$ make gconfig
....
The user would configure his kernel, and all the kernel-based Xenomai stuff, as 
if they were standard drivers/extensions
....
$ make <the_kernel>
$ cd xeno-build && make install

And we would be done. Well, in a perfect world, I mean.

> Gilles already has a tarball of the Debian rules I used for packaging fusion. 
> With minor changes, these could be used for a Xenomai package. One 
> possibility is to use the rules and the compile farm to produce "ready to 
> run" kernel/Xenomai Debian packages.
>

I think we should be able to work this out will Gilles before 2.0 is out since 
it's a separate build-related issue.

> 
> Regards, Paul.
> 
> 
> 


-- 

Philippe.

Re: [Xenomai-core] Future of fusion

[Jan Kiszka]

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

Herman Bruyninckx wrote:
> On Thu, 13 Oct 2005, Philippe Gerum wrote:
> 
>> Herman Bruyninckx wrote:
>>
>>> On Thu, 13 Oct 2005, Gilles Chanteperdrix wrote:
>>>
>>>> Herman Bruyninckx wrote:
>>>> > On Thu, 13 Oct 2005, Philippe Gerum wrote:
>>>> >
>>>> > [...]
>>>> > > - New skins: Any new colors for the "chameleon"?
>>>> > "Perfect POSIX" is, to me, more important than new skins.
>>>> "Perfect" means,
>>>> > among other things, that the interference problem with the Posix
>>>> thread
>>>> > library (libraries) under Linux is solved.
>>>>
>>>> What is wrong with the current implementation ? 
>>>
>>>
>>> [...]
>>>
>>>> But I assumed the
>>>> interference with the posix thread library was solved. Could you
>>>> elaborate a bit more on the issues you observed ?
>>>
>>>
>>>
>>> Well, if this problem is solved, I'm very happy :-) And maybe I look
>>> at the
>>> wrong places, but where do I find a succint explanation of the solution?
>>>
>>
>> Well, what's your question first? :o>
>>
> Sorry if that was not clear.
> 
> The question is: how is the following problem solved? Where the problem is
> as follows: using Posix threads in realtime requires another library than
> the standard NPTL library that Linux uses (at least, I think you require
> another library), but how do you make sure to link to the correct library?
> Or is NPTL realtime safe?
> 

Nope, that's why there is RT-NPTL. And that library is still in flux,
especially now with the ongoing work on PREEMPT_RT. Let's wait for the
result and see if it is feasible to reuse this userspace infrastructure.

For now, I'm convinced that it is much more comfortable for the user to
obtain kernel extension and userspace library from one hand with a clear
and consistent versioning.

Jan

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

Re: [Xenomai-core] Future of fusion

[Wolfgang Grandegger]

On 10/13/2005 03:33 PM Philippe Gerum wrote:
> Paul wrote:
>> Hi Philippe
>> 
>> On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
>> 
>>>- Regular automated benchmarking: What is Xenomai currently capable of, how
>>>stable is it, do we progress or regress over time and releases, arch by
>>>arch?
>> 
>> 
>> Have a couple of x86 development boxes running 24/7 - Could set one up as a 
>> compile farm for running automated builds.
> 
> That would be great, thanks. Let us know if we could help.
> 
>   Also have a PowerPC thin client
>> that I would like to utilise, but could really do with some help in setting 
>> up the tools for cross-compiling the base system under Debian.
> 
> What about DENX's ELDK?
> 
>> 
>> 
>>>- Configuration, building and packaging issues: Could we make this easier?
>> 
>> 
>> Anything that involves patching/compiling kernels is bound to cause trouble 
>> for new users. Perhaps some tests for kernel options known to cause trouble 
>> (such as APM & REGPARM) that print out large warnings during the config stage 
>> might help..
>> 
> 
> Ok, I have something rather highly ranked on my TODO list (which ends up by 2117 
> or so), which is about allowing to build all Xenomai's in-kernel support 
> statically in the Linux kernel. The rationale behind that is about making more 
> straightforward and efficient embedded setups; straightforward because modules 
> add more complexity than they would solve in typical embedded systems, and 
> efficient since loading modules in a running kernel doesn't come for free.

That would be great for embedded systems, indeed. Apart from getting rid
of the module infrastructure, it also save TLB misses because modules
are typically placed in vmalloc'ed space. Systems with small TLB entry
tables will benefit, like PowerPC 8xx and 4xx.

> 
> To do that, portions of the Xeno build system which are currently 
> autoconfiscated should move to the target kernel, so that we would only keep the 
> autoconf infrastructure for what it's good at, i.e. building the user-space 
> support. The basic idea is that we would then have a kernel extension part 
> either buildable statically or as modules using Linux's Kconfig/Kbuild 
> infrastructure, and a user-space support package providing the various interface 
> libraries, headers, tools and scripts, ala glibc.
> 
> The immediate advantages would be:
> 
> - The core of the Xenomai support would be statically embeddable in the Linux 
> kernel;
> - No need for a Kconfig duplication like we have now; most of the options 
> currently presented by Xeno's Kconfig sub-system concern the kernel portions, 
> and very few actually concern the user-space stuff. We would then get rid of the 
> former, and rely on the vanilla Linux's one instead.
> - Centralizing Xenomai's kernel-related options with Linux's ones would make 
> easier defining sanity checks (e.g. APM stuff and so on), since we could use the 
> Kconfig language to enforce them in order to obtain sane configurations "by 
> construction" (e.g. CONFIG_XENO disables CONFIG_APM). Currently, Xeno's Kconfig 
> is not aware of the kernel settings, so the checks are performed afterwise by 
> the configure script instead.
> - Removing the module compilation logic from the autoconfiscated Makefiles would 
> be a significant simplification of the Xeno build system, and would make it less 
> dependent on the kernel build system.
> - This build process is still fully automatable.
> - LKML people among my co-workers (Hi Stelian!) would start talking to me again, 
> since I would stop pretending that autoconf is a sane way of controlling builds 
> for kernel-based code. :o>
> 
> The way I see a typical build process would then be along these lines:
> 
> $ tar jxf xenomai-*
> $ mkdir xeno-build && cd xeno-build && ../xenomai-*/configure 
> --kernel=/usr/src/linux --some-option-only-for-uspace-stuff --prefix=<install-dir>
> ....
> (the configure script would then prepare the autoconf _and_ make the necessary 
> links from the target kernel to the Xenomai source tree to connect the modules 
> to the kernel's Kbuild/Kconfig infrastructure.
> ....
> $ cd /usr/src/linux
> $ make gconfig
> ....
> The user would configure his kernel, and all the kernel-based Xenomai stuff, as 
> if they were standard drivers/extensions
> ....
> $ make <the_kernel>
> $ cd xeno-build && make install
> 
> And we would be done. Well, in a perfect world, I mean.
> 
>> Gilles already has a tarball of the Debian rules I used for packaging fusion. 
>> With minor changes, these could be used for a Xenomai package. One 
>> possibility is to use the rules and the compile farm to produce "ready to 
>> run" kernel/Xenomai Debian packages.
>>
> 
> I think we should be able to work this out will Gilles before 2.0 is out since 
> it's a separate build-related issue.
> 
>> 
>> Regards, Paul.
>> 
>> 
>> 
> 
> 

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Herman Bruyninckx wrote:
 > The question is: how is the following problem solved? Where the problem is
 > as follows: using Posix threads in realtime requires another library than
 > the standard NPTL library that Linux uses (at least, I think you require
 > another library), but how do you make sure to link to the correct library?

First, Xenomai user-space POSIX library uses the same data structure
definitionss as Linux threading libraries (whether linuxthread or
NPTL). This way, including Xenomai specific headers is not mandatory for
using its POSIX library. Another advantage: Xenomai implementation of
POSIX functions may decide to delegate control to the real ones without
having to touch the user structures.

Of course, if you do not include Xenomai headers, you will not get
declarations of some functions specific to Xenomai, some of these
functions are non portable (such as pthread_make_periodic_np and
pthread_wait_np, which are still the easiest solution to get periodic
tasks in primary mode), other are not yet in all distributions, such as
the message queues API.

Second, Xenomai build a user-space library made for use with the --wrap
option of the GNU linker. Xenomai implementation of the pthread_create
function is called __wrap_pthread_create, and when linking with Xenomai
library, ld replace any call to pthread_create in the user code by
__wrap_pthread_create, so that at run time, Xenomai implementation of
this function gets called.

This solution avoids the unexpected segmentation faults. Users mistake
result either in linker errors (because of the use of a function of
Xenomai which does not exist in Linux threading library without the
--wrap parameters, or conversely because the --wrap option was passed
while trying to link with one of Linux threading libraries). In the
worst case, a user program may run as standard Linux POSIX threads
application if he forgot the --wrap options, but this is easy to see,
since /proc/xenomai/sched shows no real-time thread. Do not get me
wrong, passing the correct arguments to the compiler is as easy as with
any other skin; it is just a matter of calling xeno-config
--posix-cflags andd xeno-config --posix-ldflags. Some examples are
included in skins/posix/demos.

The current implementaion of Xenomai user-space POSIX skin also allow
Linux POSIX threads libraries functions to remain accessible aside
Xenomai calls; for example, you may still create Linux POSIX threads by
calling __real_pthread_create. Actually, now that I think about it,
being able to access easily Linux calls aside Xenomai ones was a
requirement among the most important in our view.


  > Or is NPTL realtime safe? 

the "accuracy" example in skins/posix/demos should help you get an
opinion on that point.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Gilles Chanteperdrix]

Paul wrote:
 > 
 > Hi Philippe
 > 
 > On Thursday 13 October 2005 09:24, Philippe Gerum wrote:
 > > - Regular automated benchmarking: What is Xenomai currently capable of, how
 > > stable is it, do we progress or regress over time and releases, arch by
 > > arch?
 > 
 > Have a couple of x86 development boxes running 24/7 - Could set one up as a 
 > compile farm for running automated builds. Also have a PowerPC thin client 
 > that I would like to utilise, but could really do with some help in setting 
 > up the tools for cross-compiling the base system under Debian.

Actually, there are ready made debian cross toolchain packages at
debian.speedblue.org 

 > Gilles already has a tarball of the Debian rules I used for packaging fusion. 
 > With minor changes, these could be used for a Xenomai package. One 
 > possibility is to use the rules and the compile farm to produce "ready to 
 > run" kernel/Xenomai Debian packages.

Well, quite frankly, I do not know much about the debian packages
creation process, in any case not enough to do the work which remains
to be done. The best I can do is add the debian directory to the svn
repository, letting volunteers work on it and submit patches...

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Future of fusion

[Romain Lenglet]

>  > Gilles already has a tarball of the Debian rules I used for
>  > packaging fusion. With minor changes, these could be used
>  > for a Xenomai package. One possibility is to use the rules
>  > and the compile farm to produce "ready to run"
>  > kernel/Xenomai Debian packages.
>
> Well, quite frankly, I do not know much about the debian
> packages creation process, in any case not enough to do the
> work which remains to be done. The best I can do is add the
> debian directory to the svn repository, letting volunteers
> work on it and submit patches...

I have proposed a few improvements for the Debian packaging in 
"wish" #4523:
https://gna.org/bugs/index.php?func=detailitem&item_id=4523

-- 
Romain Lenglet

[Xenomai-core] Packaging issues and licensing issues

[Romain Lenglet]

Hi,

I repost here the issues that I have pointed in "wish" #4523 on 
the GNA interface 
https://gna.org/bugs/index.php?func=detailitem&item_id=4523
which, although it is listed in the bug tracker, is *not* a 
bug... ;) but there is no other place to put wishes or todo 
items.

========================================
Debian offers the module-assistant package, that relies on the 
kernel-package tools.
 module-assistant is both a command-line and a dialog-and-menus 
based tool, to make it very easy to build and package kernel 
modules.
 
 For instance, to build a module package from the ipw2100-source 
package (for wireless cards), the single following command is 
sufficient:
 $> m-a build ipw2100
 This downloads the source package, builds the modules and 
packages them.
 $> m-a install ipw2100
 This command does the same and even installs the built package.
 
 However, the current rtai-source in Debian is the only *-source 
package that cannot be built using module-assistant. This should 
be corrected in the next packages.
 
 
 I propose that the package be split into 5 packages, anyway:
 - libxenomai: the libraries,
 - libxenomai-dev: the development libraries, headers and devel 
tools (rtai-config, etc.),
 - libxenomai-tools: the runtime tools (rtai-load, etc.?)
 - libxenomai-doc: the docs,
 - xenomai-source: only the sources of modules; should be usable 
with module-assistant.
 
 And the *-source package should be well integrated: the module 
*.ko files should go into /lib/modules/... so that we can use 
modprobe directly to load the Xenomai modules. But that should 
be OK if it is compatible with module-assistant.
========================================


I have started creating a Debian package mockup (as a week-end 
hobby, do no expect that I finish it ;)), following the above 
remarks, and I have found other issues:

There are three licenses used in the source code:
1- GPL v2 or later:
  ./sim/**
  ./skins/rtai/*
  ./skins/posix/*
  ./skins/native/*
  ./skins/uvm/*
  ...
OK, no problem: the COPYING files are consistent with the license 
headers in files.

2- GPL v2 or later with exceptions:
  ./nucleus/**
  ./include/nucleus/**
  ./skins/psos+/**
  ./skins/uitron/**
  ./skins/vrtx/**
  ./skins/vxworks/**
  ...
The license headers in files do not mention the exceptions, only 
the COPYING files do. -> You should update the license headers 
in files.

3- LGPL v2 or later:
  ./skins/rtai/lib/*
  ./skins/posix/lib/*
  ./skins/native/lib/*
  ./skins/uvm/lib/*
  ...
Problem: only the text for v2.1 is in the COPYING files, not for 
v2 as mentioned in all license headers in files. -> You should 
update the COPYING files to contain LGPL v2, or update headers 
in files.


My other issue is: what are precisely the licences of every 
binaries / docs / modules / ... produced by make install? 
Because the right license files and doc must be provided in 
binary packages.

-- 
Romain Lenglet

Re: [Xenomai-core] Packaging issues and licensing issues

[Gilles Chanteperdrix]

Romain Lenglet wrote:
 > Hi,
 > 
 > I repost here the issues that I have pointed in "wish" #4523 on 
 > the GNA interface 
 > https://gna.org/bugs/index.php?func=detailitem&item_id=4523
 > which, although it is listed in the bug tracker, is *not* a 
 > bug... ;) but there is no other place to put wishes or todo 
 > items.

Ah, thanks ! The mailing list is the best place for yous wishes, since
it may start a discussion, and we may even found a volunteer for doing
the debian package.

The bug is closed.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Packaging issues and licensing issues

[gna-dev]

On Sunday 16 October 2005 08:50, Gilles Chanteperdrix wrote:
> Ah, thanks ! The mailing list is the best place for yous wishes, since
> it may start a discussion, and we may even found a volunteer for doing
> the debian package.

Using the debian/rules I did a few weeks ago as a basis for further work, I 
can work with Romain to develop it further. Not sure that having separate 
packages for each skin is a good idea, but certainly m-a is worth persuing.

Somewhere along the way, it would be wise (in my opinion) to appoint a package 
manager with write permissions to svn/cvs and file areas - This would relieve 
the core team of the burden of repository maintenance.


Regards, Paul.

Re: [Xenomai-core] Packaging issues and licensing issues

[Romain Lenglet]

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

Hi Paul,

> Using the debian/rules I did a few weeks ago as a basis for
> further work, I can work with Romain to develop it further.
> Not sure that having separate packages for each skin is a good
> idea, but certainly m-a is worth persuing.

Yes, finally I think that one set of packages for every skin 
would be overkill.

As my 2 yen contribution, here is a debian/control file (ok, this 
is the easiest task, but someone had to do it...). ;)

As for the rules file, I think that the most difficult will be to 
generate the module source package. There is already a skeleton 
of a source package generating a module source package, in the 
documentation of package module-assistant:
/usr/share/doc/module-assistant/examples/templates-debian-dir.tar.bz2

What I did is to start with dh_make --kmod, then modify the 
control file to define the other packages. Then we should try to 
reuse module-assistant's template, that is apparently used by 
all other module source packages in Debian.

-- 
Romain Lenglet

[-- Attachment #2: control --]
[-- Type: text/plain, Size: 4537 bytes --]

Source: xenomai
Section: devel
Priority: extra
Maintainer: Romain Lenglet <rlenglet@domain.hid>
Build-Depends: debhelper (>= 4.0.0), autotools-dev
Standards-Version: 3.6.2

Package: libxenomai
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (libraries)
 Xenomai is a real-time development framework cooperating with the
 Linux kernel, in order to provide a pervasive, interface-agnostic,
 hard real-time support to user-space applications, seamlessly
 integrated into the GNU/Linux environment.
 .
 Xenomai is based on an abstract RTOS core, usable for building any
 kind of real-time interfaces, over a nucleus which exports a set of
 generic RTOS services. Any number of RTOS personalities called
 "skins" can then be built over the nucleus, providing their own
 specific interface to the applications, by using the services of a
 single generic core to implement it.
 .
 This package contains the runtime shared libraries.

Package: libxenomai-dev
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (development)
 Xenomai is a real-time development framework cooperating with the
 Linux kernel, in order to provide a pervasive, interface-agnostic,
 hard real-time support to user-space applications, seamlessly
 integrated into the GNU/Linux environment.
 .
 Xenomai is based on an abstract RTOS core, usable for building any
 kind of real-time interfaces, over a nucleus which exports a set of
 generic RTOS services. Any number of RTOS personalities called
 "skins" can then be built over the nucleus, providing their own
 specific interface to the applications, by using the services of a
 single generic core to implement it.
 .
 This package contains the development environment.

Package: libxenomai-tools
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (tools)
 Xenomai is a real-time development framework cooperating with the
 Linux kernel, in order to provide a pervasive, interface-agnostic,
 hard real-time support to user-space applications, seamlessly
 integrated into the GNU/Linux environment.
 .
 Xenomai is based on an abstract RTOS core, usable for building any
 kind of real-time interfaces, over a nucleus which exports a set of
 generic RTOS services. Any number of RTOS personalities called
 "skins" can then be built over the nucleus, providing their own
 specific interface to the applications, by using the services of a
 single generic core to implement it.
 .
 This package contains command-line tools for testing Xenomai.

Package: libxenomai-doc
Architecture: i386 powerpc
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Xenomai real-time framework (documentation)
 Xenomai is a real-time development framework cooperating with the
 Linux kernel, in order to provide a pervasive, interface-agnostic,
 hard real-time support to user-space applications, seamlessly
 integrated into the GNU/Linux environment.
 .
 Xenomai is based on an abstract RTOS core, usable for building any
 kind of real-time interfaces, over a nucleus which exports a set of
 generic RTOS services. Any number of RTOS personalities called
 "skins" can then be built over the nucleus, providing their own
 specific interface to the applications, by using the services of a
 single generic core to implement it.
 .
 This package contains documentation on the usage of the libraries.

Package: xenomai-source
Architecture: i386 powerpc
Depends: module-assistant, debhelper (>>4.0.0), make, bzip2
Recommends: kernel-patch-adeos (>=20050809)
Description: Xenomai real-time framework (kernel module source)
 Xenomai is a real-time development framework cooperating with the
 Linux kernel, in order to provide a pervasive, interface-agnostic,
 hard real-time support to user-space applications, seamlessly
 integrated into the GNU/Linux environment.
 .
 Xenomai is based on an abstract RTOS core, usable for building any
 kind of real-time interfaces, over a nucleus which exports a set of
 generic RTOS services. Any number of RTOS personalities called
 "skins" can then be built over the nucleus, providing their own
 specific interface to the applications, by using the services of a
 single generic core to implement it.
 .
 This package provides the source code for the xenomai kernel modules.
 The xenomai package is also required in order to make use of these
 modules. Kernel source or headers are required to compile these modules.

Re: [Xenomai-core] Packaging issues and licensing issues

[Gilles Chanteperdrix]

gna-dev@domain.hid wrote:
 > On Sunday 16 October 2005 08:50, Gilles Chanteperdrix wrote:
 > > Ah, thanks ! The mailing list is the best place for yous wishes, since
 > > it may start a discussion, and we may even found a volunteer for doing
 > > the debian package.
 > 
 > Using the debian/rules I did a few weeks ago as a basis for further work, I 
 > can work with Romain to develop it further. Not sure that having separate 
 > packages for each skin is a good idea, but certainly m-a is worth persuing.
 > 
 > Somewhere along the way, it would be wise (in my opinion) to appoint a package 
 > manager with write permissions to svn/cvs and file areas - This would relieve 
 > the core team of the burden of repository maintenance.

That is true. Would you volunteer ?
Or maybe Romain, since he seem to have undertaken some part of the
remaining work ?

-- 


					    Gilles Chanteperdrix.