Date: Mon, 11 Jul 2011 16:23:36 +0200 (CEST) From: Petr Salinger <Petr.Salinger@seznam.cz> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Robert Millan <rmh@debian.org>, current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() Message-ID: <alpine.LRH.2.02.1107111556000.7134@sci.felk.cvut.cz> In-Reply-To: <20110711133342.GT43872@deviant.kiev.zoral.com.ua> References: <CAOfDtXMe_pkBdAFpUdvzmfs38Re=nw_YBz4w0Va0naEcuak7iw@mail.gmail.com> <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111455230.7134@sci.felk.cvut.cz> <20110711133342.GT43872@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Can you, please, describe the reasoning behind the >>>> + if (sig == SIGCHLD) sig = 0; >>> line ? >> >> The main reason is backward compatibility. >> The original FreeBSD code allows only to select between >> SIGUSR1 or SIGCHLD signals. >> >> The our extension changes meaning of RFLINUXTHPN to select signal based on >> bits 24-30 of passed flags instead of using SIGUSR1 every time. >> >> When the passed "signal" number is zero, it should behave identically >> on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. >> The assumption is (have been) that (yet) undefined bits are zero. >> That way we are backward compatible with original FreeBSD. >> >> We still need an alternative way to select "none signal is sent" >> after child exit (under linux #0 is used). >> >> The SIGCHLD can be "selected" (also on original FreeBSD) by not specifying >> RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" >> number SIGCHLD is (have been) used for "none signal". >> >> BTW, the opposite side is in >> >> http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clone.c?view=markup > > I shall state that the sig == SIGCHLD case is ugly. Having the separate > flag "do not send signal to the parent" would be much less clumsy. > What are the requirements for the ABI stability for Debian/kFreeBSD ? > Can this be fixed now, or is it too late ? It should be backward compatible with one previous version. What about in long term this: RFLINUXTHPN bit will be renamed and will have meaning "select signal based on bits 24-30 of passed flags" - zero would mean "no signal" - SIGCHLD would mean undefined - SIGUSR1 would mean SIGUSR1 It is ABI/API breakage under original FreeBSD. The question is how frequently RFLINUXTHPN is used under native FreeBSD and its port collection. And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT - SIGCHLD would mean "no signal" We do not use SIGUSR1 currently, the eglibc side can detect whether it runs under new-enough kernel and decide whether use 0 or SIGCHLD for "no signal". The kernel side would be something like: if (flags & RFLINUXTHPN) { p2->p_sigparent = RFTHPNSIGNUM(flags); #if COMPAT8 if (p2->p_sigparent == SIGCHLD) p2->p_sigparent = 0; #endif } Petr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LRH.2.02.1107111556000.7134>