systemd on hppa and number of free RT signals
diff mbox

Message ID 5434418F.1020407@gmx.de
State Accepted, archived
Headers show

Commit Message

Helge Deller Oct. 7, 2014, 7:39 p.m. UTC
Hello everyone,

I've just had a successful boot on hppa with systemd :-)
The bootlog is attached.

As already discussed here:
http://article.gmane.org/gmane.linux.ports.parisc/5278
we don't have enough RT signals for systemd, which requests "SIGRTMIN+29" which is > 64 (SIGRTMAX).
Since systemd gets more and more important (e.g. KDE now seems to require systemd) we should try to find a solution.

The attached patches to Linux kernel and glibc shuffles around some signals, so that we end up with
#define __SIGRTMIN	32
instead of
#define __SIGRTMIN	37

I do know that this changes the ABI and introduces a binary incompatibly.
Nevertheless, my testing with the new kernel and glibc didn't showed any obvious problems, which means that I could install either of those and the system didn't showed problems even after reboots.
Additionally, given the fact that we have very little users and live in debian/gentoo unstable would IMHO justify such an incompatible change. Even HP-UX support was dropped a few months back...
And we could easily rebuild packages like strace, gdb and such...

The other option would be to increase NSIG in kernel from 64 to 128 or higher.
I did tried to come up with kernel patches for this now for a few weeks, but ended up with the recognition, that this would require to duplicate nearly all of Linux kernel signal handling and which would most likely introduce new bugs.

What's your opinion on this?
I will provide prebuilt debian packages with those patches for kernel and glibc tomorrow for download, so that people may test themselves...

Helge

Comments

Jeroen Roovers Oct. 7, 2014, 8:50 p.m. UTC | #1
On Tue, 07 Oct 2014 21:39:59 +0200
Helge Deller <deller@gmx.de> wrote:

> As already discussed here:
> http://article.gmane.org/gmane.linux.ports.parisc/5278
> we don't have enough RT signals for systemd, which requests
> "SIGRTMIN+29" which is > 64 (SIGRTMAX). Since systemd gets more and
> more important (e.g. KDE now seems to require systemd) we should try
> to find a solution.

We do have enough RT signals, as the patch attached to [1] demonstrates.
I haven't tried that patch with recent versions of systemd, though.
Unless systemd has started using even more signals or introduced even
more gaps for no reason at all.

> Additionally, given the fact that we have very little users and live
> in debian/gentoo unstable

That's Debian unstable and Gentoo /stable/ thank you very much. :)

> would IMHO justify such an incompatible change.

Gentoo dropped support for GNOME and KDE years ago (except for some of
the base libraries such as glib and gtk+ of course). The point being
that these fat window managers run utterly slow (exactly as they do on
much more recent x86 hardware).

Interest in supporting systemd therefore never went beyond the
purely academic interest displayed in [1]. Luckily, Gentoo already uses
an alternative, modern init system. Gentoo/HPPA has little need for
systemd, I would guess.

> The other option would be to increase NSIG in kernel from 64 to 128
> or higher.

Sounds like a lot of work.

> What's your opinion on this?

From my perspective it looks like a lot of work for very little gain.
Gentoo has no need for systemd so all these changes would mean
upgrading kernel and libc requires a lot more attention, and systemd
could equally well compact the ill-chosen RT signal range.


Regards,
     jer



[1] https://bugs.gentoo.org/show_bug.cgi?id=482214
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Carlos O'Donell Oct. 7, 2014, 9:03 p.m. UTC | #2
On Tue, Oct 7, 2014 at 3:39 PM, Helge Deller <deller@gmx.de> wrote:
> I've just had a successful boot on hppa with systemd :-)
> The bootlog is attached.

Awesome.

> The attached patches to Linux kernel and glibc shuffles around some signals,
> so that we end up with
> #define __SIGRTMIN      32
> instead of
> #define __SIGRTMIN      37

This is the right way to go.

Yes it's an ABI event, but these are fundamentally niche architectures
for which we can't ask everyone else to adjust.

> I do know that this changes the ABI and introduces a binary incompatibly.
> Nevertheless, my testing with the new kernel and glibc didn't showed any
> obvious problems, which means that I could install either of those and the
> system didn't showed problems even after reboots.

That's because the signals you moved/removed aren't used by anything :-)

> Additionally, given the fact that we have very little users and live in
> debian/gentoo unstable would IMHO justify such an incompatible change. Even
> HP-UX support was dropped a few months back...
> And we could easily rebuild packages like strace, gdb and such...

That's right.

> The other option would be to increase NSIG in kernel from 64 to 128 or
> higher.

No, that's a very very bad idea because it has consequences on
sigset_t and that would really really immediately break userspace.

