From: Jan Kiszka <jan.kiszka@domain.hid>
To: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] xnpipe: what's up with xnpipe_setup?
Date: Mon, 13 Oct 2008 23:16:18 +0200 [thread overview]
Message-ID: <48F3BAA2.8010500@domain.hid> (raw)
In-Reply-To: <48F3B967.5040807@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 4291 bytes --]
Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> xnpipe_setup and the callbacks it sets is dead code for in-tree Xenomai
>> users. Going back to, well, fusion-0.6.9 (the oldest version we have in
>> LXR), it used to be dead meat already at that time. Can we remove it?
>
> In case we can:
Sorry, a better one:
---
include/nucleus/pipe.h | 5 -----
ksrc/nucleus/pipe.c | 47 ++++-------------------------------------------
2 files changed, 4 insertions(+), 48 deletions(-)
Index: b/include/nucleus/pipe.h
===================================================================
--- a/include/nucleus/pipe.h
+++ b/include/nucleus/pipe.h
@@ -76,8 +76,6 @@ static inline xnpipe_mh_t *link2mh(xnhol
typedef int xnpipe_io_handler (int minor,
struct xnpipe_mh *mh, int retval, void *cookie);
-typedef int xnpipe_session_handler (int minor, void *cookie);
-
typedef void *xnpipe_alloc_handler (int minor, size_t size, void *cookie);
typedef struct xnpipe_state {
@@ -118,9 +116,6 @@ void xnpipe_umount(void);
/* Entry points of the kernel interface. */
-void xnpipe_setup(xnpipe_session_handler *open_handler,
- xnpipe_session_handler *close_handler);
-
int xnpipe_connect(int minor,
xnpipe_io_handler *output_handler,
xnpipe_io_handler *input_handler,
Index: b/ksrc/nucleus/pipe.c
===================================================================
--- a/ksrc/nucleus/pipe.c
+++ b/ksrc/nucleus/pipe.c
@@ -37,8 +37,6 @@
static int xnpipe_asyncsig = SIGIO;
-static xnpipe_session_handler *xnpipe_open_handler, *xnpipe_close_handler;
-
xnpipe_state_t xnpipe_states[XNPIPE_NDEVS];
#define XNPIPE_BITMAP_SIZE ((XNPIPE_NDEVS + BITS_PER_LONG - 1) / BITS_PER_LONG)
@@ -216,13 +214,6 @@ static inline void xnpipe_schedule_reque
sections since we might be competing with the real-time threads for
data access. */
-void xnpipe_setup(xnpipe_session_handler *open_handler,
- xnpipe_session_handler *close_handler)
-{
- xnpipe_open_handler = open_handler;
- xnpipe_close_handler = close_handler;
-}
-
int xnpipe_connect(int minor,
xnpipe_io_handler *output_handler,
xnpipe_io_handler *input_handler,
@@ -626,22 +617,6 @@ static int xnpipe_open(struct inode *ino
XNPIPE_USER_ALL_WAIT | XNPIPE_USER_ALL_READY | XNPIPE_USER_SIGIO);
if (!testbits(state->status, XNPIPE_KERN_CONN)) {
- if (xnpipe_open_handler) {
- xnlock_put_irqrestore(&nklock, s);
-
- err = xnpipe_open_handler(xnminor_from_state(state),
- NULL);
- if (err) {
- xnpipe_cleanup_user_conn(state);
- return err;
- }
-
- if (testbits(state->status, XNPIPE_KERN_CONN))
- return 0;
-
- xnlock_get_irqsave(&nklock, s);
- }
-
if (testbits(file->f_flags, O_NONBLOCK)) {
xnpipe_cleanup_user_conn(state);
xnlock_put_irqrestore(&nklock, s);
@@ -655,16 +630,10 @@ static int xnpipe_open(struct inode *ino
xnlock_put_irqrestore(&nklock, s);
return -ERESTARTSYS;
}
-
- xnlock_put_irqrestore(&nklock, s);
- } else {
- xnlock_put_irqrestore(&nklock, s);
-
- if (xnpipe_open_handler)
- err = xnpipe_open_handler(xnminor_from_state(state),
- state->cookie);
}
+ xnlock_put_irqrestore(&nklock, s);
+
if (err)
xnpipe_cleanup_user_conn(state);
@@ -685,22 +654,15 @@ static int xnpipe_release(struct inode *
xnpipe_dequeue_wait(state, XNPIPE_USER_WSYNC);
if (testbits(state->status, XNPIPE_KERN_CONN)) {
- int minor = xnminor_from_state(state);
-
/* If a Xenomai thread is waiting on this object, wake
it up now. */
-
if (xnsynch_nsleepers(&state->synchbase) > 0) {
xnsynch_flush(&state->synchbase, XNRMID);
xnpod_schedule();
}
+ }
- xnlock_put_irqrestore(&nklock, s);
-
- if (xnpipe_close_handler)
- err = xnpipe_close_handler(minor, state->cookie);
- } else
- xnlock_put_irqrestore(&nklock, s);
+ xnlock_put_irqrestore(&nklock, s);
if (state->asyncq) { /* Clear the async queue */
xnlock_get_irqsave(&nklock, s);
@@ -1188,5 +1150,4 @@ EXPORT_SYMBOL(xnpipe_send);
EXPORT_SYMBOL(xnpipe_mfixup);
EXPORT_SYMBOL(xnpipe_recv);
EXPORT_SYMBOL(xnpipe_inquire);
-EXPORT_SYMBOL(xnpipe_setup);
EXPORT_SYMBOL(xnpipe_flush);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-10-13 21:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-13 20:51 [Xenomai-core] xnpipe: what's up with xnpipe_setup? Jan Kiszka
2008-10-13 21:11 ` Jan Kiszka
2008-10-13 21:16 ` Jan Kiszka [this message]
2008-10-14 15:01 ` Philippe Gerum
2008-10-14 19:23 ` Jan Kiszka
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=48F3BAA2.8010500@domain.hid \
--to=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.