[Xenomai] Packaging Xenomai-3

[Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

Hi,

now that I have some kernel to boot, I would like to ask some aspects of 
Xenomai-3 in order to package it.

Reading the documentation, now the new libxenomai could use two kind of 
kernels: the patched one (Cobalt) or the preempt_rt (Mercury).

1) Is it possible to have _only_ one library (binary) that uses one or another 
kernel in function which is running?

2) If not, as we must recompile the library, all the programs linked against 
must be recompiled or if it's binary compatible?

3) Comparing the files generated (xenomai-2.x vs xenomai-3.x, if you bump the 
sonames of libanalogy, libpsos and libvxworks you could have (I guess) both 
binary versions installed in the same box.

4) Why the libvxworks has lower soname version in 2.6.4 than in 3.0.0?


Best regards,

Leopold




-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150123/ada3a703/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> now that I have some kernel to boot, I would like to ask some aspects of 
> Xenomai-3 in order to package it.
> 
> Reading the documentation, now the new libxenomai could use two kind of 
> kernels: the patched one (Cobalt) or the preempt_rt (Mercury).

a preempt_rt kernel is a patched kernel too.

> 
> 1) Is it possible to have _only_ one library (binary) that uses one or another 
> kernel in function which is running?

No, you could want to run a kernel with both patches. So basing the
decision on which patch you are running does not make sense.

-- 
					    Gilles.

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/23/2015 01:09 PM, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> now that I have some kernel to boot, I would like to ask some aspects of 
> Xenomai-3 in order to package it.
> 
> Reading the documentation, now the new libxenomai could use two kind of 
> kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> 

Mercury does not require preempt-rt. In some cases, one may want the API
emulation capabilities without actually having real-time requirements.

> 1) Is it possible to have _only_ one library (binary) that uses one or another 
> kernel in function which is running?
> 

No. Definitely not.

> 2) If not, as we must recompile the library, all the programs linked against 
> must be recompiled or if it's binary compatible?
> 

Can't have the same ABI. Two separate builds are required.

> 3) Comparing the files generated (xenomai-2.x vs xenomai-3.x, if you bump the 
> sonames of libanalogy, libpsos and libvxworks you could have (I guess) both 
> binary versions installed in the same box.
> 

This would make sense, but only for libs. Scripts, includes would conflict.

> 4) Why the libvxworks has lower soname version in 2.6.4 than in 3.0.0?
> 

Because it has been entirely rewritten over the copperplate interface
and extended in terms of emulated services.

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Divendres, 23 de gener de 2015, a les 16:52:31, Gilles Chanteperdrix va 
escriure:
> On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > now that I have some kernel to boot, I would like to ask some aspects of
> > Xenomai-3 in order to package it.
> > 
> > Reading the documentation, now the new libxenomai could use two kind of
> > kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> 
> a preempt_rt kernel is a patched kernel too.

Writing the email I thought, both are patches, but I thought preempt_rt was 
integrated in mainline.
 
> > 1) Is it possible to have _only_ one library (binary) that uses one or
> > another kernel in function which is running?
> 
> No, you could want to run a kernel with both patches. So basing the
> decision on which patch you are running does not make sense.

I don't want to run a kernel with both patches. It has no sense. But I could 
have binary packages that could work with both kernels. That was my idea.

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150123/fa940287/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Divendres, 23 de gener de 2015, a les 17:04:37, Philippe Gerum va escriure:
> On 01/23/2015 01:09 PM, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > now that I have some kernel to boot, I would like to ask some aspects of
> > Xenomai-3 in order to package it.
> > 
> > Reading the documentation, now the new libxenomai could use two kind of
> > kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> 
> Mercury does not require preempt-rt. In some cases, one may want the API
> emulation capabilities without actually having real-time requirements.

Ops, Philippe  the documentation [1] says that Mercury:

> Your kernel should at least provide high resolution timer support 
(CONFIG_HIGH_RES_TIMERS), and likely complete preemption (PREEMPT_RT) if your 
application requires short and bounded latencies.

if your application .. it's not mandatory, right?. So, you can use it in any 
kernel that at least has CONFIG_HIGH_RES_TIMERS

> > 1) Is it possible to have _only_ one library (binary) that uses one or
> > another kernel in function which is running?
> 
> No. Definitely not.

Ok, it's too difficult to have it? Same lib that in runtime select the interface 
to use? So, then someone could provide a binary, that depends on the kernel 
will work with cobalt or mercury. The packagers would have the life better.

> 
> > 2) If not, as we must recompile the library, all the programs linked
> > against must be recompiled or if it's binary compatible?
> 
> Can't have the same ABI. Two separate builds are required. 

:-( it makes sense if they have different names? -c vc -m or whatever?
> 
> > 3) Comparing the files generated (xenomai-2.x vs xenomai-3.x, if you bump
> > the sonames of libanalogy, libpsos and libvxworks you could have (I
> > guess) both binary versions installed in the same box.
> 
> This would make sense, but only for libs. 

of course.

> Scripts, includes would conflict.

another package shared is possible? (xenomai-tools, xenomai-scripts, ....)

If you have different library names, pkg-config could solve that.


> > 4) Why the libvxworks has lower soname version in 2.6.4 than in 3.0.0?
> 
> Because it has been entirely rewritten over the copperplate interface
> and extended in terms of emulated services.

Ok, so please use another name so that will no confusion.


Thanks,

Leopold


[1] http://xenomai.org/installing-xenomai-3-x/#Installing_the_Mercury_core

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150123/9182e533/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/23/2015 06:02 PM, Leopold Palomo-Avellaneda wrote:
> El Divendres, 23 de gener de 2015, a les 17:04:37, Philippe Gerum va escriure:
>> On 01/23/2015 01:09 PM, Leopold Palomo-Avellaneda wrote:
>>> Hi,
>>>
>>> now that I have some kernel to boot, I would like to ask some aspects of
>>> Xenomai-3 in order to package it.
>>>
>>> Reading the documentation, now the new libxenomai could use two kind of
>>> kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
>>
>> Mercury does not require preempt-rt. In some cases, one may want the API
>> emulation capabilities without actually having real-time requirements.
> 
> Ops, Philippe  the documentation [1] says that Mercury:
> 
>> Your kernel should at least provide high resolution timer support 
> (CONFIG_HIGH_RES_TIMERS), and likely complete preemption (PREEMPT_RT) if your 
> application requires short and bounded latencies.
> 
> if your application .. it's not mandatory, right?. So, you can use it in any 
> kernel that at least has CONFIG_HIGH_RES_TIMERS

Yes. Complete preemption is only required to meet real-time requirements.

> 
>>> 1) Is it possible to have _only_ one library (binary) that uses one or
>>> another kernel in function which is running?
>>
>> No. Definitely not.
> 
> Ok, it's too difficult to have it? Same lib that in runtime select the interface 
> to use? So, then someone could provide a binary, that depends on the kernel 
> will work with cobalt or mercury. The packagers would have the life better.
> 

Sure, but the maintainers would go nuts, which would not help the
packagers in the end. Not to speak of the crappy performances on low-end
hardware, due to the extra levels of encapsulation/indirection required.
I don't see any reasonable way to implement this sanely and efficiently.
We are chasing micro-second level optimization in some cases in the
code, for running on CPUs with not-that-fast caches. In this user vs
packager/maintainer trade-off, user must prevail.

