[Xenomai] Q on xenomai2/3 userland coexistence

[Xenomai] Q on xenomai2/3 userland coexistence

[Michael Haberler]

ATM we're sorting through the machinekit xenomai3 transition on debian

I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)

The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually

I hope these will be able to co-reside on the same host?

Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?


(or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)


thanks in advance,

Michael


btw: a working 3.14 Xenomai3 kernel for the Beaglebone (and likely X15) appeared the other day in "deb [arch=armhf] http://repos.rcn-ee.net/debian/ jessie main" , thanks to Robert Nelson!

mah@epig:~/machinekit/src$ apt-cache search 3.14.45-ti-xenomai-r69

linux-firmware-image-3.14.45-ti-xenomai-r69 - Linux kernel firmware, version 3.14.45-ti-xenomai-r69
linux-image-3.14.45-ti-xenomai-r69 - Linux kernel, version 3.14.45-ti-xenomai-r69
mt7601u-modules-3.14.45-ti-xenomai-r69 - mt7601u modules
ti-sgx-es8-modules-3.14.45-ti-xenomai-r69 - ti-sgx es8 modules
ti-sgx-es9-modules-3.14.45-ti-xenomai-r69 - ti-sgx es9 modules
linux-headers-3.14.45-ti-xenomai-r69 - Linux kernel headers for 3.14.45-ti-xenomai-r69 on armhf

[    2.732701] [Xenomai] Cobalt v3.0-rc4 (Exact Zero) [DEBUG]

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Gilles Chanteperdrix]

On Sat, Jun 27, 2015 at 02:22:09PM +0200, Michael Haberler wrote:
> ATM we're sorting through the machinekit xenomai3 transition on
> debian
> 
> I assume that users will continue to run xenomai2 kernels for a
> long time, so we work towards separate (but hopefully
> coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup
> is driven by kernel autodetection, so booting a different kernel
> chooses the right runtime)
> 
> The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm,
> but I assume Xenomai3 equivalents will appear eventually

Xenomai 3 has a debian directory allowing to build it as a Debian
package. So, in fact, they are already here.


> 
> I hope these will be able to co-reside on the same host?
> 
> Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
> 
> 
> (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
> 

I was afraid someone was going to ask for that. Experience has
proved that allowing to install silently several versions of Xenomai
is a recipe for trouble. So, relying on Debian allowing to install
only one version of the package was a nice feature.

So, if we agree that having the two versions installed is not
something for the common user, I would suggest people who want to do
that know what they are doing and can install one version as a
Debian package, and the other manually.

On the other hand, if we think having the two versions installed
will be a very common use case, I do not think there is any conflict
with library names, only with tool names, and since we provide the
the "xeno" wrapper to fetch the tools from another place than
/usr/bin, I guess the only conflict would be on the "xeno" wrapper
itself. So, maybe we could call it xeno3 in Xenomai3 Debian package
to avoid any issue? Or use the Debian "alternatives" mechanism
(though this mechanism is probably unknown from the typical ubuntu
user)? 

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Gilles Chanteperdrix]

On Sat, Jun 27, 2015 at 02:43:39PM +0200, Gilles Chanteperdrix wrote:
> On Sat, Jun 27, 2015 at 02:22:09PM +0200, Michael Haberler wrote:
> > ATM we're sorting through the machinekit xenomai3 transition on
> > debian
> > 
> > I assume that users will continue to run xenomai2 kernels for a
> > long time, so we work towards separate (but hopefully
> > coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup
> > is driven by kernel autodetection, so booting a different kernel
> > chooses the right runtime)
> > 
> > The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm,
> > but I assume Xenomai3 equivalents will appear eventually
> 
> Xenomai 3 has a debian directory allowing to build it as a Debian
> package. So, in fact, they are already here.
> 
> 
> > 
> > I hope these will be able to co-reside on the same host?
> > 
> > Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
> > 
> > 
> > (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
> > 
> 
> I was afraid someone was going to ask for that. Experience has
> proved that allowing to install silently several versions of Xenomai
> is a recipe for trouble. So, relying on Debian allowing to install
> only one version of the package was a nice feature.
> 
> So, if we agree that having the two versions installed is not
> something for the common user, I would suggest people who want to do
> that know what they are doing and can install one version as a
> Debian package, and the other manually.
> 
> On the other hand, if we think having the two versions installed
> will be a very common use case, I do not think there is any conflict
> with library names, only with tool names, and since we provide the
> the "xeno" wrapper to fetch the tools from another place than
> /usr/bin, I guess the only conflict would be on the "xeno" wrapper
> itself. So, maybe we could call it xeno3 in Xenomai3 Debian package
> to avoid any issue? Or use the Debian "alternatives" mechanism
> (though this mechanism is probably unknown from the typical ubuntu
> user)? 

Other obvious conflicts are xeno-config, xeno-test. Of course, they
could be hidden behind the xeno wrapper as well. as xeno config and
xeno test.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Philippe Gerum]

