Subject: Re: SEGEV defines

From: [email-masked] (Tor Arntsen)
Date: Fri, 8 Nov 2002 10:14:53 +0100

On Nov 7, 23:11, Daniel Jacobowitz wrote:
>Presumably they match IRIX... like the rest of MIPS's oddball
>definitions.  A little hard to change them now.

FWIW: You are correct, those values come from IRIX.

>On Thu, Nov 07, 2002 at 12:33:55PM -0800, Bradley Bozarth wrote:
>> Can these be changed?
>> 
>> > Now a question, why does mips use these values:
>> >  #define SIGEV_SIGNAL   129     /* notify via signal */
>> >  #define SIGEV_CALLBACK 130     /* ??? */
>> >  #define SIGEV_THREAD   131     /* deliver via thread
>> > creation */
>> >
>> > It is the only platform that adds anything to the simple
>> > 1,2,3 values used on other platforms.  The reason I ask, is
>> > that I would like to change them to conform to all the
>> > others.

---

From: Bradley Bozarth <[email-masked]>
Date: Wed, 13 Nov 2002 18:11:47 -0800 (PST)

This presents a problem that I just ran into.  What should the solution 
be?  Either glibc or the kernel needs to change as far as I can tell, in 
order for programs compiled against glibc and using these SIGEV defines to 
work w/ the mips kernel.  Is this file currently wrong?

glibc-2.3.1/sysdeps/unix/sysv/linux/mips/bits/siginfo.h

Would this patch fix it?

--- siginfo.h.orig	Wed Nov 13 18:04:58 2002
+++ siginfo.h	Wed Nov 13 18:11:15 2002
@@ -295,11 +295,11 @@
 /* `sigev_notify' values.  */
 enum
 {
-  SIGEV_SIGNAL = 0,		/* Notify via signal.  */
+  SIGEV_SIGNAL = 129,		/* Notify via signal.  */
 # define SIGEV_SIGNAL	SIGEV_SIGNAL
-  SIGEV_NONE,			/* Other notification: meaningless.  */
+  SIGEV_NONE = 128,		/* Other notification: meaningless.  */
 # define SIGEV_NONE	SIGEV_NONE
-  SIGEV_THREAD			/* Deliver via thread creation.  */
+  SIGEV_THREAD = 131		/* Deliver via thread creation.  */
 # define SIGEV_THREAD	SIGEV_THREAD
 };

---

From: george anzinger <[email-masked]>
Date: Wed, 13 Nov 2002 20:23:10 -0800

> +++ siginfo.h   Wed Nov 13 18:11:15 2002

I MUCH prefer a change to the kernel if one or the other
needs to change.  The issue is, of course, IRIX
compatability and what that means.  This comes up because I
want to use the definitions in combination and the common
bit makes a mess of things.  Still, it would be NICE if it
matched the rest of the platforms.

-g

-- 
George Anzinger   [email-masked]
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 14 Nov 2002 05:51:56 +0100

> matched the rest of the platforms.

The IRIX compatibility code seems unused and the constants aren't even
part of the ABI at all.  So in this case it indeed seems preferable to
change the kernel side.

Anybody disagrees?

  Ralf

---

From: Bradley Bozarth <[email-masked]>
Date: Thu, 14 Nov 2002 16:43:25 -0800 (PST)

Along the same lines, the struct sigevent in the kernel says that it isn't 
IRIX compatible.. but it isn't glibc compatible either.  What is it 
compatible with?  The new posix timer code copies this struct from the 
user and kaboom, so again either glibc or the kernel needs to sync up.

relevant sections:

========= glibc/sysdeps/unix/sysv/linux/mips/bits:
/* XXX This one might need to change!!!  */
typedef struct sigevent
  {
    sigval_t sigev_value;
    int sigev_signo;
    int sigev_notify;

========= linux/include/asm-mips:
/* XXX This one isn't yet IRIX / ABI compatible.  */
typedef struct sigevent {
	int sigev_notify;
	sigval_t sigev_value;
	int sigev_signo;