All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Andreas Glatz <andreasglatz@domain.hid>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-core] nucleus/pipe.c patch: check for lingering close at xnpipe_connect()
Date: Fri, 11 Sep 2009 09:46:00 +0200	[thread overview]
Message-ID: <1252655160.2820.242.camel@domain.hid> (raw)
In-Reply-To: <1252601385.28464.29.camel@domain.hid>

On Thu, 2009-09-10 at 12:49 -0400, Andreas Glatz wrote:
> Hi,
> 
> 
> > 
> > Whenever possible, please post patches inline (I had to manually copy it
> > to allow commenting).
> 
> Sure, no problem.
> 
> 
> > 
> > You cannot bluntly call release() here. You may not run in Linux context
> > while that handler demands this. 
> 
> It's also called in xnpipe_disconnect() (if I follow 'goto cleanup' and
> the user-space isn't connected). So is there a different policy here?
> I mean should xnpipe_connect() just be called from rt context whereas
> xnpipe_disconnect() has to be called from non-rt context?
> 
> 
> > Moreover, releasing the state is the
> > job of the NRT user that opened it and obviously still has a hand on it.
> 
> Yeah, that's the tricky part. I left that part out yet ...
> 
> > 
> > (And the locking is imbalanced here, but that is shadowed by the other
> > flaws.)
> 
> Agree.
> 
> If we had that new pipe behaviour it could significantly 
> speed-up debugging for us because we wouldn't have to stop (and
> eventually start) all NRT applications before restarting the RT
> application.
> 
> Thanks for commenting on my quick and dirty patch. I think, now
> I know where to continue.
> 

Allowing the RT side to be re-opened multiple times won't fly, I'm
afraid. The reason we have the linger-on-close behavior is to prevent
the NRT side to refer to stale memory whenever the RT side preempts and
disconnects. Excluding RT from preempting the write/read calls could
cause high latencies (NRT may sleep anyway, so locking would not even be
a safe option there).

Maybe you should move the RT_PIPE descriptor in a separate, standalone
module from your driver to keep the connection alive, and ignore the
-EBUSY status upon failed attempt to connect to the same minor from your
driver? That descriptor is shareable in kernel space so there is no
restriction in using it from another module, and this would allow your
driver module to be unloaded without actually tearing down the data
channel with your userland app.

> Andreas
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.




      reply	other threads:[~2009-09-11  7:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-09 21:48 [Xenomai-core] nucleus/pipe.c patch: check for lingering close at xnpipe_connect() Andreas Glatz
2009-09-09 22:34 ` Jan Kiszka
2009-09-10 16:49   ` Andreas Glatz
2009-09-11  7:46     ` 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=1252655160.2820.242.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=andreasglatz@domain.hid \
    --cc=jan.kiszka@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.