Le 19/01/2021 à 19:24, Alistair Francis a écrit :
> When mapping the host waitid status to the target status we previously
> just used decoding information in the status value. This doesn't follow
> what the waitid documentation describes, which instead suggests using
> the si_code value for the de
Le 19/01/2021 à 19:24, Alistair Francis a écrit :
> When mapping the host waitid status to the target status we previously
> just used decoding information in the status value. This doesn't follow
> what the waitid documentation describes, which instead suggests using
> the si_code value for the de
On Thu, Jan 21, 2021 at 7:15 AM Andreas K. Hüttel wrote:
>
> Am Mittwoch, 20. Januar 2021, 22:12:30 EET schrieb Andreas K. Hüttel:
> > > This patch just passes the waitid status directly back to the guest.
> >
> > This works at least as well as the previous versions, so ++ from me.
> >
> > Will do
Am Mittwoch, 20. Januar 2021, 22:12:30 EET schrieb Andreas K. Hüttel:
> > This patch just passes the waitid status directly back to the guest.
>
> This works at least as well as the previous versions, so ++ from me.
>
> Will do more testing over the next days to see if it maybe also improves the
>
> This patch just passes the waitid status directly back to the guest.
>
This works at least as well as the previous versions, so ++ from me.
Will do more testing over the next days to see if it maybe also improves the
additional oddities I observed.
Tested-by: Andreas K. Hüttel
> Bugli
When mapping the host waitid status to the target status we previously
just used decoding information in the status value. This doesn't follow
what the waitid documentation describes, which instead suggests using
the si_code value for the decoding. This results in the incorrect values
seen when cal