> I did tried to come up with kernel patches for this now for a few weeks, but
> ended up with the recognition, that this would require to duplicate nearly
> all of Linux kernel signal handling and which would most likely introduce
> new bugs.

Agreed.

> What's your opinion on this?

Flawless hack. Very well reorganized. Your removal of SIGLOST, and
reorganizing is the best I could come up with also.

The only thing I will do different is make SIGEMT equal to SIGABRT,
that way we preserve the semantics of what this operation means. Linux
doesn't use SIGEMT, but it keeps hppa defining this for use by other
software that might want similar semantics. You can catch SIGABRT and
operate on it, so it's one way forward.

If you agree I'll checkin to glibc master.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Carlos O'Donell Oct. 7, 2014, 9:07 p.m. UTC | #3
On Tue, Oct 7, 2014 at 4:50 PM, Jeroen Roovers <jer@gentoo.org> wrote:
>> What's your opinion on this?
>
> From my perspective it looks like a lot of work for very little gain.
> Gentoo has no need for systemd so all these changes would mean
> upgrading kernel and libc requires a lot more attention, and systemd
> could equally well compact the ill-chosen RT signal range.

Helge's changes bring hppa inline with other machines with little to
no impact to userspace.

That is a win from a maintenance perspective IMO.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Oct. 7, 2014, 9:21 p.m. UTC | #4
Hi Carlos,

On 10/07/2014 11:03 PM, Carlos O'Donell wrote:
> On Tue, Oct 7, 2014 at 3:39 PM, Helge Deller <deller@gmx.de> wrote:
>> I've just had a successful boot on hppa with systemd :-)
>> The bootlog is attached.
>
> Awesome.

Thanks!
  
>> The attached patches to Linux kernel and glibc shuffles around some signals,
>> so that we end up with
>> #define __SIGRTMIN      32
>> instead of
>> #define __SIGRTMIN      37
>
> This is the right way to go.
>
> Yes it's an ABI event, but these are fundamentally niche architectures
> for which we can't ask everyone else to adjust.

Yes, that was my opinion too.
  
>> I do know that this changes the ABI and introduces a binary incompatibly.
>> Nevertheless, my testing with the new kernel and glibc didn't showed any
>> obvious problems, which means that I could install either of those and the
>> system didn't showed problems even after reboots.
>
> That's because the signals you moved/removed aren't used by anything :-)
>
>> Additionally, given the fact that we have very little users and live in
>> debian/gentoo unstable would IMHO justify such an incompatible change. Even
>> HP-UX support was dropped a few months back...
>> And we could easily rebuild packages like strace, gdb and such...
>
> That's right.
>
>> The other option would be to increase NSIG in kernel from 64 to 128 or
>> higher.
>
> No, that's a very very bad idea because it has consequences on
> sigset_t and that would really really immediately break userspace.
>
>> I did tried to come up with kernel patches for this now for a few weeks, but
>> ended up with the recognition, that this would require to duplicate nearly
>> all of Linux kernel signal handling and which would most likely introduce
>> new bugs.
>
> Agreed.
>
>> What's your opinion on this?
>
> Flawless hack. Very well reorganized. Your removal of SIGLOST, and
> reorganizing is the best I could come up with also.
>
> The only thing I will do different is make SIGEMT equal to SIGABRT,
> that way we preserve the semantics of what this operation means. Linux
> doesn't use SIGEMT, but it keeps hppa defining this for use by other
> software that might want similar semantics. You can catch SIGABRT and
> operate on it, so it's one way forward.

Good idea!
  
> If you agree I'll checkin to glibc master.

I think we should check in the kernel changes first, which I can cover.
That shouldn't be a problem, but I assume people (Linus?) may ask why we do this.
Does it makes sense to set up a Wiki page with some more info about it?
If yes, I think I might need some help there...

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Oct. 7, 2014, 9:25 p.m. UTC | #5
Hi Jeroen,

On 10/07/2014 10:50 PM, Jeroen Roovers wrote:
> On Tue, 07 Oct 2014 21:39:59 +0200
> Helge Deller <deller@gmx.de> wrote:
>
>> As already discussed here:
>> http://article.gmane.org/gmane.linux.ports.parisc/5278
>> we don't have enough RT signals for systemd, which requests
>> "SIGRTMIN+29" which is > 64 (SIGRTMAX). Since systemd gets more and
>> more important (e.g. KDE now seems to require systemd) we should try
>> to find a solution.
>
> We do have enough RT signals, as the patch attached to [1] demonstrates.

Agreed, my wording was maybe not perfect. We do have enough signals, but systemd
does has some strange expectations which you perfectly described in your bug report.

