[Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

 	Hi,

  Well, recent changes marks kernel use of native/task.h as deprecated. 
I've read the FAQ, but still has questions. Suppose some kernel Xenomai RT 
driver need to be written. This driver is using pipes to exchange with 
non-rt userspace applications. The previous development model was simple :

............................. driver-module.c ...................

void process_task(void *)
{
  while (1) {
 	res = rt_pipe_read(...);
 	if (res > 0)
 		do_some_processing(...);
  }
}

int init_module()
{
  rt_pipe_create(...)
  rt_task_create(...);
  rt_task_start(...)
}

.............................

  Now as rt_task_create/rt_task_start are deprecated, can anybody 
briefly describe how such driver need to be developed ?

Thanks in advance.

P.S.	By the way - pipe.c example from Xenomai documentation still use
 	deprecated system calls from kernel space. Seems like this
 	confusing example need to be rewritten accordinly to new Xenomai
 	2.5/3.0 development paradigm.


 		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Gilles Chanteperdrix]

Rus V. Brushkoff wrote:
>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
> briefly describe how such driver need to be developed ?

Using the RTDM skin.

-- 
                                          Gilles

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:

:Rus V. Brushkoff wrote:
:>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
:> briefly describe how such driver need to be developed ?
:
:Using the RTDM skin.

 You mean replace pair of rt_task_create/rt_task_start with 
rtdm_task_init() call ?


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:

:Rus V. Brushkoff wrote:
:>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
:> briefly describe how such driver need to be developed ?
:
:Using the RTDM skin.

Can you show this paradigm on pipe.c exmaple from Xenomai docs ?


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Gilles Chanteperdrix]

Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
> 
> :Rus V. Brushkoff wrote:
> :>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
> :> briefly describe how such driver need to be developed ?
> :
> :Using the RTDM skin.
> 
> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?

We are talking about drivers, then just design your driver as you would
design a Linux driver.

For instance, you would implement the "write" method of the driver to
pass data between the user-space task and the driver.

Could you please use a valid e-mail address? I am receiving bounces from
your mail server when trying to reply.

-- 
                                          Gilles

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

:> :>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
:> :> briefly describe how such driver need to be developed ?
:> :
:> :Using the RTDM skin.
:> 
:> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
:
:We are talking about drivers, then just design your driver as you would
:design a Linux driver.
:
:For instance, you would implement the "write" method of the driver to
:pass data between the user-space task and the driver.

 This is RT driver not simply Linux driver. The previous rt_pipe_read() 
call was running in RT task context. Now it is not clear how this can be 
achieved with new RTDM driver model in kernel space.

:Could you please use a valid e-mail address? I am receiving bounces from
:your mail server when trying to reply.

 I'm receiving xenomai and couple of other mail-list with no problem. So 
have received this message. Please post privatly the exact SMTP bounce 
message - so I can investigate the problem.

TIA


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Gilles Chanteperdrix]

Rus V. Brushkoff wrote:
> :> :>   Now as rt_task_create/rt_task_start are deprecated, can anybody 
> :> :> briefly describe how such driver need to be developed ?
> :> :
> :> :Using the RTDM skin.
> :> 
> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :
> :We are talking about drivers, then just design your driver as you would
> :design a Linux driver.
> :
> :For instance, you would implement the "write" method of the driver to
> :pass data between the user-space task and the driver.
> 
>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> call was running in RT task context. Now it is not clear how this can be 
> achieved with new RTDM driver model in kernel space.

The write method of an RTDM driver can run in rt context too. If the
task which issues the call to "write" is a Xenomai user-space task
running in primary mode.

-- 
                                          Gilles

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:

:> :> :Using the RTDM skin.
:> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
:> :We are talking about drivers, then just design your driver as you would
:> :design a Linux driver.
:> :For instance, you would implement the "write" method of the driver to
:> :pass data between the user-space task and the driver.
:>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
:> call was running in RT task context. Now it is not clear how this can be 
:> achieved with new RTDM driver model in kernel space.
:
:The write method of an RTDM driver can run in rt context too. If the
:task which issues the call to "write" is a Xenomai user-space task
:running in primary mode.

 Please note - I do not have any Xenomai user-space tasks running - only 
