| Message ID | 5434418F.1020407@gmx.de (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
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
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
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
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
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
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
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
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
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
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
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
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
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. */