> I haven't tried that patch with recent versions of systemd, though.
> Unless systemd has started using even more signals or introduced even
> more gaps for no reason at all.

My patch brings hppa in sync with x86 and others, and those don't have more than us then.
This means we would be on the safe side :-)

>> Additionally, given the fact that we have very little users and live
>> in debian/gentoo unstable
>
> That's Debian unstable and Gentoo /stable/ thank you very much. :)

Sorry...
  
>> would IMHO justify such an incompatible change.
>
> Gentoo dropped support for GNOME and KDE years ago (except for some of
> the base libraries such as glib and gtk+ of course). The point being
> that these fat window managers run utterly slow (exactly as they do on
> much more recent x86 hardware).

It's not just the window manager. I tried to install "konsole" and this pulls in systemd.
  
> Interest in supporting systemd therefore never went beyond the
> purely academic interest displayed in [1]. Luckily, Gentoo already uses
> an alternative, modern init system. Gentoo/HPPA has little need for
> systemd, I would guess.

I think Debian will stay with sysvinit and systemd ?
  
>> The other option would be to increase NSIG in kernel from 64 to 128
>> or higher.
>
> Sounds like a lot of work.

Yes.

>> What's your opinion on this?
>
>  From my perspective it looks like a lot of work for very little gain.
> Gentoo has no need for systemd so all these changes would mean
> upgrading kernel and libc requires a lot more attention, and systemd
> could equally well compact the ill-chosen RT signal range.

As I mentioned before, I could not see any direct impact on a debian installation.
Of course I haven't tested everything, but I assume Gentoo would see similiar little
influence too.  

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Aaro Koskinen Oct. 7, 2014, 10:12 p.m. UTC | #6
Hi,

On Tue, Oct 07, 2014 at 05:03:30PM -0400, Carlos O'Donell wrote:
> On Tue, Oct 7, 2014 at 3:39 PM, Helge Deller <deller@gmx.de> wrote:
> > What's your opinion on this?
> 
> Flawless hack. Very well reorganized. Your removal of SIGLOST, and
> reorganizing is the best I could come up with also.
> 
> The only thing I will do different is make SIGEMT equal to SIGABRT,
> that way we preserve the semantics of what this operation means. Linux
> doesn't use SIGEMT, but it keeps hppa defining this for use by other
> software that might want similar semantics. You can catch SIGABRT and
> operate on it, so it's one way forward.
> 
> If you agree I'll checkin to glibc master.

BTW, is there any plan/schedule for getting glibc to support pa-risc
without out-of-tree patches? Any help (e.g. testing) needed there?

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Aaro Koskinen Oct. 7, 2014, 10:34 p.m. UTC | #7
Hi,

On Tue, Oct 07, 2014 at 09:39:59PM +0200, Helge Deller wrote:
> Since systemd gets more and more important (e.g. KDE now seems
> to require systemd) we should try to find a solution.

Personally I don't mind such changes (I compile everything from scratch
so ABI breakages are not a big issue), but generally I think Linux/PA-RISC
community could maybe put more focus on some core issues like GCC
and GLIBC support...

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Oct. 8, 2014, 9:10 a.m. UTC | #8
On 10/07/2014 09:39 PM, Helge Deller wrote:
> I've just had a successful boot on hppa with systemd :-)
> The bootlog is attached.
>...
> I will provide prebuilt debian packages with those patches for kernel and glibc tomorrow for download, so that people may test themselves...

I've uploaded the debian kernel and glibc packages to:
ftp://ftp.parisc-linux.org/SIGNAL_NEW/

A short README is here:
ftp://ftp.parisc-linux.org/SIGNAL_NEW/README.txt

It would be nice if people could test it...

Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
John David Anglin Oct. 8, 2014, 3:59 p.m. UTC | #9
On 10/7/2014 6:34 PM, Aaro Koskinen wrote:
> Personally I don't mind such changes (I compile everything from scratch
> so ABI breakages are not a big issue), but generally I think Linux/PA-RISC
> community could maybe put more focus on some core issues like GCC
> and GLIBC support...
I think that's happening.

On Debian unstable, we currently have 10291 installed packages.
We are neck to neck with ppc64, and a couple hundred behind alpha.
http://buildd.debian-ports.org/stats/

At this point, adding new packages requires porting and bug fixes. The 
signal change proposed
by Helge here is an example.

I am working at the moment on an update to the GCC fast indirect call 
support for Linux.  There
are also two trunk breakages and several minor issues ongoing.

Is there something specific you would like to see?

Dave
Aaro Koskinen Oct. 9, 2014, 8:41 p.m. UTC | #10
Hi,

