[Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Jan Kiszka]

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

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?

Jan


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

Re: [Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Jan Kiszka]

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

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:

---
 include/nucleus/pipe.h |    5 -----
 ksrc/nucleus/pipe.c    |   43 ++++---------------------------------------
 2 files changed, 4 insertions(+), 44 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);
 
@@ -694,13 +663,9 @@ static int xnpipe_release(struct inode *
 			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);


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

Re: [Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Jan Kiszka]

[-- 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 --]

Re: [Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Philippe Gerum]

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?
> 

We can and should emulate the close handler using the input one, so we may get
rid of the former.

We need some way to fire a callback in a skin implementation when userland
connects, this is what the open handler was for; this may be required for
implementing more complex data channels over the generic message pipe code. Ok,
we could also divert the input handler for that purpose as well, and it makes
little sense to keep a full interface just for that case.

Go ahead, remove that code, but if a skin developer ever comes and complains
about the terminal ugliness of our input handler looking like a kitchen sink in
a near future, I will ruthlessly direct him to YOU. Ah! Fair enough?

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


-- 
Philippe.

Re: [Xenomai-core] xnpipe: what's up with xnpipe_setup?

[Jan Kiszka]

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

Philippe Gerum 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?
>>
> 
> We can and should emulate the close handler using the input one, so we may get
> rid of the former.
> 
> We need some way to fire a callback in a skin implementation when userland
> connects, this is what the open handler was for; this may be required for
> implementing more complex data channels over the generic message pipe code. Ok,
> we could also divert the input handler for that purpose as well, and it makes
> little sense to keep a full interface just for that case.
> 
> Go ahead, remove that code, but if a skin developer ever comes and complains
> about the terminal ugliness of our input handler looking like a kitchen sink in
> a near future, I will ruthlessly direct him to YOU. Ah! Fair enough?

Yeah, just blame the street cleaner...

Jan


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