Well, I didn't expect this much discussion!!! I must admit I found it
hard to grok this code initially but I think the idea of exec'ing a
separate program is a good one to avoid the chance that xend can die
(especially since you don't currently seem to be able to restart xend
without rebooting Dom0).
Anyway - even if XendCheckpoint.py called xc_linux_save/restore
directly, you'd still have to deal with getting the output to the right
place since these APIs write their debug output directly to stderr so
I've got to believe you'd still fork a child that made the call and have
the parent slurp the contents of stderr and log them so the same issue
would exist...
Simon
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx]
> Sent: Monday, November 20, 2006 4:56 PM
> To: Graham, Simon
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Trivial patch to fix logging level output by
> XendCheckpoint.py
>
> On Mon, Nov 20, 2006 at 04:34:25PM -0500, Graham, Simon wrote:
> > Signed-off by: Simon Graham <Simon.Graham@xxxxxxxxxxx>
> >
> > There is a somewhat trivial issue with XendCheckpoint.py right now
in
> > that it logs everything written to stderr by xc_save and xc_restore
> as
> > errors whereas in fact the vast majority of this output is
> > information/debug (and all actual errors are marked by the string
> ERROR:
> > at the start of the message) -- this is confusing to folks looking
at
> > the logs and makes automated log analysis tricky.
> >
> > Fix is to scan for the ERROR: string and log anything without it
> using
> > log.info instead.
>
> This bit of XenD looks rather dubious to me. XenD spawns a background
> thread, which in turn forks the xc_save or xc_restore program, reading
> the stdout from this child process.
>
> Aside from command line argument handling, the xc_save and xc_restore
> programs each only make *one* single function call to xc_linux_save or
> xc_linux_restore APIs in libxc.
>
> But XenD already has libxc loaded & calls it directly for all other
> jobs
> its needs to do, including actually createing the domain in the first
> place. So why is it going to all the trouble of fork'ing a child
> process
> rather than just calling xc_linux_save/restore APIs directly ? If it
> did this, we wouldn't need this loop to read, grok & log STDOUT from
> the
> child process at all - it would just end up in regular XenD logs.
>
> And even more importantly, once we get the error reporting patches
> integrated
> into libxc, having the xc_linux_save/restore calls made by XenD
> directly
> would ensure we get reliable error handling for save/restore
> operations.
>
> So, is there any good reason for xc_save & xc_restore to exist as
> separate
> processes - it just seems like a huge complication to me, increasing
> fragility of the system & reducing the quality of error reporting we
> can
> get
>
> Regards,
> Dan.
> --
> |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392
> 2496 -=|
> |=- Perl modules: http://search.cpan.org/~danberr/
> -=|
> |=- Projects: http://freshmeat.net/~danielpb/
> -=|
> |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B
> 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home