re: CVS commit: src/sys/arch/xen

[matthew green]

"Jaromir Dolecek" writes:
> Module Name:  src
> Committed By: jdolecek
> Date: Fri May 15 07:42:58 UTC 2020
> 
> Modified Files:
>   src/sys/arch/xen/include: intr.h
>   src/sys/arch/xen/x86: pintr.c
> 
> Log Message:
> use short for irq2port[] to save memory (4KB), it only needs to store
> numbers <= NR_EVENT_CHANNELS (2048)

not that they're necessarily related, but you can have a look
at PR#54837 which has problems with running out of interrrupts
on systems with lots of cpus and devices with lots of msix?

thanks.


.mrg.

Re: CVS commit: src/external/mpl/dhcp/dist/common

[Christos Zoulas]

In article <20200515123104.297c5f...@cvs.netbsd.org>,
Emmanuel Dreyfus  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  manu
>Date:  Fri May 15 12:31:04 UTC 2020
>
>Modified Files:
>   src/external/mpl/dhcp/dist/common: bpf.c discover.c lpf.c packet.c
>   raw.c socket.c
>
>Log Message:
>crunchgen fix
>
>Make sure local_port is not shared within a crunchgen binary. There is
>more to do to get full functionnality in crunchgen, but at least this
>change makes dhcpd listen on the right port again.

Can't this be done with -Dlocal_port= in the Makefile?

christos

Re: CVS commit: src/tests/lib/libc/sys

[Kamil Rytarowski]

On 15.05.2020 00:43, Taylor R Campbell wrote:
>> Date: Thu, 14 May 2020 23:36:28 +0200
>> From: Kamil Rytarowski 
>>
>> If a signal would not reach the child process (as it is ignored or
>> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
>> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
>> Race free signals could be maybe possible, but with some design rethinking.
> 
> I don't understand -- are you saying that if I mask SIGCHLD, e.g. with
> sigprocmask(SIG_BLOCK), then because sigprop[SIGCHLD] has SA_IGNORE
> set, any SIGCHLD signals will be discarded while I have it masked?
> 

That's it. But it will be discarded only when there is no SIGCHLD signal
handler installed. That's the case in the test.

A debugger catches regular signals only (except crash related ones) when
they reach the debuggee,

> This can't be right, so either I misunderstood what you're saying, or
> something else is afoot with the test that is making it flaky, or
> there's a bug in the kernel.
> 

It's a design.

If we install a signal handler for SIGCHLD in the traced the test is
very stable and we note SIGCHLD always, so there is no bug.



signature.asc
Description: OpenPGP digital signature