All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Gardner <rob.gardner@hp.com>
To: sowmya dayanand <sowmyad@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Xen File functions
Date: Sun, 30 Oct 2005 21:49:06 -0700	[thread overview]
Message-ID: <4365A242.8070203@hp.com> (raw)
In-Reply-To: <83c5685b0510301641scfcee4fl36a204b368ff055a@mail.gmail.com>

sowmya dayanand wrote:

> Hi,
>
> We are trying to modify the file /xen-2.0/xen/common/dom0_ops.c 
> function: long do_dom0_op(dom0_op_t *u_dom0_op) to log all the calls 
> made. We need to write all these calls to a file. I am not able to use 
> standard C functions ( fopen , fprintf) as we get  compilation error. 
> Are there any xen specific functions that we need to use to read/write 
> files?


Since I/O in Xen is done by the "device domains", the Xen hypervisor 
itself cannot simply open files and write data. Where would the files 
reside? I can think of a few possible solutions for you off the top of 
my head.  First, consider hooking the dom0_op on the calling side. The 
do_dom0_op() call that is used by most (if not all) the hypercalls is 
just user code in a shared library. Just make your own version of 
tools/libxc/xc_private.c with the logging you like, then compile it up 
to create a new shared library. Install that, and you will be logging 
hypercalls, since most code I believe is linked against the shared 
library, so any executable will automatically run your code. If that 
doesn't work, you can hook in a little bit deeper; The hypercall as made 
from a domain is actually an ioctl() made to a pseudo-driver. Look at 
linux-2.6.12-xen0/drivers/xen/privcmd/privcmd.c. This doesn't completely 
solve your problem, but it will be much easier to do file I/O from the 
linux kernel that it will be from xen. If these two ideas fail for some 
reason, or if you insist on working within the hypervisor, the other 
possibliity is to log the calls in common/dom0_ops.c to a memory buffer, 
then share that memory bufer with a dom0 user app that periodically 
reads the stuff out of it. This is basically how the xen trace buffer 
works. For that matter, you might be able to just use the xen trace 
buffers if there is enough space in the trace() parameters to hold all 
the information you need. Hope one of these ideas proves useful to you.

Rob Gardner
Hewlett Packard

      reply	other threads:[~2005-10-31  4:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-31  0:41 Xen File functions sowmya dayanand
2005-10-31  4:49 ` Rob Gardner [this message]

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=4365A242.8070203@hp.com \
    --to=rob.gardner@hp.com \
    --cc=sowmyad@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /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.