On Fri, 2024-10-25 at 16:36 +0100, Richard Henderson wrote:
> On 10/25/24 10:32, Ilya Leoshkevich wrote:
> > On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
> > > Cc'ing Brian & Taylor
> > >
> > > On 12/2/24 21:45, Ilya Leoshkevich wrote:
> > > > Some applications want to use low
On 10/25/24 10:32, Ilya Leoshkevich wrote:
On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
Cc'ing Brian & Taylor
On 12/2/24 21:45, Ilya Leoshkevich wrote:
Some applications want to use low priority realtime signals (e.g.,
SIGRTMAX). Currently QEMU cannot map all target realtim
On Tue, 2024-02-13 at 07:51 +0100, Philippe Mathieu-Daudé wrote:
> Cc'ing Brian & Taylor
>
> On 12/2/24 21:45, Ilya Leoshkevich wrote:
> > Some applications want to use low priority realtime signals (e.g.,
> > SIGRTMAX). Currently QEMU cannot map all target realtime signals to
> > host signals, an
Cc'ing Brian & Taylor
On 12/2/24 21:45, Ilya Leoshkevich wrote:
Some applications want to use low priority realtime signals (e.g.,
SIGRTMAX). Currently QEMU cannot map all target realtime signals to
host signals, and chooses to sacrifice the end of the target realtime
signal range.
Change this
Some applications want to use low priority realtime signals (e.g.,
SIGRTMAX). Currently QEMU cannot map all target realtime signals to
host signals, and chooses to sacrifice the end of the target realtime
signal range.
Change this to the middle of that range, hoping that fewer applications
will ne