normal user space programs. The Xenomai-2.4 allows developing of RT driver 
in kernel space - leaving untouchable user space processes. If such new 
paradigm need to write the intermediate user-space RT task proxy - than 
it is wrong. Simply because its adds unneeded complexity to developing RT 
kernel hardware drivers.


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Gilles Chanteperdrix]

Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
> 
> :> :> :Using the RTDM skin.
> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :> :We are talking about drivers, then just design your driver as you would
> :> :design a Linux driver.
> :> :For instance, you would implement the "write" method of the driver to
> :> :pass data between the user-space task and the driver.
> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> :> call was running in RT task context. Now it is not clear how this can be 
> :> achieved with new RTDM driver model in kernel space.
> :
> :The write method of an RTDM driver can run in rt context too. If the
> :task which issues the call to "write" is a Xenomai user-space task
> :running in primary mode.
> 
>  Please note - I do not have any Xenomai user-space tasks running - only 
> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
> in kernel space - leaving untouchable user space processes. If such new 
> paradigm need to write the intermediate user-space RT task proxy - than 
> it is wrong. Simply because its adds unneeded complexity to developing RT 
> kernel hardware drivers.

You do not need a proxy. What you need to do is to create the previous
non real-time task as a Xenomai task, using rt_task_create, or the
Xenomai posix skin's pthread_create. Then you would change this task to
use RTDM's write instead of write. That is all. Everything else stays
the same. And as an additonal benefit, you have one less task running if
you can avoid to create the kernel-space task, and do everything in the
write callback.

Separating clearly the driver code running in kernel-space from the
application code running in user-space is clear win. It leads to a code
easier to maintain, and avoid taking risks of running too many code in
the unprotected kernel-space.

-- 
                                          Gilles

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:

:> :> :For instance, you would implement the "write" method of the driver to
:> :> :pass data between the user-space task and the driver.
:> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
:> :> call was running in RT task context. Now it is not clear how this can be 
:> :> achieved with new RTDM driver model in kernel space.
:> :The write method of an RTDM driver can run in rt context too. If the
:> :task which issues the call to "write" is a Xenomai user-space task
:> :running in primary mode.
:>  Please note - I do not have any Xenomai user-space tasks running - only 
:> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
:> in kernel space - leaving untouchable user space processes. If such new 
:> paradigm need to write the intermediate user-space RT task proxy - than 
:> it is wrong. Simply because its adds unneeded complexity to developing RT 
:> kernel hardware drivers.
:
:You do not need a proxy. What you need to do is to create the previous
:non real-time task as a Xenomai task, using rt_task_create, or the
:Xenomai posix skin's pthread_create. Then you would change this task to
:use RTDM's write instead of write. That is all. Everything else stays
:the same. And as an additonal benefit, you have one less task running if

 No, this means I need to change the previous non-rt user-space software 
to RT one. Problem is that exists some projects that can't be simply 
changed in this way, for example we use asterisk as non-rt user space 
process - it changing means creating and supporting previously unneeded 
patches.

:Separating clearly the driver code running in kernel-space from the
:application code running in user-space is clear win. It leads to a code
:easier to maintain, and avoid taking risks of running too many code in
:the unprotected kernel-space.

 I do not see the win in decreasing number of the API functions. So I see 
the problem with porting Xenomai-2.4 apps, written by provided pipe.c 
example from the docs, to Xenomai-2.5 and later. Next - I do not 
understand why the previous model lets the _developer_ itself decide 
which of the application tasks will be running in kernel and which will 
be running in user space. The current model left the people without any 
choice. So the current model itself decided instead of developer what is 
better - I think this is wrong.


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Philippe Gerum]