>>
>>> 2) If not, as we must recompile the library, all the programs linked
>>> against must be recompiled or if it's binary compatible?
>>
>> Can't have the same ABI. Two separate builds are required. 
> 
> :-( it makes sense if they have different names? -c vc -m or whatever?

The same way we don't have /lib/libc64.so but /lib64/libc.so, I would
rather suggest to use a different install root.

>>
>>> 3) Comparing the files generated (xenomai-2.x vs xenomai-3.x, if you bump
>>> the sonames of libanalogy, libpsos and libvxworks you could have (I
>>> guess) both binary versions installed in the same box.
>>
>> This would make sense, but only for libs. 
> 
> of course.
> 
>> Scripts, includes would conflict.
> 
> another package shared is possible? (xenomai-tools, xenomai-scripts, ....)
> 
> If you have different library names, pkg-config could solve that.
> 
> 
>>> 4) Why the libvxworks has lower soname version in 2.6.4 than in 3.0.0?
>>
>> Because it has been entirely rewritten over the copperplate interface
>> and extended in terms of emulated services.
> 
> Ok, so please use another name so that will no confusion.
> 

Why that? It is still the one and only VxWorks emulator shipped with
Xenomai.

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Fri, Jan 23, 2015 at 05:50:07PM +0100, Leopold Palomo-Avellaneda wrote:
> El Divendres, 23 de gener de 2015, a les 16:52:31, Gilles Chanteperdrix va 
> escriure:
> > On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > now that I have some kernel to boot, I would like to ask some aspects of
> > > Xenomai-3 in order to package it.
> > > 
> > > Reading the documentation, now the new libxenomai could use two kind of
> > > kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> > 
> > a preempt_rt kernel is a patched kernel too.
> 
> Writing the email I thought, both are patches, but I thought preempt_rt was 
> integrated in mainline.

No it is not.

>  
> > > 1) Is it possible to have _only_ one library (binary) that uses one or
> > > another kernel in function which is running?
> > 
> > No, you could want to run a kernel with both patches. So basing the
> > decision on which patch you are running does not make sense.
> 
> I don't want to run a kernel with both patches. It has no sense. But I could 
> have binary packages that could work with both kernels. That was my idea.

To the contrary, it has a lot of sense. You get one grade of
real-time for cobalt task, and another grade of real-time for tasks
scheduled by Linux.


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150123/841ae70d/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Fri, Jan 23, 2015 at 06:24:41PM +0100, Philippe Gerum wrote:
> On 01/23/2015 06:02 PM, Leopold Palomo-Avellaneda wrote:
> > El Divendres, 23 de gener de 2015, a les 17:04:37, Philippe Gerum va escriure:
> >> On 01/23/2015 01:09 PM, Leopold Palomo-Avellaneda wrote:
> >>> Hi,
> >>>
> >>> now that I have some kernel to boot, I would like to ask some aspects of
> >>> Xenomai-3 in order to package it.
> >>>
> >>> Reading the documentation, now the new libxenomai could use two kind of
> >>> kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> >>
> >> Mercury does not require preempt-rt. In some cases, one may want the API
> >> emulation capabilities without actually having real-time requirements.
> > 
> > Ops, Philippe  the documentation [1] says that Mercury:
> > 
> >> Your kernel should at least provide high resolution timer support 
> > (CONFIG_HIGH_RES_TIMERS), and likely complete preemption (PREEMPT_RT) if your 
> > application requires short and bounded latencies.
> > 
> > if your application .. it's not mandatory, right?. So, you can use it in any 
> > kernel that at least has CONFIG_HIGH_RES_TIMERS
> 
> Yes. Complete preemption is only required to meet real-time requirements.
> 
> > 
> >>> 1) Is it possible to have _only_ one library (binary) that uses one or
> >>> another kernel in function which is running?
> >>
> >> No. Definitely not.
> > 
> > Ok, it's too difficult to have it? Same lib that in runtime select the interface 
> > to use? So, then someone could provide a binary, that depends on the kernel 
> > will work with cobalt or mercury. The packagers would have the life better.
> > 
> 
> Sure, but the maintainers would go nuts, which would not help the
> packagers in the end. Not to speak of the crappy performances on low-end
> hardware, due to the extra levels of encapsulation/indirection required.
> I don't see any reasonable way to implement this sanely and efficiently.
> We are chasing micro-second level optimization in some cases in the
> code, for running on CPUs with not-that-fast caches. In this user vs
> packager/maintainer trade-off, user must prevail.

The maintainers are already nuts. Due to the performance impact, it
would have to be something optional. Also, it implies two build
trees of Xenomai. And finally, it looks like a very specific need,
so unless a lot of users are asking for it, there is really no
reason to have to write and more importantly maintain such code. So,
if you need this, by all means, implement it on your side. Maybe
some day a lot of users will ask for it.

On the binary compatibility side, I am not sure cobalt's
pthread_mutex_lock is not binary compatible with glibc's
pthread_mutex_lock. I would tend to think that the same goes for all
emulated OSes API calls, unless we use inlines.


-- 
					    Gilles.

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/23/2015 06:47 PM, Gilles Chanteperdrix wrote:
> On Fri, Jan 23, 2015 at 06:24:41PM +0100, Philippe Gerum wrote:
>> On 01/23/2015 06:02 PM, Leopold Palomo-Avellaneda wrote:
>>> El Divendres, 23 de gener de 2015, a les 17:04:37, Philippe Gerum va escriure:
>>>> On 01/23/2015 01:09 PM, Leopold Palomo-Avellaneda wrote:
>>>>> Hi,
>>>>>
>>>>> now that I have some kernel to boot, I would like to ask some aspects of
>>>>> Xenomai-3 in order to package it.
>>>>>
>>>>> Reading the documentation, now the new libxenomai could use two kind of
>>>>> kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
>>>>
>>>> Mercury does not require preempt-rt. In some cases, one may want the API
>>>> emulation capabilities without actually having real-time requirements.
>>>
>>> Ops, Philippe  the documentation [1] says that Mercury:
>>>
>>>> Your kernel should at least provide high resolution timer support 
>>> (CONFIG_HIGH_RES_TIMERS), and likely complete preemption (PREEMPT_RT) if your 
>>> application requires short and bounded latencies.
>>>
>>> if your application .. it's not mandatory, right?. So, you can use it in any 
>>> kernel that at least has CONFIG_HIGH_RES_TIMERS
>>
>> Yes. Complete preemption is only required to meet real-time requirements.
>>
>>>
>>>>> 1) Is it possible to have _only_ one library (binary) that uses one or
>>>>> another kernel in function which is running?
>>>>
>>>> No. Definitely not.
>>>
>>> Ok, it's too difficult to have it? Same lib that in runtime select the interface 
>>> to use? So, then someone could provide a binary, that depends on the kernel 
>>> will work with cobalt or mercury. The packagers would have the life better.
>>>
>>
>> Sure, but the maintainers would go nuts, which would not help the
>> packagers in the end. Not to speak of the crappy performances on low-end
>> hardware, due to the extra levels of encapsulation/indirection required.
>> I don't see any reasonable way to implement this sanely and efficiently.
>> We are chasing micro-second level optimization in some cases in the
>> code, for running on CPUs with not-that-fast caches. In this user vs
>> packager/maintainer trade-off, user must prevail.
> 
> The maintainers are already nuts. Due to the performance impact, it
> would have to be something optional. Also, it implies two build
> trees of Xenomai. And finally, it looks like a very specific need,
> so unless a lot of users are asking for it, there is really no
> reason to have to write and more importantly maintain such code. So,
> if you need this, by all means, implement it on your side. Maybe
> some day a lot of users will ask for it.
> 
> On the binary compatibility side, I am not sure cobalt's
> pthread_mutex_lock is not binary compatible with glibc's
> pthread_mutex_lock. I would tend to think that the same goes for all
> emulated OSes API calls, unless we use inlines.
> 
> 

