SEGEV defines

SEGEV defines

[Bradley Bozarth]

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.

Re: SEGEV defines

[Daniel Jacobowitz]

Presumably they match IRIX... like the rest of MIPS's oddball
definitions.  A little hard to change them now.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: SEGEV defines

[Tor Arntsen]

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.

Re: SEGEV defines

[Bradley Bozarth]

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
 };


On Fri, 8 Nov 2002, Tor Arntsen wrote:

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

Re: SEGEV defines

[george anzinger]

Bradley Bozarth wrote:
> 
> 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
>  };

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

> 
> On Fri, 8 Nov 2002, Tor Arntsen wrote:
> 
> > 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.
> >

-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: SEGEV defines

[Ralf Baechle]

On Wed, Nov 13, 2002 at 08:23:10PM -0800, george anzinger wrote:

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

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

Re: SEGEV defines

[Bradley Bozarth]

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;







On Thu, 14 Nov 2002, Ralf Baechle wrote:

> On Wed, Nov 13, 2002 at 08:23:10PM -0800, george anzinger wrote:
> 
> > 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.
> 
> 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
> 

Re: SEGEV defines

[Bradley Bozarth]

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;







On Thu, 14 Nov 2002, Ralf Baechle wrote:

> On Wed, Nov 13, 2002 at 08:23:10PM -0800, george anzinger wrote:
> 
> > 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.
> 
> 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
>