On Wed, 2009-09-02 at 15:00 +0300, Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
> 
> :> :> :For instance, you would implement the "write" method of the driver to
> :> :> :pass data between the user-space task and the driver.
> :> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> :> :> call was running in RT task context. Now it is not clear how this can be 
> :> :> achieved with new RTDM driver model in kernel space.
> :> :The write method of an RTDM driver can run in rt context too. If the
> :> :task which issues the call to "write" is a Xenomai user-space task
> :> :running in primary mode.
> :>  Please note - I do not have any Xenomai user-space tasks running - only 
> :> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
> :> in kernel space - leaving untouchable user space processes. If such new 
> :> paradigm need to write the intermediate user-space RT task proxy - than 
> :> it is wrong. Simply because its adds unneeded complexity to developing RT 
> :> kernel hardware drivers.
> :
> :You do not need a proxy. What you need to do is to create the previous
> :non real-time task as a Xenomai task, using rt_task_create, or the
> :Xenomai posix skin's pthread_create. Then you would change this task to
> :use RTDM's write instead of write. That is all. Everything else stays
> :the same. And as an additonal benefit, you have one less task running if
> 
>  No, this means I need to change the previous non-rt user-space software 
> to RT one. Problem is that exists some projects that can't be simply 
> changed in this way, for example we use asterisk as non-rt user space 
> process - it changing means creating and supporting previously unneeded 
> patches.
> 

This has been answered in a previous mail.

> :Separating clearly the driver code running in kernel-space from the
> :application code running in user-space is clear win. It leads to a code
> :easier to maintain, and avoid taking risks of running too many code in
> :the unprotected kernel-space.
> 
>  I do not see the win in decreasing number of the API functions. So I see 
> the problem with porting Xenomai-2.4 apps, written by provided pipe.c 
> example from the docs, to Xenomai-2.5 and later.

No, 2.5 still has the in-kernel APIs. Only Xenomai v3 will change this.

>  Next - I do not 
> understand why the previous model lets the _developer_ itself decide 
> which of the application tasks will be running in kernel and which will 
> be running in user space. The current model left the people without any 
> choice. So the current model itself decided instead of developer what is 
> better - I think this is wrong.

With that kind of reasoning, you would keep on coding your RT
application fully in kernel space, but we made some progress since 1997,
fortunately.

The point of Xenomai has always been about keeping the RT programming
model as close as possible to the one we would use to code common
applications not depending on any dual kernel support. Now we want to
break the last wall, which means enforcing a cleaner and safer
application / device driver split model. This will allow people to pick
the best option between dual kernel and PREEMPT_RT configurations,
depending on their requirements.

To sum up, the point is not about losing any freedom to develop kernel
code at all, it is about being discouraged from perpetuating legacy
_application_ designs (not driver) that were only there to mitigate
restrictions  on legacy dual kernel systems which did not provide any
userland interface to applications.

Said differently, implementing a complete application (RT or not) in
kernel space has always been sub-optimal with respect to the common
programming model. It just happened to be the only possible way to work
in the stone age of real-time Linux, when one had to trade separate
address spaces and tool availability off against better latencies. This
is no more required, and since we do have a sane and normalized
real-time driver model with RTDM, and the incentive to enforce a correct
application / driver split, the time has come to evolve.

Even if Xenomai-wise, that evolution will only start with Xenomai v3,
application designers may want to integrate this fact as early as
possible, or disable CONFIG_XENO_OPT_NOWARN_DEPRECATED and stick with
v2.5.

> 
> 
> 		Rus
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Philippe Gerum wrote:

:>  Next - I do not 
:> understand why the previous model lets the _developer_ itself decide 
:> which of the application tasks will be running in kernel and which will 
:> be running in user space. The current model left the people without any 
:> choice. So the current model itself decided instead of developer what is 
:> better - I think this is wrong.
:
:With that kind of reasoning, you would keep on coding your RT
:application fully in kernel space, but we made some progress since 1997,
:fortunately.

 Sorry, but device drivers for hardware that need RT processing can't be 
written in user space. Dealing with interrupts, PCI, DMA, I/O ports can 
be done only in kernel space. So it is not possible to decide at the 
Xenomai architect level wich driver task are optimal to run in which mode 
- it will depends from the particular development problem area.
 So I think that forcing people to write the RT tasks only in user space 
