From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4A9E5917.8060200@domain.hid> Date: Wed, 02 Sep 2009 13:37:59 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4A9E3AAB.2070404@domain.hid> <4A9E4D84.20602@domain.hid> <4A9E5424.9070500@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Deprecated kernel system calls in xenomai-head and new application development paradigm List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Rus V. Brushkoff" Cc: Xenomai help 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