All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: "s.a." <sancelot@domain.hid>
Cc: Petr Cervenka <grugh@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-help] Xenomai: binding failed: Operation not permitted.
Date: Wed, 07 Jun 2006 11:42:30 +0200	[thread overview]
Message-ID: <44869F86.4090106@domain.hid> (raw)
In-Reply-To: <448696E8.10405@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

s.a. wrote:
> Hi,
> 
> In my mind , one or more rt process manages everything critical, need
> root access for resources reasons , other processes are things like gui
> to interact with realtime world, including  X11 applications (I know , I
> will hurt some people, but this is the truth : X11 !) .....
> 

My point is: what do you gain by separating the RT core from the logging
or gui application? Not much as long as the interface is not robust.
This means that your uncritical part must not be able to interfere with
the critical one, e.g. by acquiring some common lock or messing up a
shared memory which is used blindly by the RT code. If your application
design can guarantee this, ok.

But then note that Xenomai heaps are unsuited for being shared with not
fully trusted parties: management structures reside next to the data,
write permission is always acquired (and is required for
allocation/release operations), access control beyond go/no-go is not
supported. Better use "standard" (Linux) shared memory for this: Invoke
shm_open("myshm", ...), adapt the access rights of the newly created
/dev/shm/myshm, and let the unprivileged process attach to it.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

  reply	other threads:[~2006-06-07  9:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200605181426.8240@domain.hid>
     [not found] ` <446C6C1C.2010902@domain.hid>
2006-05-19  7:43   ` [Xenomai-help] Xenomai: binding failed: Operation not permitted Petr Cervenka
2006-05-19  8:12     ` Jan Kiszka
2006-06-06 15:20       ` s.a.
2006-06-06 13:24         ` Jan Kiszka
2006-06-07  9:05           ` s.a.
2006-06-07  9:42             ` Jan Kiszka [this message]
2006-06-09 13:28               ` Jan Kiszka
2012-04-25 10:28 Frederik Bayart
2012-04-25 10:43 ` Gilles Chanteperdrix
     [not found] ` <4F97E4AA.8090502@domain.hid>
     [not found]   ` <CALH4WdbEZL9f=ikyEezZwUwpgKaFPaf=YqbCXzNe97dt0J643w@domain.hid>
2012-04-29 15:56     ` Gilles Chanteperdrix
2012-04-29 15:56 ` Gilles Chanteperdrix
     [not found]   ` <CALH4WdaTXPmzXnUHiU1jfhKUCiBhyG+X1oA6XSK5fHXds_gLTA@mail.gmail.com>
2012-05-11 15:02     ` Frederik Bayart
2012-05-11 15:21       ` Gilles Chanteperdrix

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=44869F86.4090106@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=grugh@domain.hid \
    --cc=sancelot@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.