rtnet-users — support, discussion, and announcement list

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dimarts, 20 de gener de 2015, a les 08:22:28, Leopold Palomo-Avellaneda va 
escriure:
> > 
> > That is strange, because without this commit:
> > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02
> > e6 33ec53ac9b89475
> > 
> > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > in Linux 3.16.
> > 
> > So, maybe you could compile Xenomai because you did not enable any
> > builtin RTDM driver, but you are certainly not going to be able to
> > compile RTnet.
> 
> Ok, it has sense now. Probably I did some mistake and I didn't enable some
> driver. I remember that I disable some things. 

I correct myself, I had this configuration

CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0  
CONFIG_XENO_OPT_RTDM_FILDES=512
CONFIG_XENO_OPT_RTDM_SELECT=y


I don't know if it has some relation with include/rtdm/rtdm_driver.h.



-- 
--
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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 09:03:12AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 20 de gener de 2015, a les 08:26:29, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Jan 20, 2015 at 08:22:28AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix
> > > > > va
> > > > > 
> > > > > escriure:
> > > > > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda
> > > 
> > > wrote:
> > > > > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles
> > > > > > > Chanteperdrix
> > > > > > > va
> > > > > > > 
> > > > > > > escriure:
> > > > > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold
> > > > > > > > Palomo-Avellaneda
> > > > > 
> > > > > wrote:
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I have compiled and created debian packages of xenomai-2.6.4.
> > > > > > > > > I
> > > > > > > > > have
> > > > > > > > > patched the kernel and created debian packages for it.
> > > > > > > > > (3.16.0)
> > > > > > > > 
> > > > > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > > > > 
> > > > > > > Gilles,
> > > > > > > 
> > > > > > > I have seen that Mariusz Janiak sent some patches to solve
> > > > > > > compilation
> > > > > > > issues. But my question was about in configure time, not compile
> > > > > > > time.
> > > > > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > > > > 
> > > > > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > > > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > > > > rule: a Xenomai release generally does not support kernel versions
> > > > > > higher than the highest one for which it provides patch, 2.6.3
> > > > > > having been an exception since the highest patch it provided was for
> > > > > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > > > > exception was explicitly mentioned in the announce.
> > > > > 
> > > > > Gilles,
> > > > > 
> > > > > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used
> > > > > adeos
> > > > > patch ipipe-core-3.16-x86-1.patch [2].
> > > > > 
> > > > > Xenomai compiled without any issue, The kernel compiled without any
> > > > > issue.
> > > > > I could exec: xeno-test.
> > > > 
> > > > That is strange, because without this commit:
> > > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e
> > > > 02e6 33ec53ac9b89475
> > > > 
> > > > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > > > in Linux 3.16.
> > > > 
> > > > So, maybe you could compile Xenomai because you did not enable any
> > > > builtin RTDM driver, but you are certainly not going to be able to
> > > > compile RTnet.
> > > 
> > > Ok, it has sense now. Probably I did some mistake and I didn't enable some
> > > driver. I remember that I disable some things. Probably I miss
> > > something... I tried to follow the wiki rules (yes, sometimes exist some
> > > user that read the manual and the wikis ;-)
> > > 
> > > So, and I have read your another mail:
> > > 
> > > - xenomai git (2.x series, with that commit) compiles with
> > > linux-3.16?
> > 
> > It compiles, but it has some issues which are fixed by other commit.
> > The point I was trying to make is that if you want to use I-pipe
> > patches of a higher version than the ones in the latest release, you
> > should use the git.
> 
> I got it, I will try.
> 
> > > - rtnet compiles against xenomai latest git (2.x series)
> > 
> > No idea, really, I am only interested in 3.x, 2.x series will no
> > longer evolve now. And again, in 3.x, rtnet is integrated into
> > xenomai, so much easier to compile. And since you were the one to
> > ask for rtnet with 3.x, I would expect you to test this integration
> > ;-)
> 
> :-D
> 
> 
> yes you are right. The point is that I live so happy with the debian packages 
> and the infrastructure to build them. 3.x has no it. But you are right. I will 
> need it, so I have to test it...

Xenomai 3.x has the debian directory, with contents equivalent to
the one of 2.x. It may not work, but contributions are welcome.

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dimarts, 20 de gener de 2015, a les 08:26:29, Gilles Chanteperdrix va 
escriure:
> On Tue, Jan 20, 2015 at 08:22:28AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix
> > > > va
> > > > 
> > > > escriure:
> > > > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda
> > 
> > wrote:
> > > > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles
> > > > > > Chanteperdrix
> > > > > > va
> > > > > > 
> > > > > > escriure:
> > > > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold
> > > > > > > Palomo-Avellaneda
> > > > 
> > > > wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I have compiled and created debian packages of xenomai-2.6.4.
> > > > > > > > I
> > > > > > > > have
> > > > > > > > patched the kernel and created debian packages for it.
> > > > > > > > (3.16.0)
> > > > > > > 
> > > > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > > > 
> > > > > > Gilles,
> > > > > > 
> > > > > > I have seen that Mariusz Janiak sent some patches to solve
> > > > > > compilation
> > > > > > issues. But my question was about in configure time, not compile
> > > > > > time.
> > > > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > > > 
> > > > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > > > rule: a Xenomai release generally does not support kernel versions
> > > > > higher than the highest one for which it provides patch, 2.6.3
> > > > > having been an exception since the highest patch it provided was for
> > > > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > > > exception was explicitly mentioned in the announce.
> > > > 
> > > > Gilles,
> > > > 
> > > > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used
> > > > adeos
> > > > patch ipipe-core-3.16-x86-1.patch [2].
> > > > 
> > > > Xenomai compiled without any issue, The kernel compiled without any
> > > > issue.
> > > > I could exec: xeno-test.
> > > 
> > > That is strange, because without this commit:
> > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e
> > > 02e6 33ec53ac9b89475
> > > 
> > > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > > in Linux 3.16.
> > > 
> > > So, maybe you could compile Xenomai because you did not enable any
> > > builtin RTDM driver, but you are certainly not going to be able to
> > > compile RTnet.
> > 
> > Ok, it has sense now. Probably I did some mistake and I didn't enable some
> > driver. I remember that I disable some things. Probably I miss
> > something... I tried to follow the wiki rules (yes, sometimes exist some
> > user that read the manual and the wikis ;-)
> > 
> > So, and I have read your another mail:
> > 
> > - xenomai git (2.x series, with that commit) compiles with
> > linux-3.16?
> 
> It compiles, but it has some issues which are fixed by other commit.
> The point I was trying to make is that if you want to use I-pipe
> patches of a higher version than the ones in the latest release, you
> should use the git.

