[lkml]   [2010]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: add utrace tree
Let me add my two euro-cents to this discussion.

Mark Wielaard <>:
> Unfortunately ptrace does all that magic already (badly). People don't
> just use it for (s)tracing syscalls, but also for tracing signals, for
> single step debugging and poking at memory, register state, for process
> jailing and virtualization (uml) through syscall emulation.
> So when they are talking about these fancy things that is because that
> is what ptrace gives them currently. And they hate it, because the
> ptrace interface is such a pain to work with. And all these things don't
> really work together. You cannot trace, emulate, debug, jail at the same
> time.
I support Mark's words. I don't use ptrace for debugging/tracing and I
have experienced severe limitations of ptrace interface.
(I have tried to post some extensions for ptrace to overcome some
constraints.... see my posts on ptrace_vm or ptrace_multi on LKML).

Oleg Nesterov, writing to Andrew Morton said:
> First of all, utrace makes other things possible. gdbstub,
> nondestructive core dump, uprobes, kmview, hopefully more. I didn't
> look at these projects closely, perhaps other people can tell more. As
> for their merge status, until utrace itself is merged it is very hard to
> develop them out of tree.

In the list above there is also kmview, which is a creature of mines.
umview and kmview are partial virtual machines, processes running
in a [uk]mview machine can have their own view for the file system,
networking support, user-id, system-name, etc.
A [uk]mview machine virtualizes just what the user need: the filesystem
or just a subtree/some subtrees or networking or define one/some
virtual devices, etc. The "view" provided by a [uk]mview machine can be
a composition of real resources (provided by the Linux kernel) and
virtual resources.

Each system call request gets hijacked to a module of [uk]mview when
it refers to a virtual resource. The request is forwarded to the kernel

umview is based on ptrace, kmview uses a kernel module based on utrace.
(umview is included in debian lenny (to sid), tutorial and manuals in

IMHO utrace is better than ptrace (or an optimized version of it):
1 - "Frank Ch. Eigler" wrote:
> At least one reason is that ptrace is single-usage-only, so for
> example you cannot concurrently debug & strace the same program.
- exactly. utrace allows multiple tracing engines, this means that kmview
machines can be nested (in a natural way, no extra code is needed for
this feature). In the same way strace/gdb can run on virtualized processes, too.
2 - kmview kernel module implements several optimizations
to minimize the number of requests forwarded to the kmview process
(the virtual machine monitor). kmview is just a module using the
utrace interface, prior attempts of optimized umview required kernel patches.
Like kmview any other service requiring process tracing can include
specific optimizations in its own kernel module.
On the other hand, all these services could use the standardized utrace
interface for their optimizations, instead asking for messy patches
to change code all around the kernel source.
3 - ptrace takes SIGSTOP/SIGCONT for its own management. Strace/gdb and
umview cannot be transparent for programs using these signals.

Oleg Nesterov talking about Ptrace said:
> Of course they can't use other interfaces, we don't have them. And
> without the new abstraction layer we will never have, I think.
I agree.

THe following list includes the execution times I got in a recent test
(make vde-2, see
plain kernel 22.7s,
kmview (no modules) 23.9s (+5.5%),
full kmview (modules loaded, all syscall virtualized) 38.5s (+70%)
optimized umview 51.0 (+124%),
umview on vanilla kernel 75.7s (+233%).

utrace can be used to speedup virtualization (at least in my case
it worked in this way).
Performance can be useful for debugging but it is a main issue for
Kmview module provides optimizations to select the system call requests
depending on the syscall number, the pathnames or the file descriptors.
Trying to add all the optimizations needed by different projects to ptrace is a
never-ending nightmare: the LKML will continue to receive patch proposals
for ptrace...
The solution is that everybody can code his/her optimized kernel/user
interface for tracing in his/her kernel module, i.e. utrace.


 \ /
  Last update: 2010-01-26 01:15    [W:0.098 / U:9.284 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site