The issue is with copperplate, not libcobalt.

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

A Divendres, 23 de gener de 2015, Philippe Gerum va escriure:
[...]

> >>> 1) Is it possible to have _only_ one library (binary) that uses one or
> >>> another kernel in function which is running?
> >> 
> >> No. Definitely not.
> > 
> > Ok, it's too difficult to have it? Same lib that in runtime select the
> > interface to use? So, then someone could provide a binary, that depends
> > on the kernel will work with cobalt or mercury. The packagers would have
> > the life better.
> 
> Sure, but the maintainers would go nuts, which would not help the
> packagers in the end. Not to speak of the crappy performances on low-end
> hardware, due to the extra levels of encapsulation/indirection required.
> I don't see any reasonable way to implement this sanely and efficiently.
> We are chasing micro-second level optimization in some cases in the
> code, for running on CPUs with not-that-fast caches. In this user vs
> packager/maintainer trade-off, user must prevail.
>
> >>> 2) If not, as we must recompile the library, all the programs linked
> >>> against must be recompiled or if it's binary compatible?
> >> 
> >> Can't have the same ABI. Two separate builds are required.
> >> 
> > :-( it makes sense if they have different names? -c vc -m or whatever?
> 
> The same way we don't have /lib/libc64.so but /lib64/libc.so, I would
> rather suggest to use a different install root.


So, the situation is that we must have two libraries, that are compiled with 
two main differences (mercury, cobalt).

To have it in different directories is not an easy task if we want to put in 
the main distros. Also, ldd should find it, and for it, it should be int the 
standard ldd paths.

I think that it could be a good idea to add some kind of suffix/prefix to the 
libraries. So, simply looking the files one can know if they are working with 
Mercury or Cobalt.

As, they are not binary compatible, and the programs must to be recompile, you 
can solve it with pkg-config.

The main idea is that we could package xenomai-3, thinking that we could have 
the two main versions (cobalt, mercury) installed in the same machine.

Are they same the same includes? is it protected with ifdef?
 
If yes, then the scripts, includes, could go to a common package and we could 
have some kind of libxenomai-cobalt (libxenomai-c) and libxenomai-
mercury(libxenomai-m) for example.

> > 
> > Ok, so please use another name so that will no confusion.
> 
> Why that? It is still the one and only VxWorks emulator shipped with
> Xenomai.

but xenomai-3. We could add libvxworks-c ...

It's just a propouse...

Best regadrs,

Leopold

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

A Divendres, 23 de gener de 2015, Gilles Chanteperdrix va escriure:
> On Fri, Jan 23, 2015 at 05:50:07PM +0100, Leopold Palomo-Avellaneda wrote:
> > El Divendres, 23 de gener de 2015, a les 16:52:31, Gilles Chanteperdrix
> > va
> > 
> > escriure:
> > > On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > Hi,
> > > > 
> > > > now that I have some kernel to boot, I would like to ask some aspects
> > > > of Xenomai-3 in order to package it.
> > > > 
> > > > Reading the documentation, now the new libxenomai could use two kind
> > > > of kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
> > > 
> > > a preempt_rt kernel is a patched kernel too.
> > 
> > Writing the email I thought, both are patches, but I thought preempt_rt
> > was integrated in mainline.
> 
> No it is not.
> 
> > > > 1) Is it possible to have _only_ one library (binary) that uses one
> > > > or another kernel in function which is running?
> > > 
> > > No, you could want to run a kernel with both patches. So basing the
> > > decision on which patch you are running does not make sense.
> > 
> > I don't want to run a kernel with both patches. It has no sense. But I
> > could have binary packages that could work with both kernels. That was
> > my idea.
> 
> To the contrary, it has a lot of sense. You get one grade of
> real-time for cobalt task, and another grade of real-time for tasks
> scheduled by Linux.

Maybe ... it could be interesting as an experiment.

Just for curiosity, have you had the test comparing in mercury and cobalt in 
the same harware with the same problem?

Best regards,

Leopold

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/24/2015 06:56 PM, Leopold Palomo-Avellaneda wrote:
> A Divendres, 23 de gener de 2015, Gilles Chanteperdrix va escriure:
>> On Fri, Jan 23, 2015 at 05:50:07PM +0100, Leopold Palomo-Avellaneda wrote:
>>> El Divendres, 23 de gener de 2015, a les 16:52:31, Gilles Chanteperdrix
>>> va
>>>
>>> escriure:
>>>> On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold Palomo-Avellaneda 
> wrote:
>>>>> Hi,
>>>>>
>>>>> now that I have some kernel to boot, I would like to ask some aspects
>>>>> of Xenomai-3 in order to package it.
>>>>>
>>>>> Reading the documentation, now the new libxenomai could use two kind
>>>>> of kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
>>>>
>>>> a preempt_rt kernel is a patched kernel too.
>>>
>>> Writing the email I thought, both are patches, but I thought preempt_rt
>>> was integrated in mainline.
>>
>> No it is not.
>>
>>>>> 1) Is it possible to have _only_ one library (binary) that uses one
>>>>> or another kernel in function which is running?
>>>>
>>>> No, you could want to run a kernel with both patches. So basing the
>>>> decision on which patch you are running does not make sense.
>>>
>>> I don't want to run a kernel with both patches. It has no sense. But I
>>> could have binary packages that could work with both kernels. That was
>>> my idea.
>>
>> To the contrary, it has a lot of sense. You get one grade of
>> real-time for cobalt task, and another grade of real-time for tasks
>> scheduled by Linux.
> 
> Maybe ... it could be interesting as an experiment.

No, it's not just an experiment. I'm aware of production setups which
have been running this configuration since 2009. I did the mixed
ipipe+prempt-rt port for them.

> 
> Just for curiosity, have you had the test comparing in mercury and cobalt in 
> the same harware with the same problem?
> 

Yes, without any issue. Just use two different install roots, one for
cobalt, the other for mercury.

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

But I was thinking in performance aspects comparing a system with cobalt vs a system with mercury.

On 25 de gener de 2015 10.14.57 CET, Philippe Gerum <rpm@xenomai.org> wrote:
>On 01/24/2015 06:56 PM, Leopold Palomo-Avellaneda wrote:
>> A Divendres, 23 de gener de 2015, Gilles Chanteperdrix va escriure:
>>> On Fri, Jan 23, 2015 at 05:50:07PM +0100, Leopold Palomo-Avellaneda
>wrote:
>>>> El Divendres, 23 de gener de 2015, a les 16:52:31, Gilles
>Chanteperdrix
>>>> va
>>>>
>>>> escriure:
>>>>> On Fri, Jan 23, 2015 at 01:09:41PM +0100, Leopold
>Palomo-Avellaneda 
>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> now that I have some kernel to boot, I would like to ask some
>aspects
>>>>>> of Xenomai-3 in order to package it.
>>>>>>
>>>>>> Reading the documentation, now the new libxenomai could use two
>kind
>>>>>> of kernels: the patched one (Cobalt) or the preempt_rt (Mercury).
>>>>>
>>>>> a preempt_rt kernel is a patched kernel too.
>>>>
>>>> Writing the email I thought, both are patches, but I thought
>preempt_rt
>>>> was integrated in mainline.
>>>
>>> No it is not.
>>>
>>>>>> 1) Is it possible to have _only_ one library (binary) that uses
>one
>>>>>> or another kernel in function which is running?
>>>>>
>>>>> No, you could want to run a kernel with both patches. So basing
>the
>>>>> decision on which patch you are running does not make sense.
>>>>
>>>> I don't want to run a kernel with both patches. It has no sense.
>But I
>>>> could have binary packages that could work with both kernels. That
>was
>>>> my idea.
>>>
>>> To the contrary, it has a lot of sense. You get one grade of
>>> real-time for cobalt task, and another grade of real-time for tasks
>>> scheduled by Linux.
>> 
>> Maybe ... it could be interesting as an experiment.
>
>No, it's not just an experiment. I'm aware of production setups which
>have been running this configuration since 2009. I did the mixed
>ipipe+prempt-rt port for them.
>
>> 
>> Just for curiosity, have you had the test comparing in mercury and
>cobalt in 
>> the same harware with the same problem?
>> 
>
>Yes, without any issue. Just use two different install roots, one for
>cobalt, the other for mercury.
>
>-- 
>Philippe.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/25/2015 12:14 PM, Leopold Palomo-Avellaneda wrote:
> But I was thinking in performance aspects comparing a system with cobalt
> vs a system with mercury.
> 