I got it, I will try.

> > - rtnet compiles against xenomai latest git (2.x series)
> 
> No idea, really, I am only interested in 3.x, 2.x series will no
> longer evolve now. And again, in 3.x, rtnet is integrated into
> xenomai, so much easier to compile. And since you were the one to
> ask for rtnet with 3.x, I would expect you to test this integration
> ;-)

:-D


yes you are right. The point is that I live so happy with the debian packages 
and the infrastructure to build them. 3.x has no it. But you are right. I will 
need it, so I have to test it...

-- 
--
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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dimarts, 20 de gener de 2015, a les 08:49:57, Gilles Chanteperdrix va 
escriure:
> On Tue, Jan 20, 2015 at 08:22:28AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix
> > > > va
> > > > 
> > > > escriure:
> > > > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda
> > 
> > wrote:
> > > > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles
> > > > > > Chanteperdrix
> > > > > > va
> > > > > > 
> > > > > > escriure:
> > > > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold
> > > > > > > Palomo-Avellaneda
> > > > 
> > > > wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I have compiled and created debian packages of xenomai-2.6.4.
> > > > > > > > I
> > > > > > > > have
> > > > > > > > patched the kernel and created debian packages for it.
> > > > > > > > (3.16.0)
> > > > > > > 
> > > > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > > > 
> > > > > > Gilles,
> > > > > > 
> > > > > > I have seen that Mariusz Janiak sent some patches to solve
> > > > > > compilation
> > > > > > issues. But my question was about in configure time, not compile
> > > > > > time.
> > > > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > > > 
> > > > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > > > rule: a Xenomai release generally does not support kernel versions
> > > > > higher than the highest one for which it provides patch, 2.6.3
> > > > > having been an exception since the highest patch it provided was for
> > > > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > > > exception was explicitly mentioned in the announce.
> > > > 
> > > > Gilles,
> > > > 
> > > > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used
> > > > adeos
> > > > patch ipipe-core-3.16-x86-1.patch [2].
> > > > 
> > > > Xenomai compiled without any issue, The kernel compiled without any
> > > > issue.
> > > > I could exec: xeno-test.
> > > 
> > > That is strange, because without this commit:
> > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e
> > > 02e6 33ec53ac9b89475
> > > 
> > > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > > in Linux 3.16.
> > > 
> > > So, maybe you could compile Xenomai because you did not enable any
> > > builtin RTDM driver, but you are certainly not going to be able to
> > > compile RTnet.
> > 
> > Ok, it has sense now. Probably I did some mistake and I didn't enable some
> > driver. I remember that I disable some things. Probably I miss
> > something... I tried to follow the wiki rules (yes, sometimes exist some
> > user that read the manual and the wikis ;-)
> 
> Well, first Xenomai website has not been a wiki for something like 6
> monthes now, so, I am sure you read it at some point, but I am not
> sure you read it recently. And reading this page:

It seems that it's a wordpress. Technically it's not a wiki, it's true. I 
tried to referring to the web page, ok? And yes, I read it yesterday

 
> https://xenomai.org/2014/06/building-debian-packages/
> 
> I find the sentence:
> 
> Note that if you do not find a suitable patch, you may look for
> patches in the Adeos repository. 

I looked in the adeos repository.

> As a rule of thumb, the latest
> patches delivered with a version of Xenomai sources corresponds to
> the latest version of Linux supported by this version of Xenomai,
> but sometimes a more recent patch will work (as is the case for the
> I-pipe patch for Linux 3.10.32 with Xenomai 2.6.3).

> Which clearly warns you that what you are trying to do may not work.
> And in fact, generally, it does not, because the Linux kernel API
> changes from version to version, so Xenomai has to be adapted to
> these API changes.

Yes, I know, that but I tried and I had not any compilation issue. The no 
important thing was that I disable all rtdm, not important that all ;-)

I will try to compile with the latest 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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 08:22:28AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix
> > > > > va
> > > > > 
> > > > > escriure:
> > > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda
> > > 
> > > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I have compiled and created debian packages of xenomai-2.6.4. I
> > > > > > > have
> > > > > > > patched the kernel and created debian packages for it. (3.16.0)
> > > > > > 
> > > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > > 
> > > > > Gilles,
> > > > > 
> > > > > I have seen that Mariusz Janiak sent some patches to solve compilation
> > > > > issues. But my question was about in configure time, not compile time.
> > > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > > 
> > > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > > rule: a Xenomai release generally does not support kernel versions
> > > > higher than the highest one for which it provides patch, 2.6.3
> > > > having been an exception since the highest patch it provided was for
> > > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > > exception was explicitly mentioned in the announce.
> > > 
> > > Gilles,
> > > 
> > > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos
> > > patch ipipe-core-3.16-x86-1.patch [2].
> > > 
> > > Xenomai compiled without any issue, The kernel compiled without any issue.
> > > I could exec: xeno-test.
> > 
> > That is strange, because without this commit:
> > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02e6
> > 33ec53ac9b89475
> > 
> > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > in Linux 3.16.
> > 
> > So, maybe you could compile Xenomai because you did not enable any
> > builtin RTDM driver, but you are certainly not going to be able to
> > compile RTnet.
> 
> Ok, it has sense now. Probably I did some mistake and I didn't enable some 
> driver. I remember that I disable some things. Probably I miss something... I 
> tried to follow the wiki rules (yes, sometimes exist some user that read the 
> manual and the wikis ;-)

