All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Paul Durrant <Paul.Durrant@citrix.com>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] Plumb through xen-platform device logging
Date: Thu, 11 Jul 2013 14:54:16 +0100	[thread overview]
Message-ID: <51DEB908.9020809@citrix.com> (raw)
In-Reply-To: <1373547056.5453.184.camel@hastur.hellion.org.uk>

On 11/07/13 13:50, Ian Campbell wrote:
> On Thu, 2013-07-11 at 13:07 +0100, Paul Durrant wrote:
> 
>>> > > Looking at http://wiki.qemu.org/Features/Tracing is the tracing
>>> > > interface really the right way to be logging this particular class of
>>> > > information? I'd have thought a simple logfile support in the platform
>>> > > device would be a much more natural fit.
>>> > > 
>> > 
>> > That makes sense to me, but whoever coded up the platform device
>> > obviously believed tracing to be the correct way to log. I don't know
>> > the history of that decision.
> I guess either Anthony or Stefano knows. Do you guys know why we log the
> platform device I/O port debug via the trace subsystems? It doesn't seem
> like a good fit.

It seams that I made this choice long time ago.
http://marc.info/?l=xen-devel&m=129864357001108&w=2

But I never try to use it, that was maybe not a great choice. After a
quick look into the qemu tree, using the trace thing those not seams bad
as well. There is just few step:

 - compile qemu with traces enable
 - adding to the vm-xl-config this:
device_model_args_hvm = [ '-trace', 'events=/tmp/traces' ]
(with "xen_platform_log" in /tmp/traces)


So, about the patch, I don't feel a good idea to have it enable all the
time for all the guest. Also, QEMU will refuse to start if it's compiled
without trace support.

> A better fit would be the qemu chr subsystem (I think that's the name, I
> mean the thing which lets you direct serial/parallel etc to
> file,tcp,sockets etc etc.)

This can maybe be done using a property, which could be set via the
command line by using the -device options.

-- 
Anthony PERARD

  reply	other threads:[~2013-07-11 13:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-04 15:33 [PATCH] Plumb through xen-platform device logging Paul Durrant
2013-07-11  8:23 ` Paul Durrant
2013-07-11 11:43   ` Ian Campbell
2013-07-11 12:07     ` Paul Durrant
2013-07-11 12:25       ` Don Slutz
2013-07-11 12:28       ` Don Slutz
2013-07-11 13:15         ` Paul Durrant
2013-07-11 12:50       ` Ian Campbell
2013-07-11 13:54         ` Anthony PERARD [this message]
2013-07-11 13:59           ` Paul Durrant
2013-07-11 14:01       ` Ian Campbell
2013-07-11 14:49         ` Paul Durrant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51DEB908.9020809@citrix.com \
    --to=anthony.perard@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.