Yes, but the results are now outdated (2011). This said, such benchmark
hardly reflected a use case. It was more a Xenomai 2.6.x vs 3.x analysis
of basic mechanisms (event notification, serialization, buffer exchange
etc) for measuring the impact of moving most of the real-time API
implementation to user-space, only keeping the core resource management
in kernel space. It proved to be positive.

Mercury vs Cobalt was only a by-product of those tests, specifically on
x86_32.

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Diumenge, 25 de gener de 2015, a les 19:10:16, Philippe Gerum va escriure:
> On 01/25/2015 12:14 PM, Leopold Palomo-Avellaneda wrote:
> > But I was thinking in performance aspects comparing a system with cobalt
> > vs a system with mercury.
> 
> Yes, but the results are now outdated (2011). This said, such benchmark
> hardly reflected a use case. It was more a Xenomai 2.6.x vs 3.x analysis
> of basic mechanisms (event notification, serialization, buffer exchange
> etc) for measuring the impact of moving most of the real-time API
> implementation to user-space, only keeping the core resource management
> in kernel space. It proved to be positive.
> 
> Mercury vs Cobalt was only a by-product of those tests, specifically on
> x86_32.

After this thread, I think more firmly that the libs should be renamed in the 
manner that they could be co-installed in the same root, standard places.

Please upstream, could you think about it?

Leopold
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150125/d1eca85b/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Sun, Jan 25, 2015 at 07:43:21PM +0100, Leopold Palomo-Avellaneda wrote:
> El Diumenge, 25 de gener de 2015, a les 19:10:16, Philippe Gerum va escriure:
> > On 01/25/2015 12:14 PM, Leopold Palomo-Avellaneda wrote:
> > > But I was thinking in performance aspects comparing a system with cobalt
> > > vs a system with mercury.
> > 
> > Yes, but the results are now outdated (2011). This said, such benchmark
> > hardly reflected a use case. It was more a Xenomai 2.6.x vs 3.x analysis
> > of basic mechanisms (event notification, serialization, buffer exchange
> > etc) for measuring the impact of moving most of the real-time API
> > implementation to user-space, only keeping the core resource management
> > in kernel space. It proved to be positive.
> > 
> > Mercury vs Cobalt was only a by-product of those tests, specifically on
> > x86_32.
> 
> After this thread, I think more firmly that the libs should be renamed in the 
> manner that they could be co-installed in the same root, standard places.
> 
> Please upstream, could you think about it?

This is a decision that upstream should not impose to all users.
Only users with your specific needs should do what you want. And
in fact, I believe simply using the configure script options, it is
possible to install libraries in different directories. Maybe even
the --program* options apply to libraries too.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/471515b7/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 13:08:24, Gilles Chanteperdrix va 
escriure:
> On Sun, Jan 25, 2015 at 07:43:21PM +0100, Leopold Palomo-Avellaneda wrote:
> > El Diumenge, 25 de gener de 2015, a les 19:10:16, Philippe Gerum va 
escriure:
> > > On 01/25/2015 12:14 PM, Leopold Palomo-Avellaneda wrote:
> > > > But I was thinking in performance aspects comparing a system with
> > > > cobalt
> > > > vs a system with mercury.
> > > 
> > > Yes, but the results are now outdated (2011). This said, such benchmark
> > > hardly reflected a use case. It was more a Xenomai 2.6.x vs 3.x analysis
> > > of basic mechanisms (event notification, serialization, buffer exchange
> > > etc) for measuring the impact of moving most of the real-time API
> > > implementation to user-space, only keeping the core resource management
> > > in kernel space. It proved to be positive.
> > > 
> > > Mercury vs Cobalt was only a by-product of those tests, specifically on
> > > x86_32.
> > 
> > After this thread, I think more firmly that the libs should be renamed in
> > the manner that they could be co-installed in the same root, standard
> > places.
> > 
> > Please upstream, could you think about it?
> 
> This is a decision that upstream should not impose to all users.

Interesting sentence. You are developing a new version with an step forward. 
You have reworked libraries and for instance libxenomai, libnative, librtdm 
doesn't exists in Xenomai-3. Also you have introduced new ones (libalchemy, 
libcobalt, libcopperplate, libtrank. 

You have developed xenomai in two main group of libraries (or use a cobalt 
kernel or a mercury kernel) and are you saying that you cannot impose to all 
users a suffix or something that the users could have both version co-
installed in standards places in their systems?

> Only users with your specific needs should do what you want. 

Maybe I'm wrong. But after reading this thread I understood that to have a 
kernel with both patches (i-pipe and preempt_rt) and, I understand, Xenomai-3 
with the two versions could be a very interesting system to work on.

For instance, I'm in the robotics field, and after that mails I thought that 
it could be a good solution that fit the cases where you have several loops, 
with several rates with different importance.

> And
> in fact, I believe simply using the configure script options, it is
> possible to install libraries in different directories. Maybe even
> the --program* options apply to libraries too.

Not really. It's nice if you a have a package.

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/f1f68980/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Daniele Nicolodi]

Hello Leopold,

it seems to me that you are missing a few key points.

On 26/01/15 13:39, Leopold Palomo-Avellaneda wrote:
>> This is a decision that upstream should not impose to all users.
> 
> Interesting sentence. You are developing a new version with an step forward. 
> You have reworked libraries and for instance libxenomai, libnative, librtdm 
> doesn't exists in Xenomai-3. Also you have introduced new ones (libalchemy, 
> libcobalt, libcopperplate, libtrank. 
> 
> You have developed xenomai in two main group of libraries (or use a cobalt 
> kernel or a mercury kernel) and are you saying that you cannot impose to all 
> users a suffix or something that the users could have both version co-
> installed in standards places in their systems?

The APIs provided by Xenomai on top of the regular Linux kernel
interface are only for smoothing the porting of legacy application
written using the APIs peculiar to other RTOS and which Xenomai implements.

Ideally any new development should be done with the POSIX APIs.

The choice between cobalt or mercury is demanded by the real time
requirements of the specific application and the target hardware. It
cannot be a user configuration.

>> Only users with your specific needs should do what you want. 
> 
> Maybe I'm wrong. But after reading this thread I understood that to have a 
> kernel with both patches (i-pipe and preempt_rt) and, I understand, Xenomai-3 
> with the two versions could be a very interesting system to work on.
> 
> For instance, I'm in the robotics field, and after that mails I thought that 
> it could be a good solution that fit the cases where you have several loops, 
> with several rates with different importance.