Well, first Xenomai website has not been a wiki for something like 6
monthes now, so, I am sure you read it at some point, but I am not
sure you read it recently. And reading this page:

https://xenomai.org/2014/06/building-debian-packages/

I find the sentence: 

Note that if you do not find a suitable patch, you may look for
patches in the Adeos repository. As a rule of thumb, the latest
patches delivered with a version of Xenomai sources corresponds to
the latest version of Linux supported by this version of Xenomai,
but sometimes a more recent patch will work (as is the case for the
I-pipe patch for Linux 3.10.32 with Xenomai 2.6.3). 

Which clearly warns you that what you are trying to do may not work.
And in fact, generally, it does not, because the Linux kernel API
changes from version to version, so Xenomai has to be adapted to
these API changes.

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 08:22:28AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix
> > > > > va
> > > > > 
> > > > > escriure:
> > > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda
> > > 
> > > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I have compiled and created debian packages of xenomai-2.6.4. I
> > > > > > > have
> > > > > > > patched the kernel and created debian packages for it. (3.16.0)
> > > > > > 
> > > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > > 
> > > > > Gilles,
> > > > > 
> > > > > I have seen that Mariusz Janiak sent some patches to solve compilation
> > > > > issues. But my question was about in configure time, not compile time.
> > > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > > 
> > > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > > rule: a Xenomai release generally does not support kernel versions
> > > > higher than the highest one for which it provides patch, 2.6.3
> > > > having been an exception since the highest patch it provided was for
> > > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > > exception was explicitly mentioned in the announce.
> > > 
> > > Gilles,
> > > 
> > > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos
> > > patch ipipe-core-3.16-x86-1.patch [2].
> > > 
> > > Xenomai compiled without any issue, The kernel compiled without any issue.
> > > I could exec: xeno-test.
> > 
> > That is strange, because without this commit:
> > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02e6
> > 33ec53ac9b89475
> > 
> > include/rtdm/rtdm_driver.h references a macro which no longer exists
> > in Linux 3.16.
> > 
> > So, maybe you could compile Xenomai because you did not enable any
> > builtin RTDM driver, but you are certainly not going to be able to
> > compile RTnet.
> 
> Ok, it has sense now. Probably I did some mistake and I didn't enable some 
> driver. I remember that I disable some things. Probably I miss something... I 
> tried to follow the wiki rules (yes, sometimes exist some user that read the 
> manual and the wikis ;-)
> 
> So, and I have read your another mail:
> 
> - xenomai git (2.x series, with that commit) compiles with
> linux-3.16?

It compiles, but it has some issues which are fixed by other commit.
The point I was trying to make is that if you want to use I-pipe
patches of a higher version than the ones in the latest release, you
should use the git.

> - rtnet compiles against xenomai latest git (2.x series)

No idea, really, I am only interested in 3.x, 2.x series will no
longer evolve now. And again, in 3.x, rtnet is integrated into
xenomai, so much easier to compile. And since you were the one to
ask for rtnet with 3.x, I would expect you to test this integration
;-)

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dimarts, 20 de gener de 2015, a les 08:15:58, Gilles Chanteperdrix va 
escriure:
> On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix
> > > > va
> > > > 
> > > > escriure:
> > > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda
> > 
> > wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I have compiled and created debian packages of xenomai-2.6.4. I
> > > > > > have
> > > > > > patched the kernel and created debian packages for it. (3.16.0)
> > > > > 
> > > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > > 
> > > > Gilles,
> > > > 
> > > > I have seen that Mariusz Janiak sent some patches to solve compilation
> > > > issues. But my question was about in configure time, not compile time.
> > > > So, configure doesn't detect the RTOS if it's above 3.14?
> > > 
> > > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > > rule: a Xenomai release generally does not support kernel versions
> > > higher than the highest one for which it provides patch, 2.6.3
> > > having been an exception since the highest patch it provided was for
> > > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > > exception was explicitly mentioned in the announce.
> > 
> > Gilles,
> > 
> > yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos
> > patch ipipe-core-3.16-x86-1.patch [2].
> > 
> > Xenomai compiled without any issue, The kernel compiled without any issue.
> > I could exec: xeno-test.
> 
> That is strange, because without this commit:
> https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02e6
> 33ec53ac9b89475
> 
> include/rtdm/rtdm_driver.h references a macro which no longer exists
> in Linux 3.16.
> 
> So, maybe you could compile Xenomai because you did not enable any
> builtin RTDM driver, but you are certainly not going to be able to
> compile RTnet.

Ok, it has sense now. Probably I did some mistake and I didn't enable some 
driver. I remember that I disable some things. Probably I miss something... I 
tried to follow the wiki rules (yes, sometimes exist some user that read the 
manual and the wikis ;-)

So, and I have read your another mail:

- xenomai git (2.x series, with that commit) compiles with linux-3.16?
- rtnet compiles against xenomai latest git (2.x series)

Thanks,

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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > Hi,
> > > > > 
> > > > > I have compiled and created debian packages of xenomai-2.6.4. I have
> > > > > patched the kernel and created debian packages for it. (3.16.0)
> > > > 
> > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > 
> > > Gilles,
> > > 
> > > I have seen that Mariusz Janiak sent some patches to solve compilation
> > > issues. But my question was about in configure time, not compile time.
> > > So, configure doesn't detect the RTOS if it's above 3.14?
> > 
> > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > rule: a Xenomai release generally does not support kernel versions
> > higher than the highest one for which it provides patch, 2.6.3
> > having been an exception since the highest patch it provided was for
> > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > exception was explicitly mentioned in the announce.
> 
> Gilles,
> 
> yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos patch 
> ipipe-core-3.16-x86-1.patch [2].
> 
> Xenomai compiled without any issue, The kernel compiled without any issue. I 
> could exec: xeno-test.
> 
> I created debian packages without any issue. And I'm talking about rtnet...

