Garrett Cooper wrote:
> Hi,
> While trying to determine how to print out routes via kvm for
> net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
> days that isn't executed in netstat as NewTree is always 0. The
> following patch removes that dead code and gets the FreeBSD so
Hi,
While trying to determine how to print out routes via kvm for
net-snmp, I noticed that there's a chunk of code from the 4.4 BSD Lite
days that isn't executed in netstat as NewTree is always 0. The
following patch removes that dead code and gets the FreeBSD source for
netstat more in line wi
On 07/11/2011 05:08, Ilya Bakulin wrote:
> chroot constraints only filesystem namespace, but doesn't prevent process
> from sending/receiving data via network,
... which is kind of important for DNS software. :)
> or from accessing other global
> namespaces such as PID namespace, SHM namespace, 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
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
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
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
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
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
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).
As the threading implementation in Debian GNU/kFreeBSD is
LinuxThreads-based, we
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).
> >>
Hello Jaakko,
Thanks for pointing these out to me, I have fixed the one from PR 157718, I
will check this one out tomorrow.
Edwin
On 08/07/2011, at 5:01 PM, Jaakko Heinonen wrote:
> On 2011-07-05, Julian H. Stacey wrote:
>> Jaakko Heinonen wrote:
>>> On 2011-07-05, Julian H. Stacey wrote:
On Mon, Jul 11, 2011 at 12:54:06PM +0200, Robert Millan 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).
>
> As the
chroot constraints only filesystem namespace, but doesn't prevent process
from sending/receiving data via network, or from accessing other global
namespaces such as PID namespace, SHM namespace, and from executing any
system calls.
In contract to chroot, Capsicum framework significantly increases
a
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).
As the threading implementation in Debian GNU/kFreeBSD is
LinuxThreads-based, we h
20 matches
Mail list logo