Several loops with several rates with different importance must be
mapped to tasks with different priorities. It does not make sense to
have them mapped to threads running in different modes.

> Not really. It's nice if you a have a package.

If this if of such prominent importance for you, I suggest it to code
this yourself. It does not make sense to argue with upstream that this
feature is useful, especially with arguments that seems to indicate that
you do not have a complete understanding of the issue, neither that you
tried it and it effectively solves some real problems.

Cheers,
Daniele

Re: [Xenomai] Packaging Xenomai-3

[Philippe Gerum]

On 01/26/2015 01:39 PM, Leopold Palomo-Avellaneda wrote:

> Maybe I'm wrong. But after reading this thread I understood that to have a 
> kernel with both patches (i-pipe and preempt_rt) and, I understand, Xenomai-3 
> with the two versions could be a very interesting system to work on.
> 
> For instance, I'm in the robotics field, and after that mails I thought that 
> it could be a good solution that fit the cases where you have several loops, 
> with several rates with different importance.
> 

You are missing an important point: Xenomai 3 over Mercury is about
running non-POSIX RTOS APIs over a native kernel (with or without
preempt-rt, this is orthogonal to the issue).

All projects using mixed dual kernel + native preemption systems I came
to know wanted:

- guaranteed low latency figures from the dual kernel side, regardless
of the API, regardless of the regular kernel activity, with the least
possible overhead on the latter.
- POSIX interface with short and bounded response times from the native
preemption side, for talking to the regular driver stack.

Non POSIX API with Xenomai either means: 1) the former native API (aka
"alchemy"), 2) some RTOS emulator such as VxWorks or pSOS. People
running the former native API already will most likely stay with the
dual kernel side, which is how they currently run it over Xenomai 2.6,
unless they move to a pure native preemption system, in which case the
original point is moot.

Therefore, your proposal mainly addresses the issue of running a mixed
configuration, with some Mercury-based application(s) ported from a
traditional RTOS to linux, and other application(s) running over Cobalt
in dual kernel mode, concurrently on the same system. People who just
want to run POSIX apps over a native kernel don't need Xenomai 3. In
short, the potential user base for the mixed setup as described is quite
small.

With that in mind, using a mixed installation root between Mercury and
Cobalt also means that any 2.x Makefile currently using "xeno-config"
would have to be fixed up, to reflect the new suffixed path or call
pkg-config to retrieve it, whatever fits. We have been advertising
xeno-config since years, as a mean to stay away from installation
specifics, so this would be quite wrong to end up asking people to run
xeno-config-cobalt or xeno-config-mercury.

As I mentioned already, we won't go for single binaries running over
both cores, the performance and maintenance impact would be a nightmare.
Since all our build system is autoconfiscated, you can pick any root
prefix that makes sense, and even fine tune every installation directory
already (lib, include, bin etc). This means that having multiple roots
is definitely a non-issue, and does not introduce any limitation.

I don't buy the "suffix to disambiguate" argument either:
/usr/lib/libvxworks-m.so is not clearer than
/usr/lib/mercury/libvxworks.so, or
/usr/xenomai/mercury/lib/libvxworks.so. And this does not even work
better with /usr/lib/libvxworks-mercury.so.

Besides, there is no shortage of ways to find out which Xenomai
configuration your build system and even your application is currently
depending on. The only requirement is to query the right xeno-config
script or application, which may be as simple as setting the PATH
variable appropriately for your setup:

$ xeno-config --core
mercury
$ xeno-config --cflags
-I/usr/xenomai/mercury/include/mercury -I/usr/xenomai/mercury/include
-D_GNU_SOURCE -D_REENTRANT -D__MERCURY__
$ latency --dump-config
CONFIG_MMU=1
CONFIG_SMP=1
CONFIG_XENO_ASYNC_CANCEL=1
CONFIG_XENO_BUILD_ARGS=" '-prefix=/usr/xenomai/mercury'
'--disable-doc-install' '--enable-async-cancel' '--enable-lores-clock'
'--enable-debug=full' '--enable-smp' '--enable-tls'
'--with-core=mercury' '--enable-registry' '--enable-pshared'
'--enable-condvar-workaround'"
CONFIG_XENO_BUILD_STRING="x86_64-unknown-linux-gnu"
CONFIG_XENO_COMPILER="gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) "
CONFIG_XENO_DEBUG=1
CONFIG_XENO_DEBUG_FULL=1
CONFIG_XENO_DEFAULT_PERIOD=100000
CONFIG_XENO_FORTIFY=1
CONFIG_XENO_HOST_STRING="x86_64-unknown-linux-gnu"
CONFIG_XENO_MERCURY=1
CONFIG_XENO_PREFIX="/usr/xenomai/mercury"
CONFIG_XENO_PSHARED=1
CONFIG_XENO_REGISTRY=1
CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
CONFIG_XENO_REVISION_LEVEL=10
CONFIG_XENO_SANITY=1
CONFIG_XENO_TLS_MODEL="initial-exec"
CONFIG_XENO_UAPI_LEVEL=10
CONFIG_XENO_VALGRIND_API=1
CONFIG_XENO_VERSION_MAJOR=2
CONFIG_XENO_VERSION_MINOR=99
CONFIG_XENO_VERSION_NAME="Exact Zero"
CONFIG_XENO_VERSION_STRING="3.0-rc2"
CONFIG_XENO_WORKAROUND_CONDVAR_PI=1
CONFIG_XENO_X86_VSYSCALL=1
---
CONFIG_XENO_ARM_SA1100 is OFF
CONFIG_XENO_ARM_TSC_TYPE is OFF
CONFIG_XENO_COBALT is OFF
CONFIG_XENO_COPPERPLATE_CLOCK_RESTRICTED is OFF
CONFIG_XENO_CPU_XSC3 is OFF
CONFIG_XENO_LIBS_DLOPEN is OFF
CONFIG_XENO_LORES_CLOCK_DISABLED is OFF
CONFIG_XENO_RAW_CLOCK_ENABLED is OFF
CONFIG_XENO_TLSF is OFF

-- 
Philippe.

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Mon, Jan 26, 2015 at 01:39:31PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dilluns, 26 de gener de 2015, a les 13:08:24, Gilles Chanteperdrix va 
> escriure:
> > On Sun, Jan 25, 2015 at 07:43:21PM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Diumenge, 25 de gener de 2015, a les 19:10:16, Philippe Gerum va 
> escriure:
> > > > On 01/25/2015 12:14 PM, Leopold Palomo-Avellaneda wrote:
> > > > > But I was thinking in performance aspects comparing a system with
> > > > > cobalt
> > > > > vs a system with mercury.
> > > > 
> > > > Yes, but the results are now outdated (2011). This said, such benchmark
> > > > hardly reflected a use case. It was more a Xenomai 2.6.x vs 3.x analysis
> > > > of basic mechanisms (event notification, serialization, buffer exchange
> > > > etc) for measuring the impact of moving most of the real-time API
> > > > implementation to user-space, only keeping the core resource management
> > > > in kernel space. It proved to be positive.
> > > > 
> > > > Mercury vs Cobalt was only a by-product of those tests, specifically on
> > > > x86_32.
> > > 
> > > After this thread, I think more firmly that the libs should be renamed in
> > > the manner that they could be co-installed in the same root, standard
> > > places.
> > > 
> > > Please upstream, could you think about it?
> > 
> > This is a decision that upstream should not impose to all users.
> 
> Interesting sentence. You are developing a new version with an step forward. 
> You have reworked libraries and for instance libxenomai, libnative, librtdm 
> doesn't exists in Xenomai-3. Also you have introduced new ones (libalchemy, 
> libcobalt, libcopperplate, libtrank. 
> 
> You have developed xenomai in two main group of libraries (or use a cobalt 
> kernel or a mercury kernel) and are you saying that you cannot impose to all 
> users a suffix or something that the users could have both version co-
> installed in standards places in their systems?

