On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote:
> >>I will bump revision for stable/8 when merging, but I do not see much
> >>reason to bump on HEAD right now.
>
> Many thanks.
>
> >Uhm I think we can survive without a bump in HEAD. For now we will
> >need to keep our backward-com
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl compar
2011/7/12 Kostik Belousov :
> I just committed this to HEAD. Will MFC in a week, unless some problems
> arise.
Thanks!
> I will bump revision for stable/8 when merging, but I do not see much
> reason to bump on HEAD right now.
Uhm I think we can survive without a bump in HEAD. For now we will
n
On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote:
> >Below is the patch I intend to commit after you retest it.
>
> I applied it against our 8.2 based package,
> altered our "clone" to use this new
> interface and run eglibc testsuite. No regression.
>
> Our runtime detection of thi
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our "clone" to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new interface will be based
on "sysctl kern.osreldate".
some rewording
Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
DESCRIPTION:
RFTSIGZMB If set, the kernel will return selected signal number instead
of SIGCHILD upon thread exit for
On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote:
> >>Seems this interface be acceptable ?
> >
> >Looks good to me.
>
> The proposed code changes are in the attached patch.
>
> Proposed wording of addition into RFORK(2):
Below is the patch I intend to commit after you retest it.
I a
On Mon, Jul 11, 2011 at 08:05:56PM +0200, Petr Salinger wrote:
> >>Should the bit slice be 7 or 8 bits ?
>
> >I propose to go 8 bits, and add the check to be future-proof.
>
> >It seems that we already parse GNU/kFreeBSD brandnote. I think this
> >could be used to distinguish between old behaviou
Should the bit slice be 7 or 8 bits ?
I propose to go 8 bits, and add the check to be future-proof.
It seems that we already parse GNU/kFreeBSD brandnote. I think this
could be used to distinguish between old behaviour, that is currently
used by your libc, and proposed new interface, if __Fr
On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote:
> >I would instead use a new flag to specify a signal sent on the child
> >death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
> >set, the bit slice is used as signal number, 0 means do not send any
> >signal.
> >
> >Pl
I would instead use a new flag to specify a signal sent on the child
death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
set, the bit slice is used as signal number, 0 means do not send any
signal.
Please note that the signal should be checked for validity, it must be
<= _SIG_MAX
On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote:
> >>The 1st patch satisfies this. I agree that SIGCHLD part
> >>is not easily readable.
> >The SIGCHLD part is ugly. This is why I am asking about possible ways
> >to overcome this.
>
> We need a way to specify "no signal".
> It can be
The 1st patch satisfies this. I agree that SIGCHLD part
is not easily readable.
The SIGCHLD part is ugly. This is why I am asking about possible ways
to overcome this.
We need a way to specify "no signal".
It can be "new flag" or "ugly SIGCHLD".
new flag:
pros: cleaner design
cons: one bit
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 sign
RFLINUXPTH was used by the linuxthreads port, that was popular in the
time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
this breakage.
Do I understand correctly that API/ABI backward compatibility with
previous FreeBSD releases w.r.t RFLINUXPTH is needed ?
The 1st patch s
2011/7/11 Kostik Belousov :
> 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 ?
Perhaps we
On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote:
> >RFLINUXPTH was used by the linuxthreads port, that was popular in the
> >time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
> >this breakage.
>
> Do I understand correctly that API/ABI backward compatibility with
On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote:
> >>>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
On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote:
> >>This patch made by Petr Salinger improves compatibility with
> >>LinuxThreads in rfork() syscall. The Linux clone() implementation
> >>allows specifying the signal sent to parent when child terminates
> >>(instead of SIGCHLD).
> >>
19 matches
Mail list logo
