From: Renzo Davoli <renzo@cs.unibo.it>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Roland McGrath <roland@redhat.com>,
utrace-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] utrace core
Date: Sat, 21 Mar 2009 15:08:22 +0100 [thread overview]
Message-ID: <20090321140822.GE18690@cs.unibo.it> (raw)
In-Reply-To: <20090321014909.6b654f55.akpm@linux-foundation.org>
Tracing does not mean only debug. Some tracing facilities can be used for virtualization.
For example User-Mode Linux is based on ptrace.
I have a prototype of kernel module for virtualization (kmview) based on utrace.
Using kmview (module+VMM) it is possible for a user (not root) to mount a filesystem just for
a process (or a hierarchy of processes), or it is possible for some processes to
use different networking stacks or virtual devices. It is something like user-mode containers.
kmview provides the same features of umview, based on ptrace, in a (very) faster way.
(umview is in Debian lenny,squeeze,sid if you want to test it)
*Utrace is really what I wanted* to support kmview (apart from
some minor issues about the support of nested virtualizations).
Other virtualizations now based on ptrace could move part of their implementation
at kernel level by utrace and several speedups become possible.
For example kmview is a partial virtual machine monitor: some system calls are forwarded
to the kernel, some others virtualized.
When a user mounts a filesystem, all the system calls which use pathnames inside the mountpoint
subtree get virtualized while the others are forwarded to the kernel.
With utrace the kmview kernel module handles many system calls at kernel level.
I mean, if an "open" system call was sent to the kernel because the path is outside
the virtualized part of the file system, all the system calls on the same file descriptors
can be forwarded to the kernel without any request to the VMM at user level.
This is just one example of speedup, several others are possible.
Other virtualizations like user-mode linux or fakeroot-ng could use utrace to
speedup their virtualization, too.
As far as I have seen, systemtap is a wonderful tool for debugging, expecially for
kernel debugging but it has not been designed for virtualization.
Ptrace provide a standard set of features and all the implementations of VMM must be
in userland. Utrace provides the flexibility to split a VMM and move part of it to a
kernel module.
Utrace provides a unified interface to kernel modules for tracing/virtualization.
kmview can be implemented as a client of utrace or by spreading code around the kernel and
like kmview other virtualizations based on ptrace could need to move some of their
logic to the kernel to speedup their execution.
These VMMs will use utrace based modules instead of kernel patches.
renzo
On Sat, Mar 21, 2009 at 01:49:09AM -0700, Andrew Morton wrote:
> I'd be interested in seeing a bit of discussion regarding the overall value
> of utrace - it has been quite a while since it floated past.
>
> I assume that redoing ptrace to be a client of utrace _will_ happen, and
> that this is merely a cleanup exercise with no new user-visible features?
>
> The "prototype utrace-ftrace interface" seems to be more a cool toy rather
> than a serious new kernel feature (yes?)
>
> If so, what are the new killer utrace clients which would justify all these
> changes?
>
> Also, is it still the case that RH are shipping utrace? If so, for what
> reasons and what benefits are users seeing from it?
>
> And I recall that there were real problems wiring up the Feb 2007 version
> of utrace to the ARM architecture. Have those issues been resolved? Are
> any problems expected for any architectures?
next prev parent reply other threads:[~2009-03-21 14:08 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-21 1:39 [PATCH 0/3] utrace Roland McGrath
2009-03-21 1:41 ` [PATCH 1/3] signals: tracehook_notify_jctl change Roland McGrath
2009-03-21 1:41 ` [PATCH 2/3] utrace core Roland McGrath
2009-03-21 8:49 ` Andrew Morton
2009-03-21 14:08 ` Renzo Davoli [this message]
2009-03-21 14:34 ` Ingo Molnar
2009-03-21 16:37 ` Renzo Davoli
2009-03-21 16:44 ` Ingo Molnar
2009-03-23 4:34 ` Roland McGrath
2009-03-23 4:35 ` Roland McGrath
2009-03-23 10:57 ` Will Newton
2009-03-21 1:42 ` [PATCH 3/3] utrace-based ftrace "process" engine, v2 Roland McGrath
2009-03-21 7:43 ` Ingo Molnar
2009-03-21 8:39 ` Andrew Morton
2009-03-21 9:12 ` Ingo Molnar
2009-03-21 11:19 ` Andrew Morton
2009-03-21 11:51 ` Frank Ch. Eigler
2009-03-21 12:04 ` Andrew Morton
2009-03-21 12:57 ` Frank Ch. Eigler
2009-03-21 15:45 ` Ingo Molnar
2009-03-21 20:35 ` Diego Calleja
2009-03-22 12:17 ` Ingo Molnar
2009-03-21 21:34 ` Andrew Morton
2009-03-21 21:51 ` Frank Ch. Eigler
2009-03-21 22:02 ` Linus Torvalds
2009-03-21 22:20 ` Frank Ch. Eigler
2009-03-21 22:37 ` Alexey Dobriyan
2009-03-21 23:38 ` Frank Ch. Eigler
2009-03-22 10:25 ` Ingo Molnar
2009-03-23 5:33 ` Roland McGrath
2009-03-23 5:20 ` Roland McGrath
2009-03-22 12:37 ` Ingo Molnar
2009-03-23 13:48 ` Alexey Dobriyan
2009-03-23 15:14 ` Oleg Nesterov
2009-03-23 21:44 ` Theodore Tso
2009-03-30 22:18 ` Andrew Morton
2009-03-30 22:52 ` Frank Ch. Eigler
2009-03-31 9:17 ` Peter Zijlstra
2009-03-31 11:27 ` Peter Zijlstra
2009-03-31 11:38 ` Frank Ch. Eigler
2009-03-31 16:25 ` Christoph Hellwig
2009-03-31 20:54 ` Roland McGrath
2009-03-21 21:48 ` Frank Ch. Eigler
2009-03-22 12:08 ` Ingo Molnar
2009-03-22 12:53 ` Ingo Molnar
2009-03-23 20:25 ` Frank Ch. Eigler
2009-03-23 20:39 ` Linus Torvalds
2009-03-23 5:09 ` Roland McGrath
2009-03-24 5:29 ` Ananth N Mavinakayanahalli
2009-03-24 5:54 ` Andrew Morton
2009-03-24 6:10 ` Ananth N Mavinakayanahalli
2009-03-23 4:49 ` Roland McGrath
2009-03-23 6:34 ` Ingo Molnar
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=20090321140822.GE18690@cs.unibo.it \
--to=renzo@cs.unibo.it \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=utrace-devel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®