| Message ID | 20170207235757.2026-1-mreitz@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Wed, Feb 08, 2017 at 12:57:57AM +0100, Max Reitz wrote: > Currently we only print progress information on retrieval of SIGUSR1. > Some systems have a dedicated SIGINFO for this, however, so it should be > handled appropriately if it is available. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > Can anyone test this on a BSD system? O:-) > --- > util/qemu-progress.c | 3 +++ > qemu-img.texi | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 08.02.2017 00:57, Max Reitz wrote: > Currently we only print progress information on retrieval of SIGUSR1. > Some systems have a dedicated SIGINFO for this, however, so it should be > handled appropriately if it is available. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > Can anyone test this on a BSD system? O:-) > --- > util/qemu-progress.c | 3 +++ > qemu-img.texi | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) Ping
On 08.02.2017 00:57, Max Reitz wrote: > Currently we only print progress information on retrieval of SIGUSR1. > Some systems have a dedicated SIGINFO for this, however, so it should be > handled appropriately if it is available. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > Can anyone test this on a BSD system? O:-) > --- > util/qemu-progress.c | 3 +++ > qemu-img.texi | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) Ping (If nobody replies in the next month or so, I'm just going to merge this, as util/qemu-progress.c doesn't have a maintainer.)
On 04/13/2017 04:38 PM, Max Reitz wrote: > On 08.02.2017 00:57, Max Reitz wrote: >> Currently we only print progress information on retrieval of SIGUSR1. >> Some systems have a dedicated SIGINFO for this, however, so it should be >> handled appropriately if it is available. >> >> Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 >> Signed-off-by: Max Reitz <mreitz@redhat.com> >> --- >> Can anyone test this on a BSD system? O:-) >> --- >> util/qemu-progress.c | 3 +++ >> qemu-img.texi | 3 ++- >> 2 files changed, 5 insertions(+), 1 deletion(-) > > Ping > > (If nobody replies in the next month or so, I'm just going to merge > this, as util/qemu-progress.c doesn't have a maintainer.) > https://www.youtube.com/watch?v=vU54c3YDyak
On Thu, 04/13 22:38, Max Reitz wrote: > On 08.02.2017 00:57, Max Reitz wrote: > > Currently we only print progress information on retrieval of SIGUSR1. > > Some systems have a dedicated SIGINFO for this, however, so it should be > > handled appropriately if it is available. > > > > Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 > > Signed-off-by: Max Reitz <mreitz@redhat.com> > > --- > > Can anyone test this on a BSD system? O:-) > > --- > > util/qemu-progress.c | 3 +++ > > qemu-img.texi | 3 ++- > > 2 files changed, 5 insertions(+), 1 deletion(-) > > Ping > > (If nobody replies in the next month or so, I'm just going to merge > this, as util/qemu-progress.c doesn't have a maintainer.) qemu-img.c is the sole user, so it implicitly belongs to the block maintainers, I assume. Actually, why not add this file under block layer section of MAINTAINERS? Fam
On 08.02.2017 00:57, Max Reitz wrote: > Currently we only print progress information on retrieval of SIGUSR1. > Some systems have a dedicated SIGINFO for this, however, so it should be > handled appropriately if it is available. > > Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > Can anyone test this on a BSD system? O:-) > --- > util/qemu-progress.c | 3 +++ > qemu-img.texi | 3 ++- > 2 files changed, 5 insertions(+), 1 deletion(-) Applied to my block branch. (https://github.com/XanClic/qemu/commits/block) Max
diff --git a/util/qemu-progress.c b/util/qemu-progress.c index f745233763..3c2223c1a2 100644 --- a/util/qemu-progress.c +++ b/util/qemu-progress.c @@ -88,6 +88,9 @@ static void progress_dummy_init(void) action.sa_handler = sigusr_print; action.sa_flags = 0; sigaction(SIGUSR1, &action, NULL); +#ifdef SIGINFO + sigaction(SIGINFO, &action, NULL); +#endif /* * SIGUSR1 is SIG_IPI and gets blocked in qemu_init_main_loop(). In the diff --git a/qemu-img.texi b/qemu-img.texi index 174aae38b7..b7e849b22b 100644 --- a/qemu-img.texi +++ b/qemu-img.texi @@ -84,7 +84,8 @@ with or without a command shows help and lists the supported formats @item -p display progress bar (compare, convert and rebase commands only). If the @var{-p} option is not used for a command that supports it, the -progress is reported when the process receives a @code{SIGUSR1} signal. +progress is reported when the process receives a @code{SIGUSR1} or +@code{SIGINFO} signal. @item -q Quiet mode - do not print any output (except errors). There's no progress bar in case both @var{-q} and @var{-p} options are used.
Currently we only print progress information on retrieval of SIGUSR1. Some systems have a dedicated SIGINFO for this, however, so it should be handled appropriately if it is available. Buglink: https://bugs.launchpad.net/qemu/+bug/1662468 Signed-off-by: Max Reitz <mreitz@redhat.com> --- Can anyone test this on a BSD system? O:-) --- util/qemu-progress.c | 3 +++ qemu-img.texi | 3 ++- 2 files changed, 5 insertions(+), 1 deletion(-)