On Fri, 3 Aug 2018 12:07:58 +
"Wang, Zhi A" wrote:
> Hi:
>
> Thanks for unfolding your idea. The picture is clearer to me now. I didn't
> realize that you also want to support cross hardware migration. Well, I
> thought for a while, the cross hardware migration might be not popular in
>
On Fri, 3 Aug 2018 at 18:49, Erik Skultety wrote:
>
> On Sat, Jul 28, 2018 at 11:31:31PM +0530, Sukrit Bhatnagar wrote:
> > By making use of GNU C's cleanup attribute handled by the
> > VIR_AUTOPTR macro for declaring aggregate pointer variables,
> > majority of the calls to *Free functions can
On Thu, Aug 02, 2018 at 06:40:56PM +0200, Andrea Bolognani wrote:
If all we achieve is reducing the depth by one for a single
test case, the additional complexity (not to mention breaking
the principle of least surprise) is not worth it: let's use
simpler, more predictable code instead.
This
On Mon, 2018-07-30 at 10:07 -0400, Anya Harter wrote:
[...]
> static int
> -virInterfaceObjListPopulate(void *payload,
> +virInterfaceObjListExportCallback(void *payload,
> const void *name ATTRIBUTE_UNUSED,
> void *opaque)
Please make
On Mon, 2018-07-30 at 10:07 -0400, Anya Harter wrote:
> conf: rename structs used by Export function
>
> to be the name of the Export function followed by Data
>
> ex. for virInterfaceObjListExport, the struct is named
> virInterfaceObjListExportData
The title and body of the
On Sat, Jul 28, 2018 at 11:31:34PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On Sat, Jul 28, 2018 at 11:31:33PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:32PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On Sat, Jul 28, 2018 at 11:31:29PM +0530, Sukrit Bhatnagar wrote:
> Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in
> src/util/viralloc.h, define a new wrapper around an existing
> cleanup function which will be called when a variable declared
> with VIR_AUTOPTR macro goes out of scope.
On Sat, Jul 28, 2018 at 11:31:31PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:30PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On Fri, Aug 03, 2018 at 06:38:30PM +0530, Sukrit Bhatnagar wrote:
> On Fri, 3 Aug 2018 at 18:32, Erik Skultety wrote:
> >
> > On Sat, Jul 28, 2018 at 11:31:28PM +0530, Sukrit Bhatnagar wrote:
> > > By making use of GNU C's cleanup attribute handled by the
> > > VIR_AUTOPTR macro for declaring
On Sat, Jul 28, 2018 at 11:31:25PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:24PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
The distros we support for RPM builds all have %autosetup support so we
can ditch the convoluted code for running git manually and use the RPM
defaults.
Signed-off-by: Daniel P. Berrangé
---
libvirt.spec.in | 38 +-
1 file changed, 1 insertion(+), 37
On Sat, Jul 28, 2018 at 11:31:22PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOPTR macro for declaring aggregate pointer variables,
> majority of the calls to *Free functions can be dropped, which
> in turn leads to getting rid of most of
On Sat, Jul 28, 2018 at 11:31:21PM +0530, Sukrit Bhatnagar wrote:
> By making use of GNU C's cleanup attribute handled by the
> VIR_AUTOFREE macro for declaring scalar variables, majority
> of the VIR_FREE calls can be dropped, which in turn leads to
> getting rid of most of our cleanup sections.
On Fri, Aug 03, 2018 at 09:30:22AM +0200, Erik Skultety wrote:
> On Sat, Jul 28, 2018 at 11:31:19PM +0530, Sukrit Bhatnagar wrote:
> > Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in
> > src/util/viralloc.h, define a new wrapper around an existing
> > cleanup function which will be called
On Sat, Jul 28, 2018 at 11:31:20PM +0530, Sukrit Bhatnagar wrote:
> Using the new VIR_DEFINE_AUTOPTR_FUNC macro defined in
> src/util/viralloc.h, define a new wrapper around an existing
> cleanup function which will be called when a variable declared
> with VIR_AUTOPTR macro goes out of scope.
On Thu, Aug 02, 2018 at 11:03:16PM +0530, Sukrit Bhatnagar wrote:
> On Thu, 2 Aug 2018 at 19:33, Erik Skultety wrote:
> >
> > On Sat, Jul 28, 2018 at 11:31:18PM +0530, Sukrit Bhatnagar wrote:
> > > By making use of GNU C's cleanup attribute handled by the
> > > VIR_AUTOFREE macro for declaring
Hi,
I was recently looking into a case which essentially looked like this:
1. virsh shutdown guest
2. after <1 second the qemu process was gone from /proc/
3. but libvirt spun in virProcessKillPainfully because the process
was still reachable via signals
4. virProcessKillPainfully
In cases where virProcessKillPainfully already reailizes that
SIGTERM wasn't enough we are partially on a bad path already.
Maybe the system is overloaded or having serious trouble to free and
reap resources in time.
In those case give the SIGKILL that was sent after 10 seconds some more
time to
22 matches
Mail list logo