will make unneded latencies, which will be inserted by data passing 
between user and kernel domains.
 Next: the traditional and clean Unix programming concept suppose that 
user space applications are simple and operate on the files/pipes that 
are attached to kernel drivers. It will be better to leave this concept 
live as it proved its architect efficiency.

:The point of Xenomai has always been about keeping the RT programming
:model as close as possible to the one we would use to code common
:applications not depending on any dual kernel support. Now we want to
:break the last wall, which means enforcing a cleaner and safer
:application / device driver split model. This will allow people to pick
:the best option between dual kernel and PREEMPT_RT configurations,
:depending on their requirements.

 No problem about breaking the wall - but you are breaking the existing 
applications. So you will restrict the developers freedom. I see this as 
the same that if, for example, Linux kernel developers will decide once 
time to disable at all kernel modules development - all people will be 
forced to write drivers in userspace, motivied for example - that "you 
will never write the good driver or driver without bugs, and the kernel 
will crash, and you will expect problems, but from that time - you are 
free from this beacause module development is prohibited."

:To sum up, the point is not about losing any freedom to develop kernel
:code at all, it is about being discouraged from perpetuating legacy
:_application_ designs (not driver) that were only there to mitigate
:restrictions  on legacy dual kernel systems which did not provide any
:userland interface to applications.

 The freedom means posibility to develop selecting model as it is needed 
by the current task conditions. It is good if some new paradigm exists - 
people will select themselves what they will use. If the people can't 
select the Xenomai development model - this is called enforcement, but 
not the freedom.

:Said differently, implementing a complete application (RT or not) in
:kernel space has always been sub-optimal with respect to the common
:programming model. It just happened to be the only possible way to work
:in the stone age of real-time Linux, when one had to trade separate
:address spaces and tool availability off against better latencies. This
:is no more required, and since we do have a sane and normalized
:real-time driver model with RTDM, and the incentive to enforce a correct
:application / driver split, the time has come to evolve.

 It is clear that developing all in kernel space is bad, but from other 
side developing all in user space is bad too. Because you can't say now 
where this margin will be - it fully depends from the particular task 
requrements. It is very strange that it is not clear - how many kind of 
RT programming tasks can exist in future.

:Even if Xenomai-wise, that evolution will only start with Xenomai v3,
:application designers may want to integrate this fact as early as
:possible, or disable CONFIG_XENO_OPT_NOWARN_DEPRECATED and stick with
:v2.5.

 Better I will patch Xenomai with needed backport feature than will do 
a plenty amount of unneded job in future.

:

		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Philippe Gerum]

On Wed, 2009-09-02 at 17:34 +0300, Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Philippe Gerum wrote:
> 
> :>  Next - I do not 
> :> understand why the previous model lets the _developer_ itself decide 
> :> which of the application tasks will be running in kernel and which will 
> :> be running in user space. The current model left the people without any 
> :> choice. So the current model itself decided instead of developer what is 
> :> better - I think this is wrong.
> :
> :With that kind of reasoning, you would keep on coding your RT
> :application fully in kernel space, but we made some progress since 1997,
> :fortunately.
> 
>  Sorry, but device drivers for hardware that need RT processing can't be 
> written in user space.

Please, would you mind re-reading my various answers again, and properly
interpret "application" and "driver" for what they really mean?