BTW, note that RTnet compiles fine with Xenomai forge, merging it in
Xenomai tree avoided a lot of troubles, ao I am interested by any
feedback you could give me with this configuration.

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 08:11:54AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va 
> escriure:
> > On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda wrote:
> > > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix va
> > > 
> > > escriure:
> > > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda 
> wrote:
> > > > > Hi,
> > > > > 
> > > > > I have compiled and created debian packages of xenomai-2.6.4. I have
> > > > > patched the kernel and created debian packages for it. (3.16.0)
> > > > 
> > > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > > 
> > > Gilles,
> > > 
> > > I have seen that Mariusz Janiak sent some patches to solve compilation
> > > issues. But my question was about in configure time, not compile time.
> > > So, configure doesn't detect the RTOS if it's above 3.14?
> > 
> > I am not talking about RTnet. I am talking about Xenomai. Xenomai
> > 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> > rule: a Xenomai release generally does not support kernel versions
> > higher than the highest one for which it provides patch, 2.6.3
> > having been an exception since the highest patch it provided was for
> > Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> > exception was explicitly mentioned in the announce.
> 
> Gilles,
> 
> yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos patch 
> ipipe-core-3.16-x86-1.patch [2].
> 
> Xenomai compiled without any issue, The kernel compiled without any issue. I 
> could exec: xeno-test.

That is strange, because without this commit:
https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02e633ec53ac9b89475

include/rtdm/rtdm_driver.h references a macro which no longer exists
in Linux 3.16.

So, maybe you could compile Xenomai because you did not enable any
builtin RTDM driver, but you are certainly not going to be able to
compile RTnet.

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dimarts, 20 de gener de 2015, a les 08:07:08, Gilles Chanteperdrix va 
escriure:
> On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda wrote:
> > El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda 
wrote:
> > > > Hi,
> > > > 
> > > > I have compiled and created debian packages of xenomai-2.6.4. I have
> > > > patched the kernel and created debian packages for it. (3.16.0)
> > > 
> > > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> > 
> > Gilles,
> > 
> > I have seen that Mariusz Janiak sent some patches to solve compilation
> > issues. But my question was about in configure time, not compile time.
> > So, configure doesn't detect the RTOS if it's above 3.14?
> 
> I am not talking about RTnet. I am talking about Xenomai. Xenomai
> 2.6.4 can not use Linux kernels higher than 3.14. That is a general
> rule: a Xenomai release generally does not support kernel versions
> higher than the highest one for which it provides patch, 2.6.3
> having been an exception since the highest patch it provided was for
> Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
> exception was explicitly mentioned in the announce.

Gilles,

yesterday I downloaded xenomai 2.6.4 and linux-3.16.0 [1]. I used adeos patch 
ipipe-core-3.16-x86-1.patch [2].

Xenomai compiled without any issue, The kernel compiled without any issue. I 
could exec: xeno-test.

I created debian packages without any issue. And I'm talking about rtnet...

[1] https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.tar.xz
[2] http://download.gna.org/adeos/patches/v3.x/x86/ipipe-core-3.16-x86-1.patch
-- 
--
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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Tue, Jan 20, 2015 at 08:02:29AM +0100, Leopold Palomo-Avellaneda wrote:
> El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix va 
> escriure:
> > On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > I have compiled and created debian packages of xenomai-2.6.4. I have
> > > patched the kernel and created debian packages for it. (3.16.0)
> > 
> > Xenomai 2.6.4 does not compile with Linux 3.16.0.
> 
> Gilles,
> 
> I have seen that Mariusz Janiak sent some patches to solve compilation issues. 
> But my question was about in configure time, not compile time. So, configure 
> doesn't detect the RTOS if it's above 3.14?

I am not talking about RTnet. I am talking about Xenomai. Xenomai
2.6.4 can not use Linux kernels higher than 3.14. That is a general
rule: a Xenomai release generally does not support kernel versions
higher than the highest one for which it provides patch, 2.6.3
having been an exception since the highest patch it provided was for
Linux 3.8 but it supported the I-pipe patch for Linux 3.10. But this
exception was explicitly mentioned in the announce.

-- 
					    Gilles.

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

El Dilluns, 19 de gener de 2015, a les 23:24:57, Gilles Chanteperdrix va 
escriure:
> On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > I have compiled and created debian packages of xenomai-2.6.4. I have
> > patched the kernel and created debian packages for it. (3.16.0)
> 
> Xenomai 2.6.4 does not compile with Linux 3.16.0.

Gilles,

I have seen that Mariusz Janiak sent some patches to solve compilation issues. 
But my question was about in configure time, not compile time. So, configure 
doesn't detect the RTOS if it's above 3.14?

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?

Re: [RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Gilles C. <gil...@xe...>]

On Mon, Jan 19, 2015 at 11:03:19PM +0100, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> I have compiled and created debian packages of xenomai-2.6.4. I have patched 
> the kernel and created debian packages for it. (3.16.0)

Xenomai 2.6.4 does not compile with Linux 3.16.0.

-- 
					    Gilles.

[RTnet-users] Compiling rtnet git with xenomai 2.6.4 and linux 3.16.0

[Leopold Palomo-A. <le...@al...>]

Hi,

I have compiled and created debian packages of xenomai-2.6.4. I have patched 
the kernel and created debian packages for it. (3.16.0)

Now, I'm trying to compile rtnet, and I don't know why, it doesn't detect the 
linux/xenomai headers. make menuconfig fail to detect:

checking for main in -lncurses... yes
checking for RTnet Kconfig file... .rtnet_config (supplied)
checking for RT-extension... configure: error: *** RT-extended kernel not found 
in /lib/modules/3.16.0-xenomai-2.6.4/build
makefile:51: recipe for target 'config.status' failed