What I am saying is that Xenomai user-space support is delivered
with a configure script giving users a choice to install things
wherever they want. I do not see any reason to hardcode a particular
choice in xenomai itself.

> 
> > Only users with your specific needs should do what you want. 
> 
> Maybe I'm wrong. But after reading this thread I understood that to have a 
> kernel with both patches (i-pipe and preempt_rt) and, I understand, Xenomai-3 
> with the two versions could be a very interesting system to work on.

Sure, but in that case you would have two xenomai build trees, that
you can configure with different options so that they do not collide
once installed.

> 
> For instance, I'm in the robotics field, and after that mails I thought that 
> it could be a good solution that fit the cases where you have several loops, 
> with several rates with different importance.
> 
> > And
> > in fact, I believe simply using the configure script options, it is
> > possible to install libraries in different directories. Maybe even
> > the --program* options apply to libraries too.
> 
> Not really. 

Do you dismiss it because you have tried and it did not work?
Because if that is the case, we would be interested to see any error
message you got, and help solve them.

> It's nice if you a have a package.

What has this to do with anything ? A "package" is just a script
which runs configure with some options chosen to fit a distribution
then make and make install. If you are the Debian maintainer then it
is your job to choose the options to pass to configure to fit the
need of Debian. But there is no reason to hardcode these options in
the upstream package, so that other distributions can choose other
options.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/6459bff5/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 14:38:00, Daniele Nicolodi va escriure:
> Hello Leopold,
> 
> it seems to me that you are missing a few key points.

Probably. Thanks for helping me to understand it.

> On 26/01/15 13:39, Leopold Palomo-Avellaneda wrote:
> >> This is a decision that upstream should not impose to all users.
> > 
> > Interesting sentence. You are developing a new version with an step
> > forward. You have reworked libraries and for instance libxenomai,
> > libnative, librtdm doesn't exists in Xenomai-3. Also you have introduced
> > new ones (libalchemy, libcobalt, libcopperplate, libtrank.
> > 
> > You have developed xenomai in two main group of libraries (or use a cobalt
> > kernel or a mercury kernel) and are you saying that you cannot impose to
> > all users a suffix or something that the users could have both version
> > co- installed in standards places in their systems?
> 
> The APIs provided by Xenomai on top of the regular Linux kernel
> interface are only for smoothing the porting of legacy application
> written using the APIs peculiar to other RTOS and which Xenomai implements.
> 
> Ideally any new development should be done with the POSIX APIs.
> 
> The choice between cobalt or mercury is demanded by the real time
> requirements of the specific application and the target hardware. It
> cannot be a user configuration.

I'm not talking about user configuration. AFAIK the idea is that you can 
compile and link your code (without any change) again the library built to 
work cobalt or mercury. No that the user config it in runtime.

> >> Only users with your specific needs should do what you want.
> > 
> > Maybe I'm wrong. But after reading this thread I understood that to have a
> > kernel with both patches (i-pipe and preempt_rt) and, I understand,
> > Xenomai-3 with the two versions could be a very interesting system to
> > work on.
> > 
> > For instance, I'm in the robotics field, and after that mails I thought
> > that it could be a good solution that fit the cases where you have
> > several loops, with several rates with different importance.
> 
> Several loops with several rates with different importance must be
> mapped to tasks with different priorities. It does not make sense to
> have them mapped to threads running in different modes.

this is one option. But many times you work on software provides by others and 
modify it is not affordable.

> > Not really. It's nice if you a have a package.
> 
> If this if of such prominent importance for you, I suggest it to code
> this yourself. It does not make sense to argue with upstream that this
> feature is useful, especially with arguments that seems to indicate that
> you do not have a complete understanding of the issue, neither that you
> tried it and it effectively solves some real problems.

Maybe I didn't choose a perfect reference about with robotic field. But I 
don't think that it's fair to disqualifying my arguments me about my propose.

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/3a66b092/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Daniele Nicolodi]

On 26/01/15 15:17, Leopold Palomo-Avellaneda wrote:
> I'm not talking about user configuration. AFAIK the idea is that you can 
> compile and link your code (without any change) again the library built to 
> work cobalt or mercury. No that the user config it in runtime.

I don't see the problem in simply using a different install path for the
two libraries then. As Gilles repeated a few times now, this is
perfectly supported by the status quo.

Cheers,
Daniele

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 15:01:27, Philippe Gerum va escriure:
> On 01/26/2015 01:39 PM, Leopold Palomo-Avellaneda wrote:
> > Maybe I'm wrong. But after reading this thread I understood that to have a
> > kernel with both patches (i-pipe and preempt_rt) and, I understand,
> > Xenomai-3 with the two versions could be a very interesting system to
> > work on.
> > 
> > For instance, I'm in the robotics field, and after that mails I thought
> > that it could be a good solution that fit the cases where you have
> > several loops, with several rates with different importance.
> 
> You are missing an important point: Xenomai 3 over Mercury is about
> running non-POSIX RTOS APIs over a native kernel (with or without
> preempt-rt, this is orthogonal to the issue).

this is an interesting point.

[...]

> 
> Therefore, your proposal mainly addresses the issue of running a mixed
> configuration, with some Mercury-based application(s) ported from a
> traditional RTOS to linux, and other application(s) running over Cobalt
> in dual kernel mode, concurrently on the same system. People who just
> want to run POSIX apps over a native kernel don't need Xenomai 3. In
> short, the potential user base for the mixed setup as described is quite
> small.
> 
> With that in mind, using a mixed installation root between Mercury and
> Cobalt also means that any 2.x Makefile currently using "xeno-config"
> would have to be fixed up, to reflect the new suffixed path or call
> pkg-config to retrieve it, whatever fits. We have been advertising
> xeno-config since years, as a mean to stay away from installation
> specifics, so this would be quite wrong to end up asking people to run
> xeno-config-cobalt or xeno-config-mercury.

xeno-config --with-core=cobalt/mercury

could be a solution. But, some default core should be defined.

> As I mentioned already, we won't go for single binaries running over
> both cores, the performance and maintenance impact would be a nightmare.

Yes, two types of binaries. Your argumentation was clear.

> Since all our build system is autoconfiscated, you can pick any root
> prefix that makes sense, and even fine tune every installation directory
> already (lib, include, bin etc). This means that having multiple roots
> is definitely a non-issue, and does not introduce any limitation.
> 
> I don't buy the "suffix to disambiguate" argument either:
> /usr/lib/libvxworks-m.so is not clearer than
> /usr/lib/mercury/libvxworks.so, or
> /usr/xenomai/mercury/lib/libvxworks.so. And this does not even work
> better with /usr/lib/libvxworks-mercury.so.
> 
> Besides, there is no shortage of ways to find out which Xenomai
> configuration your build system and even your application is currently
> depending on. 

well, I usually ask to ldd. So, if I have a binary and I run:

ldd /usr/local/lib/libcpp4ec.so
	linux-vdso.so.1 (0x00007fffee0dc000)
	libsoemrt.so.1.3.0 => /usr/local/lib/libsoemrt.so.1.3.0 
(0x00007feea2352000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007feea214a000)
	libnative.so.3 => /usr/lib/libnative.so.3 (0x00007feea1f40000)
	libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0x00007feea1d39000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x00007feea1b1c000)
	libpugixml.so.1 => /usr/lib/x86_64-linux-gnu/libpugixml.so.1 
(0x00007feea18e7000)
	librtdm.so.1 => /usr/lib/librtdm.so.1 (0x00007feea16e5000)

for example, if I had libvxworks-cobalt there, I knew that my binary was built 
against xenomai with cobalt.


> The only requirement is to query the right xeno-config
> script or application, which may be as simple as setting the PATH
> variable appropriately for your setup:
> 
> $ xeno-config --core
> mercury
> $ xeno-config --cflags

[...]

Yes, I liked. I thought that it was a good solution but I don't know if it's 
fhs, if follow debian/fedora policies for instance. That's all. It was my 
first idea to propose you but I asked and to put libraries in places non-
standards isn't a good idea. I'm investigating it. 

But, for instance in debian mentors irc they found it "Sounds suspicious"

Best regards,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/02693e57/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Mon, Jan 26, 2015 at 03:47:03PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dilluns, 26 de gener de 2015, a les 15:01:27, Philippe Gerum va escriure:
> > On 01/26/2015 01:39 PM, Leopold Palomo-Avellaneda wrote:
> > > Maybe I'm wrong. But after reading this thread I understood that to have a
> > > kernel with both patches (i-pipe and preempt_rt) and, I understand,
> > > Xenomai-3 with the two versions could be a very interesting system to
> > > work on.
> > > 
> > > For instance, I'm in the robotics field, and after that mails I thought
> > > that it could be a good solution that fit the cases where you have
> > > several loops, with several rates with different importance.
> > 
> > You are missing an important point: Xenomai 3 over Mercury is about
> > running non-POSIX RTOS APIs over a native kernel (with or without
> > preempt-rt, this is orthogonal to the issue).
> 
> this is an interesting point.
> 
> [...]
> 
> > 
> > Therefore, your proposal mainly addresses the issue of running a mixed
> > configuration, with some Mercury-based application(s) ported from a
> > traditional RTOS to linux, and other application(s) running over Cobalt
> > in dual kernel mode, concurrently on the same system. People who just
> > want to run POSIX apps over a native kernel don't need Xenomai 3. In
> > short, the potential user base for the mixed setup as described is quite
> > small.
> > 
> > With that in mind, using a mixed installation root between Mercury and
> > Cobalt also means that any 2.x Makefile currently using "xeno-config"
> > would have to be fixed up, to reflect the new suffixed path or call
> > pkg-config to retrieve it, whatever fits. We have been advertising
> > xeno-config since years, as a mean to stay away from installation
> > specifics, so this would be quite wrong to end up asking people to run
> > xeno-config-cobalt or xeno-config-mercury.
> 
> xeno-config --with-core=cobalt/mercury
> 
> could be a solution. But, some default core should be defined.
> 
> > As I mentioned already, we won't go for single binaries running over
> > both cores, the performance and maintenance impact would be a nightmare.
> 
> Yes, two types of binaries. Your argumentation was clear.
> 
> > Since all our build system is autoconfiscated, you can pick any root
> > prefix that makes sense, and even fine tune every installation directory
> > already (lib, include, bin etc). This means that having multiple roots
> > is definitely a non-issue, and does not introduce any limitation.
> > 
> > I don't buy the "suffix to disambiguate" argument either:
> > /usr/lib/libvxworks-m.so is not clearer than
> > /usr/lib/mercury/libvxworks.so, or
> > /usr/xenomai/mercury/lib/libvxworks.so. And this does not even work
> > better with /usr/lib/libvxworks-mercury.so.
> > 
> > Besides, there is no shortage of ways to find out which Xenomai
> > configuration your build system and even your application is currently
> > depending on. 
> 
> well, I usually ask to ldd. So, if I have a binary and I run:
> 
> ldd /usr/local/lib/libcpp4ec.so
> 	linux-vdso.so.1 (0x00007fffee0dc000)
> 	libsoemrt.so.1.3.0 => /usr/local/lib/libsoemrt.so.1.3.0 
> (0x00007feea2352000)
> 	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007feea214a000)
> 	libnative.so.3 => /usr/lib/libnative.so.3 (0x00007feea1f40000)
> 	libxenomai.so.0 => /usr/lib/libxenomai.so.0 (0x00007feea1d39000)
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
> (0x00007feea1b1c000)
> 	libpugixml.so.1 => /usr/lib/x86_64-linux-gnu/libpugixml.so.1 
> (0x00007feea18e7000)
> 	librtdm.so.1 => /usr/lib/librtdm.so.1 (0x00007feea16e5000)
> 
> for example, if I had libvxworks-cobalt there, I knew that my binary was built 
> against xenomai with cobalt.
> 
> 
> > The only requirement is to query the right xeno-config
> > script or application, which may be as simple as setting the PATH
> > variable appropriately for your setup:
> > 
> > $ xeno-config --core
> > mercury
> > $ xeno-config --cflags
> 
> [...]
> 
> Yes, I liked. I thought that it was a good solution but I don't know if it's 
> fhs, if follow debian/fedora policies for instance. That's all. It was my 
> first idea to propose you but I asked and to put libraries in places non-
> standards isn't a good idea. I'm investigating it. 
> 
> But, for instance in debian mentors irc they found it "Sounds suspicious"

Again: pass to the configure script the option
--program-suffix=-cobalt 

And xeno-config will be named xeno-config-cobalt.

Please stop this useless discussion. Xenomai has all the flexibility
to allow you install things how you see fit.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/d19794da/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 15:08:26, Gilles Chanteperdrix va 
escriure:

[...]

> Sure, but in that case you would have two xenomai build trees, that
> you can configure with different options so that they do not collide
> once installed.

I'm sure that you can install it where do you want. But are you sure that you 
can install a library in a path outside the standard place, without touching 
ld.so.conf and you can have a program running from an installation?
 
Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/da174539/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Mon, Jan 26, 2015 at 03:56:08PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dilluns, 26 de gener de 2015, a les 15:08:26, Gilles Chanteperdrix va 
> escriure:
> 
> [...]
> 
> > Sure, but in that case you would have two xenomai build trees, that
> > you can configure with different options so that they do not collide
> > once installed.
> 
> I'm sure that you can install it where do you want. But are you sure that you 
> can install a library in a path outside the standard place, without touching 
> ld.so.conf and you can have a program running from an installation?

In Debian wheezy (and I assume any later revision), there is an
/etc/ld.so.conf.d directory where each package can install its
file with the directories it wants to add to the search path.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/900f2883/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 15:59:43, Gilles Chanteperdrix va 
escriure:
> On Mon, Jan 26, 2015 at 03:56:08PM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dilluns, 26 de gener de 2015, a les 15:08:26, Gilles Chanteperdrix va
> > escriure:
> > 
> > [...]
> > 
> > > Sure, but in that case you would have two xenomai build trees, that
> > > you can configure with different options so that they do not collide
> > > once installed.
> > 
> > I'm sure that you can install it where do you want. But are you sure that
> > you can install a library in a path outside the standard place, without
> > touching ld.so.conf and you can have a program running from an
> > installation?
> In Debian wheezy (and I assume any later revision), there is an
> /etc/ld.so.conf.d directory where each package can install its
> file with the directories it wants to add to the search path.

That's the point Gilles. Debian doesn't accept that [1]. Also, fedora 
recommends it as plugins, not libraries [2]. Only Opensuse doesn't say nothing 
against [3].

I don't want to make any useless discussion. I thought that it could be a 
simple change to make a co-installable versions of xenomai. However, as it 
seems that this case is strange it seems that it doesn't justify the 
investment in time to do that. I really though that could be useful.

Thanks for your patience,

Leopold


-----
[1] https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html
[2] http://fedoraproject.org/wiki/Packaging:Guidelines
[3] https://en.opensuse.org/openSUSE:Packaging_checks

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/f3b3fe1a/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Mon, Jan 26, 2015 at 06:46:21PM +0100, Leopold Palomo-Avellaneda wrote:
> El Dilluns, 26 de gener de 2015, a les 15:59:43, Gilles Chanteperdrix va 
> escriure:
> > On Mon, Jan 26, 2015 at 03:56:08PM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dilluns, 26 de gener de 2015, a les 15:08:26, Gilles Chanteperdrix va
> > > escriure:
> > > 
> > > [...]
> > > 
> > > > Sure, but in that case you would have two xenomai build trees, that
> > > > you can configure with different options so that they do not collide
> > > > once installed.
> > > 
> > > I'm sure that you can install it where do you want. But are you sure that
> > > you can install a library in a path outside the standard place, without
> > > touching ld.so.conf and you can have a program running from an
> > > installation?
> > In Debian wheezy (and I assume any later revision), there is an
> > /etc/ld.so.conf.d directory where each package can install its
> > file with the directories it wants to add to the search path.
> 
> That's the point Gilles. Debian doesn't accept that [1]. 

No, you missed the point. Entirely. The point is distribution rules
apply to re-packaging made for distributions. Not to upstream
packages. So, basically, Xenomai upstream package does not care
about any distribution rules, and the job of the Debian maintainer
is to massage Xenomai installation so that it fits Debian rules.

Look for instance at how the libcurl3 packages are made. libcurl3 can
use openssl, gnutls or nss as providing TLS, but was not meant to
run the three at a time. Debian wants to be able to install the
three version, so what does the Debian rules does ? They manage to do
it.

Putting things into several directories was just one proposed
solution, but it is not by any mean the only one.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/189efd2b/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Gilles Chanteperdrix]

On Mon, Jan 26, 2015 at 06:46:21PM +0100, Leopold Palomo-Avellaneda wrote:
> [1] https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html

Besides, you misread this directive it says:

Packages containing shared libraries should either install them into
/usr/lib or should require binaries built against them to set RPATH
to find the library at run-time.

So, it is permitted not to install libraries under /usr/lib provided
that you encode the RPATH into binaries, and do not rely on the
loader search path.


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/1080b35b/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 19:20:46, Gilles Chanteperdrix va 
escriure:
> > 
> > That's the point Gilles. Debian doesn't accept that [1].
> 
> No, you missed the point. Entirely. The point is distribution rules
> apply to re-packaging made for distributions. Not to upstream
> packages. So, basically, Xenomai upstream package does not care
> about any distribution rules, and the job of the Debian maintainer
> is to massage Xenomai installation so that it fits Debian rules.

The main idea is to collaborate with upstream in the way that both could make 
a good work that benefits all together. Obviously, this kind of rules doesn't 
affect upstream. My sentence was about that if you implement something that 
debian (or whatever distro) doesn't accept, the maintainer has double work 
patching it to be included. That's all, my propose was to have something that 
could benefit all the parts.

> Look for instance at how the libcurl3 packages are made. libcurl3 can
> use openssl, gnutls or nss as providing TLS, but was not meant to
> run the three at a time. Debian wants to be able to install the
> three version, so what does the Debian rules does ? They manage to do
> it.

AFAIK, looking the sources of the package, the names of the libraries are 
different. And installing in my box I have:

/usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.3.0
/usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
/usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0

that comes from libcurl3-nss, libcurl3-gnutls and libcurl3. The last one  
(OpenSSL flavour)

> Putting things into several directories was just one proposed
> solution, but it is not by any mean the only one.

I agree. I would like to find something that could benefit all the parts. If you 
prefer not rename, no problem. I though that it could be a good idea for all. 
Also I have to say that I don't think that it has sense to implement it in 
packaging. This kind of modifications have to have a very good reason to 
diverge from upstream.

Leopold

[1] http://anonscm.debian.org/cgit/collab-maint/curl.git

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/12637a25/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 19:32:17, Gilles Chanteperdrix va 
escriure:
> On Mon, Jan 26, 2015 at 06:46:21PM +0100, Leopold Palomo-Avellaneda wrote:
> > [1]
> > https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html
> 
> Besides, you misread this directive it says:

as always ...

> Packages containing shared libraries should either install them into
> /usr/lib or should require binaries built against them to set RPATH
> to find the library at run-time.
> 
> So, it is permitted not to install libraries under /usr/lib provided
> that you encode the RPATH into binaries, and do not rely on the
> loader search path.

using rpath is discouraged by debian [1] (and also others distros)

Leopold

[1] https://wiki.debian.org/RpathIssue
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/dbdf5f80/attachment.sig>

Re: [Xenomai] Packaging Xenomai-3

[Daniele Nicolodi]

On 26/01/15 23:17, Leopold Palomo-Avellaneda wrote:
> AFAIK, looking the sources of the package, the names of the libraries are 
> different. And installing in my box I have:
> 
> /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.3.0
> /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
> /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
> 
> that comes from libcurl3-nss, libcurl3-gnutls and libcurl3. The last one  
> (OpenSSL flavour)

The different library names are created in the debian package, not by
the upstream build system:
http://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/rules

That is what Gilles wanted to point out: renaming the packaged library
is done by the packaging machinery to suite the distribution, not upstream.

> I agree. I would like to find something that could benefit all the parts. If you 
> prefer not rename, no problem. I though that it could be a good idea for all. 
> Also I have to say that I don't think that it has sense to implement it in 
> packaging. This kind of modifications have to have a very good reason to 
> diverge from upstream.

See above.

Cheers,
Daniele

Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda]

El Dilluns, 26 de gener de 2015, a les 23:26:16, Daniele Nicolodi va escriure:
> On 26/01/15 23:17, Leopold Palomo-Avellaneda wrote:
> > AFAIK, looking the sources of the package, the names of the libraries are
> > different. And installing in my box I have:
> > 
> > /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.3.0
> > /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0
> > /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
> > 
> > that comes from libcurl3-nss, libcurl3-gnutls and libcurl3. The last one
> > (OpenSSL flavour)
> 
> The different library names are created in the debian package, not by
> the upstream build system:
> http://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/rules

Of course. I just said that to have co-installable it renaming the library 
it's an option.

> That is what Gilles wanted to point out: renaming the packaged library
> is done by the packaging machinery to suite the distribution, not upstream.

It's one option. The package sightly  modifies and patched upstream code. It's 
a complex package. It's not an easy job. It's rules file is long. And it's a 
sensible point (security), so I could understand that the maintainer wanted to 
offer all the variants that upstream provides. But I don't know the main reason 
for all this work.

> > I agree. I would like to find something that could benefit all the parts.
> > If you prefer not rename, no problem. I though that it could be a good
> > idea for all. Also I have to say that I don't think that it has sense to
> > implement it in packaging. This kind of modifications have to have a very
> > good reason to diverge from upstream.
> 
> See above.

I can see everything you want, but you should have a very good reason to make 
all this job. From my point of view if this kind of modifications are made by 
upstream (thinking the sources to do that), all is more easy. That's all. 

Of course that if could be done in packaging, but then the distro version is 
different than the others, so, from my point of view, you should have a very 
good reason to do that. If upstream made that change, all the distros follow.

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/b99cf931/attachment.sig>