>  Dealing with interrupts, PCI, DMA, I/O ports can 
> be done only in kernel space. So it is not possible to decide at the 
> Xenomai architect level wich driver task are optimal to run in which mode 
> - it will depends from the particular development problem area.
>  So I think that forcing people to write the RT tasks only in user space 
> will make unneded latencies, which will be inserted by data passing 
> between user and kernel domains.
>  Next: the traditional and clean Unix programming concept suppose that 
> user space applications are simple and operate on the files/pipes that 
> are attached to kernel drivers. It will be better to leave this concept 
> live as it proved its architect efficiency.
> 
> :The point of Xenomai has always been about keeping the RT programming
> :model as close as possible to the one we would use to code common
> :applications not depending on any dual kernel support. Now we want to
> :break the last wall, which means enforcing a cleaner and safer
> :application / device driver split model. This will allow people to pick
> :the best option between dual kernel and PREEMPT_RT configurations,
> :depending on their requirements.
> 
>  No problem about breaking the wall - but you are breaking the existing 
> applications. So you will restrict the developers freedom. I see this as 
> the same that if, for example, Linux kernel developers will decide once 
> time to disable at all kernel modules development - all people will be 
> forced to write drivers in userspace, motivied for example - that "you 
> will never write the good driver or driver without bugs, and the kernel 
> will crash, and you will expect problems, but from that time - you are 
> free from this beacause module development is prohibited."
> 
> :To sum up, the point is not about losing any freedom to develop kernel
> :code at all, it is about being discouraged from perpetuating legacy
> :_application_ designs (not driver) that were only there to mitigate
> :restrictions  on legacy dual kernel systems which did not provide any
> :userland interface to applications.
> 
>  The freedom means posibility to develop selecting model as it is needed 
> by the current task conditions. It is good if some new paradigm exists - 
> people will select themselves what they will use. If the people can't 
> select the Xenomai development model - this is called enforcement, but 
> not the freedom.
> 
> :Said differently, implementing a complete application (RT or not) in
> :kernel space has always been sub-optimal with respect to the common
> :programming model. It just happened to be the only possible way to work
> :in the stone age of real-time Linux, when one had to trade separate
> :address spaces and tool availability off against better latencies. This
> :is no more required, and since we do have a sane and normalized
> :real-time driver model with RTDM, and the incentive to enforce a correct
> :application / driver split, the time has come to evolve.
> 
>  It is clear that developing all in kernel space is bad, but from other 
> side developing all in user space is bad too. Because you can't say now 
> where this margin will be - it fully depends from the particular task 
> requrements. It is very strange that it is not clear - how many kind of 
> RT programming tasks can exist in future.
> 
> :Even if Xenomai-wise, that evolution will only start with Xenomai v3,
> :application designers may want to integrate this fact as early as
> :possible, or disable CONFIG_XENO_OPT_NOWARN_DEPRECATED and stick with
> :v2.5.
> 
>  Better I will patch Xenomai with needed backport feature than will do 
> a plenty amount of unneded job in future.
> 
> :
> 
> 		Rus
-- 
Philippe.

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Gilles Chanteperdrix]

Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Philippe Gerum wrote:
> 
> :>  Next - I do not 
> :> understand why the previous model lets the _developer_ itself decide 
> :> which of the application tasks will be running in kernel and which will 
> :> be running in user space. The current model left the people without any 
> :> choice. So the current model itself decided instead of developer what is 
> :> better - I think this is wrong.
> :
> :With that kind of reasoning, you would keep on coding your RT
> :application fully in kernel space, but we made some progress since 1997,
> :fortunately.
> 
>  Sorry, but device drivers for hardware that need RT processing can't be 
> written in user space. Dealing with interrupts, PCI, DMA, I/O ports can 
> be done only in kernel space. So it is not possible to decide at the 
> Xenomai architect level wich driver task are optimal to run in which mode 
> - it will depends from the particular development problem area.
>  So I think that forcing people to write the RT tasks only in user space 
> will make unneded latencies, which will be inserted by data passing 
> between user and kernel domains.
>  Next: the traditional and clean Unix programming concept suppose that 
> user space applications are simple and operate on the files/pipes that 
> are attached to kernel drivers. It will be better to leave this concept 
> live as it proved its architect efficiency.

You misunderstand us. We tell you that you should develop drivers in
kernel-space, using the RTDM skin. The RTDM skin is made to resemble the
Linux driver model, so that it will make your drivers easily portable to
vanilla linux.


-- 
                                          Gilles

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Philippe Gerum]