and this directory exists and point to:

/lib/modules/3.16.0-xenomai-2.6.4/build -> /usr/src/linux-headers-3.16.0-
xenomai-2.6.4

I had a previous version (3.8.13) and it has more or less the same files and it 
worked. But with this new version fails and I really doesn't found the 
mistake. Because, are there some important changes in the configure step 
between xenomai-2.6.3 /linux-3.8.13 and  xenomai-2.6.4 /linux-3.16.0?

Thanks.

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?

Re: [RTnet-users] [Xenomai] Add "rtroute solicit" support to the rtnet script and rtnet.conf

[Jeff W. <jef...@nt...>]

On 12/18/2014 08:49 AM, Gilles Chanteperdrix wrote:
> On Thu, Dec 18, 2014 at 08:35:32AM -0600, Jeff Webb wrote:
>> On 12/17/2014 04:31 AM, Gilles Chanteperdrix wrote:
>>> On Tue, Dec 16, 2014 at 03:51:16PM -0600, Jeff Webb wrote:
>>>> I am using rtnet without rtmac/tdma. I previously sent a patch
>>>> that allows one to use the "rtnet" script and rtnet.conf in this
>>>> configuration. I would also like to be able to specify a list of
>>>> IP addresses in rtnet.conf that are passed along to "rtroute
>>>> solicit". I have attached patches for the rtnet and
>>>> xenomai-3.git/next repositories. I think others will find them
>>>> useful.
>>>
>>> Well, you should probably be using "nomac" if you are not interested
>>> in tdma.
>>>
>>
>> Thank you for your response. I appreciate your advice, Gilles, and
>> even more so, since I am new to RTnet. I am somewhat confused by
>> the rtmac/nomac configuration, since I haven't found a lot of
>> documentation on it. Something I read indicated that the primary
>> purpose was for use as skeleton when writing new MAC
>> implementations, but it also seems that it is useful for other
>> purposes. I have a couple questions that might clarify things for
>> me a bit.
>>
>> There are a couple of ASCII-art drawings at the beginning of the
>> README.rtmac file in the rtnet documentation. The first one seems
>> to indicate that rtnet can be used without rtmac, if all
>> communication is done from RT applications. I see that with rtmac
>> inserted, standard linux programs can also send information over
>> the real-time interface. The RTmac.spec document indicates that
>> the rtmac layer wraps data sent through rtmac with an rtmac frame
>> header, and specifies how the non-real-time packets can be
>> tunneled through a real-time network. My first question is: does
>> the rtmac/nomac configuration still add the rtmac header? I
>> assumed the answer was "yes", but perhaps I am wrong.
>
> The answer is yes, but only for the packets sent from non real-time
> applications. The UDP packets sent using RTnet sockets are plain IP
> packets compatible with normal IP stacks.
>
>>
>> My initial RTnet application is to send UDP packets in real-time
>> to a hardware device manufactured by someone else. Since I am not
>> in control of the receiving device, I cannot have any additional
>> headers added to my packets. Can I do this without the rtmac
>> module inserted? Can I do this with rtmac and nomac inserted? If
>> so, what would be the advantage in my application? At some point I
>> may need to send/receive TCP and UDP packets for non-real-time
>> configuration purposes, but I don't see any need to communicate
>> from standard linux programs at this time.
>>
>> Thank you again to everyone for their input. The documentation is
>> not very clear on how (or even if) rtnet can be used to do what I
>> need.
>
> To be able to send plain IP packets using Linux sockets without the
> rtmac tunneling, you can use rtnetproxy. The problem with rtnetproxy
> is that it creates only one linux interface, and then routing is
> done by rtnet. While it may be sufficient for typical applications,
> it is insufficient for network oriented equipments which need
> NAT, or per-interface QOS settings.
>
> A solution to this need is to create, like rtmac does, one linux
> interface by rtnet interface, but do not do the tunneling that rtmac
> does. A long time ago, when I worked for a company which was using
> RTnet, I did exactly that, modifying the nomac policy, but the
> patches did not went far into rtnet (you can probably find them in
> rtnet archives though).
>
> My plan is to do the same thing, but adding a new mac policy which
> would be dubbed xmac (like cross-mac) in xenomai 3 tree. I can not
> make any promise on that though, since I have plenty to do already
> with rtnet, as I have posted. Ideally, what I would like to do, is
> to have, for each NIC, one RT interface which gives good latencies,
> and a plain linux interface which allows high throughput.
>

Thanks, Gilles.  That explanation helps a lot.

-Jeff

Re: [RTnet-users] [Xenomai] Add "rtroute solicit" support to the rtnet script and rtnet.conf

[Gilles C. <gil...@xe...>]

On Thu, Dec 18, 2014 at 08:35:32AM -0600, Jeff Webb wrote:
> On 12/17/2014 04:31 AM, Gilles Chanteperdrix wrote:
> > On Tue, Dec 16, 2014 at 03:51:16PM -0600, Jeff Webb wrote:
> >> I am using rtnet without rtmac/tdma. I previously sent a patch
> >> that allows one to use the "rtnet" script and rtnet.conf in this
> >> configuration. I would also like to be able to specify a list of
> >> IP addresses in rtnet.conf that are passed along to "rtroute
> >> solicit". I have attached patches for the rtnet and
> >> xenomai-3.git/next repositories. I think others will find them
> >> useful.
> >
> > Well, you should probably be using "nomac" if you are not interested
> > in tdma.
> >
> 
> Thank you for your response. I appreciate your advice, Gilles, and
> even more so, since I am new to RTnet. I am somewhat confused by
> the rtmac/nomac configuration, since I haven't found a lot of
> documentation on it. Something I read indicated that the primary
> purpose was for use as skeleton when writing new MAC
> implementations, but it also seems that it is useful for other
> purposes. I have a couple questions that might clarify things for
> me a bit.
> 
> There are a couple of ASCII-art drawings at the beginning of the
> README.rtmac file in the rtnet documentation. The first one seems
> to indicate that rtnet can be used without rtmac, if all
> communication is done from RT applications. I see that with rtmac
> inserted, standard linux programs can also send information over
> the real-time interface. The RTmac.spec document indicates that
> the rtmac layer wraps data sent through rtmac with an rtmac frame
> header, and specifies how the non-real-time packets can be
> tunneled through a real-time network. My first question is: does
> the rtmac/nomac configuration still add the rtmac header? I
> assumed the answer was "yes", but perhaps I am wrong.