On Tue, Oct 07, 2014 at 05:03:30PM -0400, Carlos O'Donell wrote:
> The only thing I will do different is make SIGEMT equal to SIGABRT,
> that way we preserve the semantics of what this operation means. Linux
> doesn't use SIGEMT, but it keeps hppa defining this for use by other
> software that might want similar semantics. You can catch SIGABRT and
> operate on it, so it's one way forward.

I tested Helge's SIGNAL_NEW patches by recompiling my small distro
(~100 packages) and only Tcl 8.6 complation breaks (duplicate case
value in tclPosixStr.c / Tcl_SignalMsg).

The current check they have is:

#if defined(SIGEMT) && (!defined(SIGXCPU) || (SIGEMT != SIGXCPU))
    case SIGEMT: return "SIGEMT";
#endif

A.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Carlos O'Donell Oct. 9, 2014, 8:48 p.m. UTC | #11
On Thu, Oct 9, 2014 at 4:41 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> #if defined(SIGEMT) && (!defined(SIGXCPU) || (SIGEMT != SIGXCPU))
>     case SIGEMT: return "SIGEMT";
> #endif

Helge,

I withdraw my suggestion to make SIGEMT equal to SIGABRT. Just remove
it. It's not needed on Linux and just causes problems.

In this case it conflicts with SIGABRT in the case statement. Better
to just remove it.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Helge Deller Oct. 9, 2014, 8:58 p.m. UTC | #12
Hi Aaro & Carlos,

On 10/09/2014 10:48 PM, Carlos O'Donell wrote:
> On Thu, Oct 9, 2014 at 4:41 PM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
>> #if defined(SIGEMT) && (!defined(SIGXCPU) || (SIGEMT != SIGXCPU))
>>      case SIGEMT: return "SIGEMT";
>> #endif

Aaro, thanks a lot for testing !!!

> I withdraw my suggestion to make SIGEMT equal to SIGABRT. Just remove
> it. It's not needed on Linux and just causes problems.
>
> In this case it conflicts with SIGABRT in the case statement. Better
> to just remove it.

Yes, I agree.

Helge

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff -up ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h.org ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h
--- ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h.org	2014-10-06 10:58:34.071963059 +0200
+++ ./ports/sysdeps/unix/sysv/linux/hppa/bits/signum.h	2014-10-06 11:02:48.879949179 +0200
@@ -35,13 +35,13 @@ 
 #define	SIGILL		4	/* Illegal instruction (ANSI).  */
 #define	SIGTRAP		5	/* Trace trap (POSIX).  */
 #define	SIGABRT		6	/* Abort (ANSI).  */
+#define	SIGSTKFLT	7	/* Stack fault.  */
 #define	SIGIOT		6	/* IOT trap (4.2 BSD).  */
-#define	SIGEMT		7
 #define	SIGFPE		8	/* Floating-point exception (ANSI).  */
 #define	SIGKILL		9	/* Kill, unblockable (POSIX).  */
 #define	SIGBUS		10	/* BUS error (4.2 BSD).  */
 #define	SIGSEGV		11	/* Segmentation violation (ANSI).  */
-#define SIGSYS		12	/* Bad system call.  */
+#define	SIGXCPU		12	/* CPU limit exceeded (4.2 BSD).  */
 #define	SIGPIPE		13	/* Broken pipe (POSIX).  */
 #define	SIGALRM		14	/* Alarm clock (POSIX).  */
 #define	SIGTERM		15	/* Termination (ANSI).  */
@@ -61,11 +61,9 @@ 
 #define	SIGTTIN		27	/* Background read from tty (POSIX).  */
 #define	SIGTTOU		28	/* Background write to tty (POSIX).  */
 #define	SIGURG		29	/* Urgent condition on socket (4.2 BSD).  */
-#define SIGLOST		30	/* Operating System Has Lost (HP/UX). */
+#define	SIGXFSZ		30	/* File size limit exceeded (4.2 BSD).  */
+#define SIGSYS		31	/* Bad system call.  */
 #define SIGUNUSED	31
-#define	SIGXCPU		33	/* CPU limit exceeded (4.2 BSD).  */
-#define	SIGXFSZ		34	/* File size limit exceeded (4.2 BSD).  */
-#define	SIGSTKFLT	36	/* Stack fault.  */
 
 #define	_NSIG		65	/* Biggest signal number + 1
 				   (including real-time signals).  */
@@ -75,7 +73,7 @@ 
 
 /* These are the hard limits of the kernel.  These values should not be
    used directly at user level.  */
-#define __SIGRTMIN	37
+#define __SIGRTMIN	32	/* Kernel > 3.17 */
 #define __SIGRTMAX	(_NSIG - 1)
 
 #endif	/* <signal.h> included.  */