All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Brunner <dbrunner@ebus.com>
To: Xenomai <xenomai@xenomai.org>
Subject: [Xenomai] Detecting closure of non-RT end of XDDP from userspace
Date: Thu, 26 Feb 2015 23:27:00 -0800	[thread overview]
Message-ID: <54F01C44.9090000@ebus.com> (raw)

Hi all,

I have a need for an RT task that communicates with Linux tasks through
XDDP to tell when the Linux process has closed /dev/rtpN. In this case the
RT task is acting as a server of sorts from which Linux processes retrieve
data, and if an ill-behaved Linux process dies, the RT task needs to clean
up its connection state in order to not flood the hapless Linux process
that connects next with all the data that built up in the XDDP buffers. I
would rather avoid implementing a heartbeat mechanism (RT task watches for
periodic "I'm alive" signal from Linux process), because of the many
moving parts this would introduce.

It looks like the information is there - xnpipe_state::status (please
forgive my C++ scoping operator :)) has a bit indicating whether the Linux
side is connected, XNPIPE_USER_CONN. I was thinking of adding a function
xnpipe_get_status, which retrieves the status word:

int xnpipe_get_status(int minor, unsigned long *out);

The XDDP getsockopt() can then return this information to userspace,
mirroring how Linux sockets behave (if I understand correctly):

int err;
getsockopt(fd, SOL_SOCKET, SO_ERROR, &err, sizeof(err));
if(err == 0) {
    /* socket is connected on Linux end */
}
else if(err == EPIPE) {
    /* socket is not connected on Linux end*/
}

One other possibility would be to add a socket option that, when set,
causes sendmsg() and recvmsg() to fail with EPIPE if the Linux end of the
pipe is not connected.

Does either/both of these seem like a good idea?

-- 
    Doug Brunner



             reply	other threads:[~2015-02-27  7:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27  7:27 Doug Brunner [this message]
2015-03-02 10:24 ` [Xenomai] Detecting closure of non-RT end of XDDP from userspace Philippe Gerum
2015-04-09  2:21   ` Doug Brunner

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=54F01C44.9090000@ebus.com \
    --to=dbrunner@ebus.com \
    --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.