The answer is yes, but only for the packets sent from non real-time
applications. The UDP packets sent using RTnet sockets are plain IP
packets compatible with normal IP stacks.

> 
> My initial RTnet application is to send UDP packets in real-time
> to a hardware device manufactured by someone else. Since I am not
> in control of the receiving device, I cannot have any additional
> headers added to my packets. Can I do this without the rtmac
> module inserted? Can I do this with rtmac and nomac inserted? If
> so, what would be the advantage in my application? At some point I
> may need to send/receive TCP and UDP packets for non-real-time
> configuration purposes, but I don't see any need to communicate
> from standard linux programs at this time.
> 
> Thank you again to everyone for their input. The documentation is
> not very clear on how (or even if) rtnet can be used to do what I
> need.

To be able to send plain IP packets using Linux sockets without the
rtmac tunneling, you can use rtnetproxy. The problem with rtnetproxy
is that it creates only one linux interface, and then routing is
done by rtnet. While it may be sufficient for typical applications,
it is insufficient for network oriented equipments which need
NAT, or per-interface QOS settings.

A solution to this need is to create, like rtmac does, one linux
interface by rtnet interface, but do not do the tunneling that rtmac
does. A long time ago, when I worked for a company which was using
RTnet, I did exactly that, modifying the nomac policy, but the
patches did not went far into rtnet (you can probably find them in
rtnet archives though).

My plan is to do the same thing, but adding a new mac policy which
would be dubbed xmac (like cross-mac) in xenomai 3 tree. I can not
make any promise on that though, since I have plenty to do already
with rtnet, as I have posted. Ideally, what I would like to do, is
to have, for each NIC, one RT interface which gives good latencies,
and a plain linux interface which allows high throughput.

-- 
					    Gilles.

Re: [RTnet-users] [Xenomai] Add "rtroute solicit" support to the rtnet script and rtnet.conf

[Jeff W. <jef...@nt...>]

On 12/17/2014 04:31 AM, Gilles Chanteperdrix wrote:
> On Tue, Dec 16, 2014 at 03:51:16PM -0600, Jeff Webb wrote:
>> I am using rtnet without rtmac/tdma. I previously sent a patch
>> that allows one to use the "rtnet" script and rtnet.conf in this
>> configuration. I would also like to be able to specify a list of
>> IP addresses in rtnet.conf that are passed along to "rtroute
>> solicit". I have attached patches for the rtnet and
>> xenomai-3.git/next repositories. I think others will find them
>> useful.
>
> Well, you should probably be using "nomac" if you are not interested
> in tdma.
>

Thank you for your response.  I appreciate your advice, Gilles, and even more so, since I am new to RTnet.  I am somewhat confused by the rtmac/nomac configuration, since I haven't found a lot of documentation on it.  Something I read indicated that the primary purpose was for use as skeleton when writing new MAC implementations, but it also seems that it is useful for other purposes.  I have a couple questions that might clarify things for me a bit.

There are a couple of ASCII-art drawings at the beginning of the README.rtmac file in the rtnet documentation.  The first one seems to indicate that rtnet can be used without rtmac, if all communication is done from RT applications.  I see that with rtmac inserted, standard linux programs can also send information over the real-time interface.  The RTmac.spec document indicates that the rtmac layer wraps data sent through rtmac with an rtmac frame header, and specifies how the non-real-time packets can be tunneled through a real-time network.  My first question is: does the rtmac/nomac configuration still add the rtmac header?  I assumed the answer was "yes", but perhaps I am wrong.

My initial RTnet application is to send UDP packets in real-time to a hardware device manufactured by someone else.  Since I am not in control of the receiving device, I cannot have any additional headers added to my packets.  Can I do this without the rtmac module inserted?  Can I do this with rtmac and nomac inserted?  If so, what would be the advantage in my application?  At some point I may need to send/receive TCP and UDP packets for non-real-time configuration purposes, but I don't see any need to communicate from standard linux programs at this time.

Thank you again to everyone for their input.  The documentation is not very clear on how (or even if) rtnet can be used to do what I need.

-Jeff

Re: [RTnet-users] [Xenomai] Add "rtroute solicit" support to the rtnet script and rtnet.conf

[Gilles C. <gil...@xe...>]

On Tue, Dec 16, 2014 at 03:51:16PM -0600, Jeff Webb wrote:
> I am using rtnet without rtmac/tdma. I previously sent a patch
> that allows one to use the "rtnet" script and rtnet.conf in this
> configuration. I would also like to be able to specify a list of
> IP addresses in rtnet.conf that are passed along to "rtroute
> solicit". I have attached patches for the rtnet and
> xenomai-3.git/next repositories. I think others will find them
> useful.

Well, you should probably be using "nomac" if you are not interested
in tdma.

-- 
					    Gilles.

Re: [RTnet-users] [Xenomai] Add cards parameter to rt_e1000e module?

[Jeff W. <jef...@nt...>]