On 06/27/2015 02:22 PM, Michael Haberler wrote:
> ATM we're sorting through the machinekit xenomai3 transition on debian
> 
> I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)
> 
> The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually
> 
> I hope these will be able to co-reside on the same host?
> 
> Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
> 
> 
> (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
> 

Not possible. Xenomai 2 uses kernel services provided by the I-pipe
compiled for legacy operation mode. Xenomai 3 wants this mode disabled.

-- 
Philippe.

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Gilles Chanteperdrix]

On Sat, Jun 27, 2015 at 03:09:19PM +0200, Philippe Gerum wrote:
> On 06/27/2015 02:22 PM, Michael Haberler wrote:
> > ATM we're sorting through the machinekit xenomai3 transition on debian
> > 
> > I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)
> > 
> > The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually
> > 
> > I hope these will be able to co-reside on the same host?
> > 
> > Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
> > 
> > 
> > (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
> > 
> 
> Not possible. Xenomai 2 uses kernel services provided by the I-pipe
> compiled for legacy operation mode. Xenomai 3 wants this mode disabled.

The two kernels have different ABIs anyway. I think what Michael
wants to do is to also have the two patched kernels installed and
reboot (or kexec?) to switch from one to the other.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Michael Haberler]

> Am 27.06.2015 um 15:14 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> 
> On Sat, Jun 27, 2015 at 03:09:19PM +0200, Philippe Gerum wrote:
>> On 06/27/2015 02:22 PM, Michael Haberler wrote:
>>> ATM we're sorting through the machinekit xenomai3 transition on debian
>>> 
>>> I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)
>>> 
>>> The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually
>>> 
>>> I hope these will be able to co-reside on the same host?
>>> 
>>> Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
>>> 
>>> 
>>> (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
>>> 
>> 
>> Not possible. Xenomai 2 uses kernel services provided by the I-pipe
>> compiled for legacy operation mode. Xenomai 3 wants this mode disabled.
> 
> The two kernels have different ABIs anyway. I think what Michael
> wants to do is to also have the two patched kernels installed and
> reboot (or kexec?) to switch from one to the other.

yes, it's a potential support issue, mostly for the folk installing from packages (I'm less concerned about those which install from source, and we can use configure.ac tests if something is obviously afoul)

what I see unfolding is:

- folks with a xeno2 package-based install want to try a xeno3 kernel, run apt-get upgrade etc, pull in kernel, and updated libraries
- something is not to their liking, and they step back to boot a xeno2 kernel - maybe just by changing the bootloader entry or by removing the xeno3 kernel
- if the first step has wiped the xeno2 userland support by upgrading, we have a support issue
- if xeno2 and xeno3 userland co-reside peacefully and separate, no issue

doing everything through the xeno wrapper looks doable, but I guess backporting this wrapper to xeno2 will be unpopular

what about completely separating the names, like /usr/xenomai3 ? sledgehammer approach (that is, in the best tradition of yankee engineering ;), but certainly effective.


- Michael




> 
> -- 
> 					    Gilles.
> https://click-hack.org

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[Gilles Chanteperdrix]

On Sat, Jun 27, 2015 at 03:25:01PM +0200, Michael Haberler wrote:
> 
> > Am 27.06.2015 um 15:14 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > 
> > On Sat, Jun 27, 2015 at 03:09:19PM +0200, Philippe Gerum wrote:
> >> On 06/27/2015 02:22 PM, Michael Haberler wrote:
> >>> ATM we're sorting through the machinekit xenomai3 transition on debian
> >>> 
> >>> I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)
> >>> 
> >>> The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually
> >>> 
> >>> I hope these will be able to co-reside on the same host?
> >>> 
> >>> Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
> >>> 
> >>> 
> >>> (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
> >>> 
> >> 
> >> Not possible. Xenomai 2 uses kernel services provided by the I-pipe
> >> compiled for legacy operation mode. Xenomai 3 wants this mode disabled.
> > 
> > The two kernels have different ABIs anyway. I think what Michael
> > wants to do is to also have the two patched kernels installed and
> > reboot (or kexec?) to switch from one to the other.
> 
> yes, it's a potential support issue, mostly for the folk installing from packages (I'm less concerned about those which install from source, and we can use configure.ac tests if something is obviously afoul)
> 
> what I see unfolding is:
> 
> - folks with a xeno2 package-based install want to try a xeno3 kernel, run apt-get upgrade etc, pull in kernel, and updated libraries
> - something is not to their liking, and they step back to boot a xeno2 kernel - maybe just by changing the bootloader entry or by removing the xeno3 kernel
> - if the first step has wiped the xeno2 userland support by upgrading, we have a support issue
> - if xeno2 and xeno3 userland co-reside peacefully and separate, no issue
> 
> doing everything through the xeno wrapper looks doable, but I guess backporting this wrapper to xeno2 will be unpopular
> 
> what about completely separating the names, like /usr/xenomai3 ? sledgehammer approach (that is, in the best tradition of yankee engineering ;), but certainly effective.

