* [Xenomai] Hardware I/O from Userspace
@ 2013-10-16 16:06 Drasko DRASKOVIC
2013-10-16 17:14 ` Gilles Chanteperdrix
0 siblings, 1 reply; 8+ messages in thread
From: Drasko DRASKOVIC @ 2013-10-16 16:06 UTC (permalink / raw)
To: xenomai@xenomai.org
Hi all,
I would like to access to various peripheral and CPU regs of my FPGA
from userspace.
Is mmap of /dev/mem best way to it, or I should do it from kernelspace
via kernel module?
I am looking at examples/common/hw_direct_io.c of Xenomai examples.
Can somebody explain me how Xenomai is used in this case, as I see
only standard pthread interface. Was this patched by Xenomai patches?
I do not see calls to RT tasks or some other Xenomai-related API.
I can see:
struct sched_param param;
printf("%s: %s %s\n", __FUNCTION__, __DATE__, __TIME__ );
param.__sched_priority = 99;
res = pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m);
How these lines affect Xenomai?
Thanks and best regards,
Drasko
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Xenomai] Hardware I/O from Userspace 2013-10-16 16:06 [Xenomai] Hardware I/O from Userspace Drasko DRASKOVIC @ 2013-10-16 17:14 ` Gilles Chanteperdrix 2013-10-17 14:57 ` Drasko DRASKOVIC 0 siblings, 1 reply; 8+ messages in thread From: Gilles Chanteperdrix @ 2013-10-16 17:14 UTC (permalink / raw) To: Drasko DRASKOVIC; +Cc: xenomai@xenomai.org On 10/16/2013 06:06 PM, Drasko DRASKOVIC wrote: > Hi all, > I would like to access to various peripheral and CPU regs of my FPGA > from userspace. > > Is mmap of /dev/mem best way to it, or I should do it from kernelspace > via kernel module? Hi, The RTDM kernel module is the recommended way, among other things, it may be used to prevent several applications to access the registers at the same time. > > I am looking at examples/common/hw_direct_io.c of Xenomai examples. > Can somebody explain me how Xenomai is used in this case, as I see > only standard pthread interface. Was this patched by Xenomai patches? > I do not see calls to RT tasks or some other Xenomai-related API. > > I can see: > struct sched_param param; > > printf("%s: %s %s\n", __FUNCTION__, __DATE__, __TIME__ ); > param.__sched_priority = 99; > res = pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m); > > How these lines affect Xenomai? Xenomai has more skins than just the native skin, it has notably a POSIX skin which attempts to implement the POSIX API. How pthread_setschedparam is hijacked by Xenomai is explained here: https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags Regards. -- Gilles. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-16 17:14 ` Gilles Chanteperdrix @ 2013-10-17 14:57 ` Drasko DRASKOVIC 2013-10-17 15:00 ` Lennart Sorensen ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Drasko DRASKOVIC @ 2013-10-17 14:57 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org Hi Gilles, On Wed, Oct 16, 2013 at 7:14 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > On 10/16/2013 06:06 PM, Drasko DRASKOVIC wrote: >> Hi all, >> I would like to access to various peripheral and CPU regs of my FPGA >> from userspace. >> >> Is mmap of /dev/mem best way to it, or I should do it from kernelspace >> via kernel module? > > Hi, > > The RTDM kernel module is the recommended way, among other things, it may > be used to prevent several applications to access the registers at the > same time. I will most probably have only one application who access these regs. Is not putting this application into the user-space safer - if it breaks it will not block system? Did i misunderstand something, or RTDM kernel module is like standard kernel module - if it has a bug it can break the whole kernel. > >> >> I am looking at examples/common/hw_direct_io.c of Xenomai examples. >> Can somebody explain me how Xenomai is used in this case, as I see >> only standard pthread interface. Was this patched by Xenomai patches? >> I do not see calls to RT tasks or some other Xenomai-related API. >> >> I can see: >> struct sched_param param; >> >> printf("%s: %s %s\n", __FUNCTION__, __DATE__, __TIME__ ); >> param.__sched_priority = 99; >> res = pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m); >> >> How these lines affect Xenomai? > > Xenomai has more skins than just the native skin, it has notably a > POSIX skin which attempts to implement the POSIX API. How > pthread_setschedparam is hijacked by Xenomai is explained here: > > https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags Usage of the compilation flags is pretty-much clear. What I was asing is can anybody elaborate of how Posix calls became Xenomai ones in this example (if they did). BR, Drasko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-17 14:57 ` Drasko DRASKOVIC @ 2013-10-17 15:00 ` Lennart Sorensen 2013-10-17 15:08 ` Drasko DRASKOVIC 2013-10-17 15:05 ` Drasko DRASKOVIC 2013-10-17 18:39 ` Gilles Chanteperdrix 2 siblings, 1 reply; 8+ messages in thread From: Lennart Sorensen @ 2013-10-17 15:00 UTC (permalink / raw) To: Drasko DRASKOVIC; +Cc: xenomai@xenomai.org On Thu, Oct 17, 2013 at 04:57:43PM +0200, Drasko DRASKOVIC wrote: > I will most probably have only one application who access these regs. > > Is not putting this application into the user-space safer - if it > breaks it will not block system? > Did i misunderstand something, or RTDM kernel module is like standard > kernel module - if it has a bug it can break the whole kernel. What do you think using /dev/mem can do? -- Len Sorensen ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-17 15:00 ` Lennart Sorensen @ 2013-10-17 15:08 ` Drasko DRASKOVIC 0 siblings, 0 replies; 8+ messages in thread From: Drasko DRASKOVIC @ 2013-10-17 15:08 UTC (permalink / raw) To: Lennart Sorensen; +Cc: xenomai@xenomai.org On Thu, Oct 17, 2013 at 5:00 PM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote: > On Thu, Oct 17, 2013 at 04:57:43PM +0200, Drasko DRASKOVIC wrote: >> I will most probably have only one application who access these regs. >> >> Is not putting this application into the user-space safer - if it >> breaks it will not block system? >> Did i misunderstand something, or RTDM kernel module is like standard >> kernel module - if it has a bug it can break the whole kernel. > > What do you think using /dev/mem can do? I guess it opens the file for reading... right? Is there more than meets the eye? Can it do much harm when file is opened from userspace and how? BR, Drasko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-17 14:57 ` Drasko DRASKOVIC 2013-10-17 15:00 ` Lennart Sorensen @ 2013-10-17 15:05 ` Drasko DRASKOVIC 2013-10-17 18:39 ` Gilles Chanteperdrix 2 siblings, 0 replies; 8+ messages in thread From: Drasko DRASKOVIC @ 2013-10-17 15:05 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On Thu, Oct 17, 2013 at 4:57 PM, Drasko DRASKOVIC <drasko.draskovic@gmail.com> wrote: https://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Compilation_flags > > Usage of the compilation flags is pretty-much clear. What I was asing > is can anybody elaborate of how Posix calls became Xenomai ones in > this example (if they did). Whoops, just saw that "Under the hood: the --wrap flag" section actually explains this quite well. Thanks. BR, Drasko ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-17 14:57 ` Drasko DRASKOVIC 2013-10-17 15:00 ` Lennart Sorensen 2013-10-17 15:05 ` Drasko DRASKOVIC @ 2013-10-17 18:39 ` Gilles Chanteperdrix 2013-10-18 16:30 ` Drasko DRASKOVIC 2 siblings, 1 reply; 8+ messages in thread From: Gilles Chanteperdrix @ 2013-10-17 18:39 UTC (permalink / raw) To: Drasko DRASKOVIC; +Cc: xenomai@xenomai.org On 10/17/2013 04:57 PM, Drasko DRASKOVIC wrote: > Hi Gilles, > > On Wed, Oct 16, 2013 at 7:14 PM, Gilles Chanteperdrix > <gilles.chanteperdrix@xenomai.org> wrote: >> On 10/16/2013 06:06 PM, Drasko DRASKOVIC wrote: >>> Hi all, >>> I would like to access to various peripheral and CPU regs of my FPGA >>> from userspace. >>> >>> Is mmap of /dev/mem best way to it, or I should do it from kernelspace >>> via kernel module? >> >> Hi, >> >> The RTDM kernel module is the recommended way, among other things, it may >> be used to prevent several applications to access the registers at the >> same time. > > I will most probably have only one application who access these regs. > > Is not putting this application into the user-space safer - if it > breaks it will not block system? > Did i misunderstand something, or RTDM kernel module is like standard > kernel module - if it has a bug it can break the whole kernel. Yes, but having to separate application from driver is a future proof pattern: the same driver can be used with different applications, and changing hardware does not break the application, you only have to write a driver for the new hardware. -- Gilles. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Xenomai] Hardware I/O from Userspace 2013-10-17 18:39 ` Gilles Chanteperdrix @ 2013-10-18 16:30 ` Drasko DRASKOVIC 0 siblings, 0 replies; 8+ messages in thread From: Drasko DRASKOVIC @ 2013-10-18 16:30 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org On Thu, Oct 17, 2013 at 8:39 PM, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote: > On 10/17/2013 04:57 PM, Drasko DRASKOVIC wrote: >> Hi Gilles, >> >> On Wed, Oct 16, 2013 at 7:14 PM, Gilles Chanteperdrix >> <gilles.chanteperdrix@xenomai.org> wrote: >>> On 10/16/2013 06:06 PM, Drasko DRASKOVIC wrote: >>>> Hi all, >>>> I would like to access to various peripheral and CPU regs of my FPGA >>>> from userspace. >>>> >>>> Is mmap of /dev/mem best way to it, or I should do it from kernelspace >>>> via kernel module? >>> >>> Hi, >>> >>> The RTDM kernel module is the recommended way, among other things, it may >>> be used to prevent several applications to access the registers at the >>> same time. >> >> I will most probably have only one application who access these regs. >> >> Is not putting this application into the user-space safer - if it >> breaks it will not block system? >> Did i misunderstand something, or RTDM kernel module is like standard >> kernel module - if it has a bug it can break the whole kernel. > > Yes, but having to separate application from driver is a future proof > pattern: the same driver can be used with different applications, and > changing hardware does not break the application, you only have to write > a driver for the new hardware. > Here is my scenario: I have to access HW regs to set up and initialize peripherals and FPGA. There is a lot of initialization, and currently I am doing this from userspace via /dev/mem. You are suggesting to move this as RTDM into the kernel space. But I also have some code that is executed in this application that might use floating point calculation, etc, i.e. pure data processing, no HW access - but it has to be executed with high priority and in RT. What would be the best scenario in that case: a) keep all as userspace b) move all to kernelspace c) divide this somehow into kernel-spce part of HW access and small userspace app (of data processing) and make them communicate somehow (how?). Would this affect responsiveness? Best regards, Drasko ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-10-18 16:30 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-10-16 16:06 [Xenomai] Hardware I/O from Userspace Drasko DRASKOVIC 2013-10-16 17:14 ` Gilles Chanteperdrix 2013-10-17 14:57 ` Drasko DRASKOVIC 2013-10-17 15:00 ` Lennart Sorensen 2013-10-17 15:08 ` Drasko DRASKOVIC 2013-10-17 15:05 ` Drasko DRASKOVIC 2013-10-17 18:39 ` Gilles Chanteperdrix 2013-10-18 16:30 ` Drasko DRASKOVIC
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.