[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[carlos at systemhalted dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=2383

Carlos O'Donell <carlos at systemhalted dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at systemhalted dot
                   |                            |org
              Flags|examined+                   |

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at sources dot redhat dot com]

------- Additional Comments From drow at sources dot redhat dot com  2006-07-24 20:09 -------
Checked in.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2006-07-24 19:11 -------
(In reply to comment #9)

> So.  You want to set these to 32-34, but don't want those to be marked by
> __SIGRTMIN.  How about setting something like the attached?

It will work for us (together with "#define PTHREAD_SIGBASE 32" in GNU/kFreeBSD 
kernel-features.h).

So, yes, please commit this. It will fully satisfy our needs.
Thanks for your patch.

Petr








-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at false dot org]

------- Additional Comments From drow at false dot org  2006-07-24 15:03 -------
Subject: Re:  [PATCH] Please use sysdeps for selecting linuxthreads internal signals

On Mon, Jul 24, 2006 at 03:02:37PM -0000, ams at gnu dot org wrote:
> The Hurd doesn't use LinuxThreads.

Oops, thanks.  Anyway, point stands.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Re: [Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Alfred M. Szmidt]

   I really don't like putting this initialization into sysdeps.  For
   one thing, Linux is not the only supported port.  I think this
   would break LinuxThreads for the Hurd, for instance.

The Hurd doesn't use LinuxThreads.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[ams at gnu dot org]

------- Additional Comments From ams at gnu dot org  2006-07-24 15:02 -------
Subject: Re:  [PATCH] Please use sysdeps for selecting linuxthreads internal signals

   I really don't like putting this initialization into sysdeps.  For
   one thing, Linux is not the only supported port.  I think this
   would break LinuxThreads for the Hurd, for instance.

The Hurd doesn't use LinuxThreads.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at sources dot redhat dot com]

------- Additional Comments From drow at sources dot redhat dot com  2006-07-24 14:35 -------
Created an attachment (id=1178)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=1178&action=view)
PTHREAD_SIGBASE patch


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at sources dot redhat dot com]

------- Additional Comments From drow at sources dot redhat dot com  2006-07-24 14:35 -------
I really don't like putting this initialization into sysdeps.  For one thing,
Linux is not the only supported port.  I think this would break LinuxThreads for
the Hurd, for instance.

So.  You want to set these to 32-34, but don't want those to be marked by
__SIGRTMIN.  How about setting something like the attached?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2006-04-26 17:26 -------
> So... why not define __SIGRTMIN to 32 while building glibc?  Seems like
> everything would just work, modulo maybe changes to your allocrtsig.c.

We can't. :-( 

On FreeBSD 5.x and 6.x there are no rt-signals.
So we must not advertise them via __ASSUME_REALTIME_SIGNALS,
otherwise rt variants of pthread_restart(), pthread_suspend(),
pthread_timedsuspend()
will be used (see restart.h) => BAD.

Iff we don't advertise them, init_rtsigs () calls _libc_current_sigrtmin_private ().

Based on result, it will either
 -  use SIGRTMIN & rt-variants   => again BAD
 -  use USR1 & USR2 & non-rt variants => BAD (same collision as with linux 2.0)

Moreover

- it looks like  __SIGRTMIN is also used for advertising whether real-time
signals are available 
- there will be rt-signals in FreeBSD 7.x, but with numbers #65-#126 
 - we must use #32-#34 for __pthread_sig_*, they have special security handling
in kernel, otherwise setuid threaded application breaks.

Proposed patch only moves a few bits into sysdeps to allow us to override it as
needed.
It  does not change behaviour on Linux.

Thanks for  your time.

Petr

>From http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/signal.h

****************************
#if __BSD_VISIBLE
#define SIGTHR          32      /* reserved by thread library. */
#define SIGLWP          SIGTHR
#endif

#define SIGRTMIN        65
#define SIGRTMAX        126
*****************************

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at false dot org]

------- Additional Comments From drow at false dot org  2006-04-26 16:46 -------
Subject: Re:  [PATCH] Please use sysdeps for selecting linuxthreads internal signals

On Wed, Apr 26, 2006 at 04:03:15PM -0000, Petr dot Salinger at seznam dot cz wrote:
> **********************************************
> /* Signal numbers used for the communication. */
>                                           
> int __pthread_sig_restart = 32;
> int __pthread_sig_cancel  = 33;
> int __pthread_sig_debug   = 34;
> **********************************************

So... why not define __SIGRTMIN to 32 while building glibc?  Seems like
everything would just work, modulo maybe changes to your allocrtsig.c.



-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2006-04-26 16:03 -------
> I think I'd want to see how you were replacing the new header on kfreebsd.

Our pthread_sig.h is rather simple:

**********************************************
/* Signal numbers used for the communication. */
                                          
int __pthread_sig_restart = 32;
int __pthread_sig_cancel  = 33;
int __pthread_sig_debug   = 34;
**********************************************

Our whole linuxthreads kfreebsd sysdeps are browseable at:
http://svn.debian.org/wsvn/glibc-bsd/trunk/glibc-2.3-head/linuxthreads/kfreebsd/?rev=0&sc=0
They go into  $SRC/linuxthreads/sysdeps/unix/bsd/bsd4.4/kfreebsd

And also our main kfreebsd sysdeps:
http://svn.debian.org/wsvn/glibc-bsd/trunk/glibc-2.3-head/sysdeps/kfreebsd/?rev=0&sc=0
They go into  $SRC/sysdeps/unix/bsd/bsd4.4/kfreebsd

Petr

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at sources dot redhat dot com]

------- Additional Comments From drow at sources dot redhat dot com  2006-04-26 15:41 -------
I think I'd want to see how you were replacing the new header on kfreebsd.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Last reconfirmed|0000-00-00 00:00:00         |2006-04-26 15:41:59
               date|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2006-03-01 06:41 -------
(In reply to comment #3)
> Petr, are there any RT signals?  Is __SIGRTMIN defined?

No, kfreebsd does not define __SIGRTMIN , non-rt variants of pthread_restart(),
pthread_suspend(),  pthread_timedsuspend() are used on kfreebsd. 

All others Linux specifics (like syscalls in linuxthreads/sysdeps/i386/tls.h)
are overrided by kfreebsd specifics sysdeps. 

Petr
 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[drow at sources dot redhat dot com]

------- Additional Comments From drow at sources dot redhat dot com  2006-02-28 22:07 -------
Petr, are there any RT signals?  Is __SIGRTMIN defined?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[decimal at us dot ibm dot com]

------- Additional Comments From decimal at us dot ibm dot com  2006-02-28 21:59 -------
I'm not sure moving declarations from a .c to a .h is good. I would think you
could do this by providing an alternate .c or by using #ifdef in the existing .c.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|                            |examined+


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug linuxthreads/2383] [PATCH] Please use sysdeps for selecting linuxthreads internal signals

[Petr dot Salinger at seznam dot cz]

------- Additional Comments From Petr dot Salinger at seznam dot cz  2006-02-22 09:39 -------
Created an attachment (id=887)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=887&action=view)
proposed patch


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2383

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.