On 12/15/2014 02:04 PM, Mariusz Janiak wrote:
>>>> Certainly a well behaved driver would not touch a device already handled
>>>> by a linux driver.  It should be possible to just issue an unbind request
>>>> to the linux driver for the desired device and then a bind request to
>>>> the rtnet driver to take over that device.
>>
>> Thanks for sharing this information.  It sounds like that might work.
>>
>>> The problem with the
>>> bind/unbind solution is that the driver that will get all the cards
>>> first depends on the drivers initialization order. With the "cards"
>>> parameter, you do not have this issue.
>>
>> Maybe one could create a script that would attempt to unbind both the rt and non-rt drivers (or check to see which one is bound and then unbind it), and then make the desired "bind" calls.  It would be better if the incorrect binding were not made in the first place, however.  I think the ideal solution would be to have a file that contains device/driver pairs that would keep the kernel from passing the specified devices to any other drivers.  I wonder how hard that would be to implement.
>
> The RTnet configuration file rtnet.conf has already instrumentation for binding/unbinding devices. The REBIND_RT_NICS variable has to be set up with the correct NIC PCI addresses. If you have more then one NIC, you can identity PCI address of respective eth's using ethtool
>
> ethtool -i eth0
> ethtool -i eth1
>
> etc.
>
> The bus-info field contains device pci addres that you can directly insert to REBIND_RT_NICS. If you don't know which eth menage with physical interface, you can blink LED port of the NIC using, eg.
>
> ethtool -p eth0

(I am cross-posting this message to rtnet-users from the xenomai mailing list, since this is even more relevant there.  I apologize to those who receive duplicate e-mails.)

Thank you again, Mariusz.  All of this information is helpful.  I was following the instructions to start the RTnet core manually (as documented in the README file), since I am not using RTmac in my application.  I saw some references to REBIND_RT_NICS, but I didn't look into it very closely, since rtnet.conf and the "rtnet" script appeared to associated with RTmac.

After looking at the "rtnet" script, I see that it does indeed use bind/unbind in exactly the way we were discussing.  The script works very works well to switch an interface between standard and real-time networking, but unfortunately it does not support running without the RTmac layer.  I made some minor modifications to the script to add this support.  With my modifications, if TDMA_MODE = "none" (instead of "master" or "slave"), the script skips all of the rtmac/rtcfg/tmda initialization.  I have attached patches for both the rtnet and xenomai-3.git/next repositories.  I hope that they will be accepted, since I believe others have asked for this functionality in the past.

Gilles, it appears that the "cards" parameter may not be needed anymore, unless there are some other situations in which bind/unbind won't work.  I can see how that would make maintaining the RT drivers simpler.

-Jeff

[RTnet-users] Add "rtroute solicit" support to the rtnet script and rtnet.conf

[Jeff W. <jef...@nt...>]

I am using rtnet without rtmac/tdma.  I previously sent a patch that allows one to use the "rtnet" script and rtnet.conf in this configuration.  I would also like to be able to specify a list of IP addresses in rtnet.conf that are passed along to "rtroute solicit".  I have attached patches for the rtnet and xenomai-3.git/next repositories.  I think others will find them useful.

-Jeff

(P.S. I am cross-posting this message to both rtnet-users and the xenomai mailing lists, since I have attached patches relevant to both git repositories.  I apologize to those who receive duplicate e-mails.)

[RTnet-users] RTnet compilation issues with kernel above 3.10

[Mariusz J. <mar...@wp...>]

Dnia Poniedziałek, 15 Grudnia 2014 22:24 Mariusz Janiak <mar...@wp...> napisał(a) 
> Hi,
> 
> Following patch should fix the RTnet compilation issues on a kernel 3.10 and higher, especially the latest supported 3.14.17 by the Xenomai 2.6.4. It is based on the Anders Blomdell patch
> 
> http://sourceforge.net/p/rtnet/mailman/message/32034653/
> 
> supplemented with missing parts. 
> 
> Best regards,
> Mariusz Janiak

Now witch missing attachment.

Mariusz

> 
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> RTnet-users mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-users

[RTnet-users] RTnet compilation issues with kernel above 3.10

[Mariusz J. <mar...@wp...>]

Hi,

Following patch should fix the RTnet compilation issues on a kernel 3.10 and higher, especially the latest supported 3.14.17 by the Xenomai 2.6.4. It is based on the Anders Blomdell patch

http://sourceforge.net/p/rtnet/mailman/message/32034653/

supplemented with missing parts. 

Best regards,
Mariusz Janiak

Re: [RTnet-users] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

On Sat, Nov 22, 2014 at 12:23:49AM +0100, Jeroen Van den Keybus wrote:
> >
> >
> > - the NAPI will be implemented. The NAPI thread will run with the
> > priority of the highest priority waiting thread, and will call
> > rt_stack_deliver, in order not to increase the RX latency compared
> > to the current solution.
> 
> 
> Would you just poll this thread continuously, at high rate ? I'm asking
> because I'd expect the poll method to be called only at moderate rates and
> registers may be read or written.

You can not really guarantee low RX latency if the NAPI thread does
not poll hardware as soon as a packet is received. One thing to
understand though is that the NAPI thread will generally be
sleeping, and be just woken up on the reception of the first RX irq,
at which point RX irq will be disabled at the NIC level, all the
received packets will be processed, then the RX irq will be
re-enabled at NIC level, and the NAPI thread will go back to sleep.
> 
> Maybe the RTnet drivers contain some modifications for low latency
> > like reducing the TX ring length, but I believe putting these
> > modifications in the drivers is not a so good idea:
> > - it means that the modification is to be made in each driver, and
> > needs to be maintained;
> > - in the particular case of the TX ring, reducing the number of
> > queued packets in hardware is not a really precise way to guarantee
> > a bounded latency, because the latency is proportional to the number
> > of bytes queued, not on the number of packets, and ethernet packets
> > have widely varying sizes.
> >
> 
> I fully agree.
> 
> 
> > Please feel free to send any reaction to this mail.
> >
> 
> I've always been wondering if it would be possible to emulate the entire
> Linux netdev system in realtime instead, essentially avoiding any driver
> modification at all. 

The plan is to approach this goal. We have to rename the functions
to avoid the symbol names clashes, but I would like the conversion
to be really automatic. One thing I will not do, however, is spend
time trying and emulating the last 20% of the netdev API that would
cost me 80% of the development effort.

> However, this would also include the handling of the
> various task registrations (INIT_WORK) a driver typically does (the e1000e
> registers five). But these may still be handled by Linux, perhaps.

Actually, I have added the rtdm_schedule_nrt_work() service allowing
to trigger workqueues in Linux domain, from Xenomai domain:

http://git.xenomai.org/xenomai-gch.git/commit/?h=for-forge&id=ee703d9785f7e242057ef689bc500b965cd75294
 

> 
> Though it could very well be a large undertaking, I'm not sure if modifying
> the individual drivers (and often the various codepaths for different card
> variants inside them) would entail less effort in the end.

Well, part, if not majority of the maintenance work is to get the
drivers to follow mainline changes. We need this because it allows
supporting new hardware, and in case the mainline changes contain
fixes. To make that job easy, we need to modify them as little as
possible to integrate into RTnet, because every change we make will
have to be carried from one version to the next, and have chance to
get broken by the mainline changes.

-- 
					    Gilles.

Re: [RTnet-users] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

On Fri, Nov 21, 2014 at 11:08:44PM +0100, Richard Cochran wrote:
> On Fri, Nov 21, 2014 at 10:48:39PM +0100, Gilles Chanteperdrix wrote:
> > On Fri, Nov 21, 2014 at 10:53:05AM +0100, Richard Cochran wrote:
> > > This is the reason that, every time I considered using rtnet, I ended
> > > up deciding against it.
> > 
> > Well, on the other hand, picking one driver, and improving it for
> > the project which needs it was not an insurmountable task.
> 
> Except when you have a napi driver. Then, although not insurmountable,
> it still is a formidable task. (But that is changing, now ;)
> 
> > > this work is *long* overdue!
> > 
> > Well, for it to be overdue, it would have to have been due in the
> > first place. And since as far as I know, nobody paid for it and was
> > expecting a result, and nobody ever promised anything (well up to
> > now, I kind of made the promise, now), I do not really think it was
> > due. Or maybe I am just misinterpreting the meaning of overdue.
> 
> I did mean that you or anyone else owed anyone anything. I only meant
> to say that it was unfortunate that rtnet has stagnated, especially
> considering the wide industry interest in real time Ethernet.

If you need a project, and you let it stagnate, then you can not
really complain, you are just as responsible as every other user
doing the same.

> 
> And for paying the bill, no one wants to pay for preempt_rt either!

I did not say no one pays the bill for Xenomai! Just that no one
paid for refreshing RTNet. For the record, just speaking for myself,
it is quite the contrary. The contribution to RTnet of support for
NIC statistics and Xenomai and RTnet support for the select service,
to name the most significant patches, was made while I was paid to
work with Xenomai and RTnet. Since then, I have been doing my
maintainer job mostly as a hobbyist, which BTW, I believe did not
result in a dramatic decrease in either the quality or the quantity
of my contributions. You can find on this page:

http://www.denx.de/en/Software/SoftwareXenomaiProjects 

some ports of Xenomai to ARM boards for which I earned money (and a
little more which are not on the page, Freescale i.MX53, i.MX6Q,
i.MX28 and ST SPEAr600). And finally, I have received donations of
boards from several companies, for which I thank them, it is really
helping me doing the maintainer job. I am not going to list the
companies here, because I am not sure all of them want it to be
publicly known that they use Xenomai (Xenomai has that kind of
users), but I can give the boards list: Cogent Computer CSB637, a
custom board based on AT91SAM9260, an Advantech board based on AMD
Geode, an AOpen mini-PC based on Intel Core 2 duo, a Calao systems
USBA9263, an ISEE IGEPv2, recently an Atmel Xplained board, based on
the brand new AT91SAMA5D3, and just yesterday, a mail from a company
proposing me an i.MX6Q based board.


> > Maybe the next step will be to integrate the support for PTP. In
> > that case, I hope we will get your help to do the job.
> 
> Happy to help, if I can. If the drivers can stay close to mainline,
> then probably there isn't too much to do. The ptp stack itself does
> not need real time guarantees in order to operate. The one thing I can
> think of that might be needed is synchronization from the MAC clock to
> the xenomai system clock.

This is going to be hard. Maybe easier, we could add a posix clock
ID, like CLOCK_PTP, to have access to that clock from primary mode.

> 
> Also, regarding rtnet, the i210 is an inexpensive card that allows
> transmission scheduling at given time. That might be something to take
> advantage of.

Ok, thanks, will look into it.

Regards.

-- 
					    Gilles.

Re: [RTnet-users] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

On Fri, Nov 21, 2014 at 10:53:05AM +0100, Richard Cochran wrote:
> Hi Gilles,
> 
> On Fri, Nov 21, 2014 at 10:08:57AM +0100, Gilles Chanteperdrix wrote:
> > The drivers, on the other hand, are a bit more worrying. They are
> > based on seriously outdated versions of the corresponding Linux
> > drivers, with support for much less hardware, and probably missing
> > some bug fixes. So, putting the drivers into a better shape and
> > making it easy to track mainline changes will be my first priority.
> 
> This is the reason that, every time I considered using rtnet, I ended
> up deciding against it.

Well, on the other hand, picking one driver, and improving it for
the project which needs it was not an insurmountable task.

> 
> > Please feel free to send any reaction to this mail.
> 
> Good luck,

Thanks.

> this work is *long* overdue!

Well, for it to be overdue, it would have to have been due in the
first place. And since as far as I know, nobody paid for it and was
expecting a result, and nobody ever promised anything (well up to
now, I kind of made the promise, now), I do not really think it was
due. Or maybe I am just misinterpreting the meaning of overdue.

Anyway, to make things perfectly clear on that subject, I am not
doing this because I feel the Xenomai project owes it to anyone,
only because I like the idea of working on that project and that it
may be useful for a lot of Xenomai dual-kernel applications.

Maybe the next step will be to integrate the support for PTP. In
that case, I hope we will get your help to do the job.

Regards.

-- 
					    Gilles.