On Wed, 2009-09-02 at 14:25 +0300, Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Gilles Chanteperdrix wrote:
> 
> :> :> :Using the RTDM skin.
> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :> :We are talking about drivers, then just design your driver as you would
> :> :design a Linux driver.
> :> :For instance, you would implement the "write" method of the driver to
> :> :pass data between the user-space task and the driver.
> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> :> call was running in RT task context. Now it is not clear how this can be 
> :> achieved with new RTDM driver model in kernel space.
> :
> :The write method of an RTDM driver can run in rt context too. If the
> :task which issues the call to "write" is a Xenomai user-space task
> :running in primary mode.
> 
>  Please note - I do not have any Xenomai user-space tasks running - only 
> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
> in kernel space - leaving untouchable user space processes. If such new 
> paradigm need to write the intermediate user-space RT task proxy - than 
> it is wrong. Simply because its adds unneeded complexity to developing RT 
> kernel hardware drivers.

The pipe support is indeed one of a kind, since it shares semantics
between RT and non-RT endpoints, and it should be possible to open the
non-RT side from programs which were _not_ linked against any Xenomai
library. E.g. cat /dev/rtp22 should get any data sent from a RT endpoint
bound to the same pseudo-device.

We will solve this issue by having a RTDM-based driver, implementing the
services of the current RT_PIPE support, eventually taping into the
nucleus core. A kernel-space RTDM driver will be able to send/recv data
via the standard inter-driver RTDM interface - this is what your device
driver should do. A user-space RT application will have access to a
socket-type service access point for sending/receiving packets;
semantics close to the AF_UNIX protocol family should be used there. A
non-RT application will still be able to open its endpoint via the usual
open(2) interface, i.e. such as cat /dev/rtpX works as before.

This work is scheduled for Xenomai v3; v2.5.x still provides the
kernel-based APIs available in earlier releases, and as such it is a bit
early for changing your code. This is also why there is no migration
cookbook from v2 -> v3 yet.
The "deprecated" messages are an early warning so that people notice
that things will change in the next major release, and that it may be a
good idea to reconsider any decision to build _applications_ in
kernel-space; you can still disable those messages via the
CONFIG_XENO_OPT_NOWARN_DEPRECATED switch if they get on your nerves.

> 
> 
> 		Rus
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Rus V. Brushkoff]

On Wed, 2 Sep 2009, Philippe Gerum wrote:

:> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
:> :> :We are talking about drivers, then just design your driver as you would
:> :> :design a Linux driver.
:> :> :For instance, you would implement the "write" method of the driver to
:> :> :pass data between the user-space task and the driver.
:> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
:> :> call was running in RT task context. Now it is not clear how this can be 
:> :> achieved with new RTDM driver model in kernel space.
:> :The write method of an RTDM driver can run in rt context too. If the
:> :task which issues the call to "write" is a Xenomai user-space task
:> :running in primary mode.
:>  Please note - I do not have any Xenomai user-space tasks running - only 
:> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
:> in kernel space - leaving untouchable user space processes. If such new 
:> paradigm need to write the intermediate user-space RT task proxy - than 
:> it is wrong. Simply because its adds unneeded complexity to developing RT 
:> kernel hardware drivers.
:The pipe support is indeed one of a kind, since it shares semantics
:between RT and non-RT endpoints, and it should be possible to open the
:non-RT side from programs which were _not_ linked against any Xenomai
:library. E.g. cat /dev/rtp22 should get any data sent from a RT endpoint
:bound to the same pseudo-device.

 Yes, this is one of the issues - most of non-rt apps need to be relinked 
with Xenomai and later supported, that can be impossible in the most 
cases.