Obviously, the two installations should have different prefixes, but
that does not solve the problem of helpers which should be found in
the PATH, such as xeno and xeno-config.

Anyway, I think this is a Debian-specific problem, so, I will let
the Debian maintainer discuss of what would be the distribution best
practices.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Q on xenomai2/3 userland coexistence

[John Morris]

On 06/27/2015 08:37 AM, Gilles Chanteperdrix wrote:
> On Sat, Jun 27, 2015 at 03:25:01PM +0200, Michael Haberler wrote:
>>
>>> Am 27.06.2015 um 15:14 schrieb Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>>>
>>> On Sat, Jun 27, 2015 at 03:09:19PM +0200, Philippe Gerum wrote:
>>>> On 06/27/2015 02:22 PM, Michael Haberler wrote:
>>>>> ATM we're sorting through the machinekit xenomai3 transition on debian
>>>>>
>>>>> I assume that users will continue to run xenomai2 kernels for a long time, so we work towards separate (but hopefully coexisting-in-peace) packages for Xenomai2 and Xenomai3 (startup is driven by kernel autodetection, so booting a different kernel chooses the right runtime)
>>>>>
>>>>> The libxenomai-dev and libxenomai1 in debian are all xenomai2 atm, but I assume Xenomai3 equivalents will appear eventually
>>>>>
>>>>> I hope these will be able to co-reside on the same host?
>>>>>
>>>>> Ideally suggesting the Xenomai3 packages would be separate, be named differently, and not supersede any installed Xenomai2 packages?
>>>>>
>>>>>
>>>>> (or am I blundering and I can run applications linked against the Xenomai3 libraries on a Xenomai2 kernel? my tests so far indicate - not)
>>>>>
>>>>
>>>> Not possible. Xenomai 2 uses kernel services provided by the I-pipe
>>>> compiled for legacy operation mode. Xenomai 3 wants this mode disabled.
>>>
>>> The two kernels have different ABIs anyway. I think what Michael
>>> wants to do is to also have the two patched kernels installed and
>>> reboot (or kexec?) to switch from one to the other.
>>
>> yes, it's a potential support issue, mostly for the folk installing from packages (I'm less concerned about those which install from source, and we can use configure.ac tests if something is obviously afoul)
>>
>> what I see unfolding is:
>>
>> - folks with a xeno2 package-based install want to try a xeno3 kernel, run apt-get upgrade etc, pull in kernel, and updated libraries
>> - something is not to their liking, and they step back to boot a xeno2 kernel - maybe just by changing the bootloader entry or by removing the xeno3 kernel
>> - if the first step has wiped the xeno2 userland support by upgrading, we have a support issue
>> - if xeno2 and xeno3 userland co-reside peacefully and separate, no issue
>>
>> doing everything through the xeno wrapper looks doable, but I guess backporting this wrapper to xeno2 will be unpopular
>>
>> what about completely separating the names, like /usr/xenomai3 ? sledgehammer approach (that is, in the best tradition of yankee engineering ;), but certainly effective.
>
> Obviously, the two installations should have different prefixes, but
> that does not solve the problem of helpers which should be found in
> the PATH, such as xeno and xeno-config.
>
> Anyway, I think this is a Debian-specific problem, so, I will let
> the Debian maintainer discuss of what would be the distribution best
> practices.

Yes, this is a packaging-specific problem, and it's the package repo 
maintainer's job to solve this for the repo's users.

My Machinekit distro, which includes Xenomai kernels and run-time 
packages, will only ever ship one version of Xenomai:  v.2 now, and v.3 
once the Machinekit migration is stable.

I do also ship a separate 'bleeding' repo with Xenomai-3 packages, 
potentially opening up space for confusion.  However, there are strong 
warnings [1], and those not scared off are expected to know how to revert.

So, I don't see the above support issue affecting regular users.  Of the 
handful of folks who'll help develop and test the Xeno-3 migration, if 
some small fraction needs hand-holding, I'm OK helping them.

As for two simultaneous copies, I agree with Gilles:  install Xenomai-3 
in non-standard location and use Machinekit's `./configure 
--with-xeno-config=[...]`.  One can still install both Xenomai 2 and 3 
kernel packages simultaneously, and it takes just a minute to compile 
Xenomai.

	John

[1]: 
http://www.dovetail-automata.com/articles/2015/05/30/jessie-bleeding-kernel-packages/