All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Ulrich Schwab <schwab@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] pthread_attr_setfp_np needed in user space apps ?
Date: Mon, 31 Oct 2005 18:31:25 +0100	[thread overview]
Message-ID: <436654ED.4010804@domain.hid> (raw)
In-Reply-To: <200510311453.14159.schwab@domain.hid>

Ulrich Schwab wrote:
> Hello,
> 
> I am in the progress of porting an application from RTLinux to Xenomai-2.0
> While compiling for a user space RT program with the posix skin I get
> the following warning:
> 
> warning: implicit declaration of function `pthread_attr_setfp_np'
> 
> is this call NOT needed in an user space app   ?
> 

It's not needed. If you selected FPU support in the "Machine" menu when 
configuring, then Xenomai will handle FPU switches properly.

> It is there in the sources, but does not seem to be exported to a user space 
> RT app.
> 
> Another point unclear to me is, how are printf's handled in RT user space 
> apps ?
> Isn't the RT scheduling affected, when done in a RT critical context ?
> 

Printf ends up calling the write(2) system call, which is indeed the issue.
When issuing a Linux call over a RT context, your thread automatically switches 
from primary execution mode (Xenomai) to secondary (Linux). The priority of this 
thread is kept across such migration (*), so the scheduling per se is not 
impacted. What's impacted is the overall determinism one could expect from 
running Linux code, which cannot be guaranteed with vanilla kernels: IOW, you 
would have unpredictable execution times in such context, since nothing could 
guarantee that the syscall some routine end up calling would not be delayed for 
an unbounded amount of time by lower priority kernel operations.

What Xenomai brings is the ability to keep the priority scheme intact in such 
circumstances, so that a high RT priority thread switching in secondary mode is 
still runnable before a low RT priority one. The day we have a really 
deterministic Linux kernel, this little thing will make a huge difference when 
it comes to provide a seamless RT service integration.

> Thanks, for any comments,
> Ulrich Schwab
> 


-- 

Philippe.


      reply	other threads:[~2005-10-31 17:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-31 13:53 [Xenomai-help] pthread_attr_setfp_np needed in user space apps ? Ulrich Schwab
2005-10-31 17:31 ` Philippe Gerum [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=436654ED.4010804@domain.hid \
    --to=rpm@xenomai.org \
    --cc=schwab@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.