:We will solve this issue by having a RTDM-based driver, implementing the
:services of the current RT_PIPE support, eventually taping into the
:nucleus core. A kernel-space RTDM driver will be able to send/recv data
:via the standard inter-driver RTDM interface - this is what your device
:driver should do. A user-space RT application will have access to a
:socket-type service access point for sending/receiving packets;
:semantics close to the AF_UNIX protocol family should be used there. A
:non-RT application will still be able to open its endpoint via the usual
:open(2) interface, i.e. such as cat /dev/rtpX works as before.
:
:This work is scheduled for Xenomai v3; v2.5.x still provides the
:kernel-based APIs available in earlier releases, and as such it is a bit
:early for changing your code. This is also why there is no migration
:cookbook from v2 -> v3 yet.
:The "deprecated" messages are an early warning so that people notice
:that things will change in the next major release, and that it may be a
:good idea to reconsider any decision to build _applications_ in
:kernel-space; you can still disable those messages via the
:CONFIG_XENO_OPT_NOWARN_DEPRECATED switch if they get on your nerves.

 I think that marking some feature as deprecated need to be done _after_ 
the ready up new solution exists, including examples in Xenomai docs. Now 
Xenomai users are facing with problem that has no solution yet.


		Rus

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Philippe Gerum]

On Wed, 2009-09-02 at 15:04 +0300, Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Philippe Gerum wrote:
> 
> :> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :> :> :We are talking about drivers, then just design your driver as you would
> :> :> :design a Linux driver.
> :> :> :For instance, you would implement the "write" method of the driver to
> :> :> :pass data between the user-space task and the driver.
> :> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> :> :> call was running in RT task context. Now it is not clear how this can be 
> :> :> achieved with new RTDM driver model in kernel space.
> :> :The write method of an RTDM driver can run in rt context too. If the
> :> :task which issues the call to "write" is a Xenomai user-space task
> :> :running in primary mode.
> :>  Please note - I do not have any Xenomai user-space tasks running - only 
> :> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
> :> in kernel space - leaving untouchable user space processes. If such new 
> :> paradigm need to write the intermediate user-space RT task proxy - than 
> :> it is wrong. Simply because its adds unneeded complexity to developing RT 
> :> kernel hardware drivers.
> :The pipe support is indeed one of a kind, since it shares semantics
> :between RT and non-RT endpoints, and it should be possible to open the
> :non-RT side from programs which were _not_ linked against any Xenomai
> :library. E.g. cat /dev/rtp22 should get any data sent from a RT endpoint
> :bound to the same pseudo-device.
> 
>  Yes, this is one of the issues - most of non-rt apps need to be relinked 
> with Xenomai and later supported, that can be impossible in the most 
> cases.
> 
> :We will solve this issue by having a RTDM-based driver, implementing the
> :services of the current RT_PIPE support, eventually taping into the
> :nucleus core. A kernel-space RTDM driver will be able to send/recv data
> :via the standard inter-driver RTDM interface - this is what your device
> :driver should do. A user-space RT application will have access to a
> :socket-type service access point for sending/receiving packets;
> :semantics close to the AF_UNIX protocol family should be used there. A
> :non-RT application will still be able to open its endpoint via the usual
> :open(2) interface, i.e. such as cat /dev/rtpX works as before.
> :
> :This work is scheduled for Xenomai v3; v2.5.x still provides the
> :kernel-based APIs available in earlier releases, and as such it is a bit
> :early for changing your code. This is also why there is no migration
> :cookbook from v2 -> v3 yet.
> :The "deprecated" messages are an early warning so that people notice
> :that things will change in the next major release, and that it may be a
> :good idea to reconsider any decision to build _applications_ in
> :kernel-space; you can still disable those messages via the
> :CONFIG_XENO_OPT_NOWARN_DEPRECATED switch if they get on your nerves.
> 
>  I think that marking some feature as deprecated need to be done _after_ 
> the ready up new solution exists, including examples in Xenomai docs. Now 
> Xenomai users are facing with problem that has no solution yet.
> 

Please read on again the last couple of mails, neither you or anything
else has problems with 2.5 compared to 2.4, because the interfaces are
still there. Maybe you should read the help text provided with the
option I mentioned, as well:

===
	Starting with Xenomai 3, the skins will not export their
	interface to kernel modules anymore, at the notable exception
	of the RTDM device driver API, which by essence must be used
	from kernel space for writing real-time device
	drivers.

	Warnings will be emitted at build time when kernel code
	invokes thread/task creation services from Xenomai skins to
	remind you that application code should run in user-space
	context instead.

	The reason for this is fully explained in the project Roadmap
	document (see What Will Change With Xenomai 3):
	http://www.xenomai.org/index.php/Xenomai:Roadmap

	You may switch those warnings off by enabling this option, but
	nevertheless, you have been WARNED.


> 
> 		Rus
-- 
Philippe.

Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm

[Jan Kiszka]

Rus V. Brushkoff wrote:
> On Wed, 2 Sep 2009, Philippe Gerum wrote:
> 
> :> :> :> Can you show this paradigm on pipe.c exmaple from Xenomai docs ?
> :> :> :We are talking about drivers, then just design your driver as you would
> :> :> :design a Linux driver.
> :> :> :For instance, you would implement the "write" method of the driver to
> :> :> :pass data between the user-space task and the driver.
> :> :>  This is RT driver not simply Linux driver. The previous rt_pipe_read() 
> :> :> call was running in RT task context. Now it is not clear how this can be 
> :> :> achieved with new RTDM driver model in kernel space.
> :> :The write method of an RTDM driver can run in rt context too. If the
> :> :task which issues the call to "write" is a Xenomai user-space task
> :> :running in primary mode.
> :>  Please note - I do not have any Xenomai user-space tasks running - only 
> :> normal user space programs. The Xenomai-2.4 allows developing of RT driver 
> :> in kernel space - leaving untouchable user space processes. If such new 
> :> paradigm need to write the intermediate user-space RT task proxy - than 
> :> it is wrong. Simply because its adds unneeded complexity to developing RT 
> :> kernel hardware drivers.
> :The pipe support is indeed one of a kind, since it shares semantics
> :between RT and non-RT endpoints, and it should be possible to open the
> :non-RT side from programs which were _not_ linked against any Xenomai
> :library. E.g. cat /dev/rtp22 should get any data sent from a RT endpoint
> :bound to the same pseudo-device.
> 
>  Yes, this is one of the issues - most of non-rt apps need to be relinked 
> with Xenomai and later supported, that can be impossible in the most 
> cases.
> 
> :We will solve this issue by having a RTDM-based driver, implementing the
> :services of the current RT_PIPE support, eventually taping into the
> :nucleus core. A kernel-space RTDM driver will be able to send/recv data
> :via the standard inter-driver RTDM interface - this is what your device
> :driver should do. A user-space RT application will have access to a
> :socket-type service access point for sending/receiving packets;
> :semantics close to the AF_UNIX protocol family should be used there. A
> :non-RT application will still be able to open its endpoint via the usual
> :open(2) interface, i.e. such as cat /dev/rtpX works as before.
> :
> :This work is scheduled for Xenomai v3; v2.5.x still provides the
> :kernel-based APIs available in earlier releases, and as such it is a bit
> :early for changing your code. This is also why there is no migration
> :cookbook from v2 -> v3 yet.
> :The "deprecated" messages are an early warning so that people notice
> :that things will change in the next major release, and that it may be a
> :good idea to reconsider any decision to build _applications_ in
> :kernel-space; you can still disable those messages via the
> :CONFIG_XENO_OPT_NOWARN_DEPRECATED switch if they get on your nerves.
> 
>  I think that marking some feature as deprecated need to be done _after_ 
> the ready up new solution exists, including examples in Xenomai docs. Now 
> Xenomai users are facing with problem that has no solution yet.

Basically you are right regarding this particular feature (rt-pipe
access from RTDM drivers). It's rarely required, but it is used, I'm
aware of at least one further driver [1]. I think we should simply
enhance RTDM by some equivalent rtdm_pipe service to plug this hole
(BTW, the alternative would be registering a Linux device from the RTDM
driver and implementing your own data forwarding, also using rtdm_nrtsig).

Still, all the other deprecated in-kernel features do have a proper
alternative already.

Jan

[1]http://git.berlios.de/cgi-bin/gitweb.cgi?p=rack;a=tree;f=rack/main/tims/driver;hb=refs/heads/master

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux