[libvirt] [PATCH 5/6] Add an an internal API for emergency dump of debug buffer

[Daniel Veillard]

On Mon, Mar 07, 2011 at 01:22:09PM +0000, Daniel P. Berrange wrote:
> On Mon, Mar 07, 2011 at 09:18:46PM +0800, Daniel Veillard wrote:
> >   the problem is that I really want to empty the buffer as a
> > result of emitting the logs, i.e. the reader will emit only once
> > the content at most.
> 
> While emptying the buffer is nice, I don't actually think it is
> too important.  Upon SEGV,BUS,FPE etc we're going to abort the
> entire process anyway, so clearing the buffer isn't neccessary.
> With SIGUSR2, if the user triggers it multiple times, they will
> likely have left enough time between invocation that the original
> data has been already overwritten. So clearing the buffer is a
> minor non-critical optmization for that.

  Well it's actually interesting to see what my have happen between
exactly 2 instruction on an otherwise idle system, and consecutive
USR2 gives this if we flush, I palyed with this a bit and I like the
feature, it would be sad to drop this if we can avoid.

> > > It would probably suffice to make sure we use atomic integer
> > > arithmetic on virLogLen, virLogStart and virLogEnd, and update
> > > them in a specific order to avoid a reader seeing garbage.
> > 
> > honnestly I would not be chagrined by the probability of emitting
> > a little bit of garbage when flushing the logs or one or two items.
> > I think we can work lockless there, by registering the initial values
> > of virLogStart and virLogEnd when entering the routine, emit whever is
> > in those boundaries with the tiny risk that some of it may be
> > overwritten (at the beginning hence the less interesting stuff) and
> > on exit set back virLogStart = virLogEnd and virLogLen = 0, possibly
> > loosing whetver might have been emitted between the beginning of the
> > save and the exit from the routine.
> 
> Agreed, the only thing we need to avoid is crashing. If we emit a little
> bit of garbage data, that's not too bad and outweighed by the benefit of
> useful data in most scenarios.

  Okay, I'm gonna look more closely. The good thing is that
virLogEmergencyDumpAll() is really the only function reading that
buffer so it should be easy to make things safe without locking.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/