Re: [PATCH 2/3] utrace core

2009-03-21 Thread Andrew Morton
On Fri, 20 Mar 2009 18:41:40 -0700 (PDT) Roland McGrath rol...@redhat.com 
wrote:

 This adds the utrace facility, a new modular interface in the kernel for
 implementing user thread tracing and debugging.  This fits on top of the
 tracehook_* layer, so the new code is well-isolated.
 
 The new interface is in linux/utrace.h and the DocBook utrace book
 describes it.  It allows for multiple separate tracing engines to work in
 parallel without interfering with each other.  Higher-level tracing
 facilities can be implemented as loadable kernel modules using this layer.
 
 The new facility is made optional under CONFIG_UTRACE.
 When this is not enabled, no new code is added.
 It can only be enabled on machines that have all the
 prerequisites and select CONFIG_HAVE_ARCH_TRACEHOOK.
 
 In this initial version, utrace and ptrace do not play together at all.
 If ptrace is attached to a thread, the attach calls in the utrace kernel
 API return -EBUSY.  If utrace is attached to a thread, the PTRACE_ATTACH
 or PTRACE_TRACEME request will return EBUSY to userland.  The old ptrace
 code is otherwise unchanged and nothing using ptrace should be affected
 by this patch as long as utrace is not used at the same time.  In the
 future we can clean up the ptrace implementation and rework it to use
 the utrace API.

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?

Thanks.



Re: [PATCH 2/3] utrace core

2009-03-21 Thread Renzo Davoli
On Sat, Mar 21, 2009 at 03:34:57PM +0100, Ingo Molnar wrote:
 
 * Renzo Davoli re...@cs.unibo.it wrote:
 
  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. [...]
 
 Hm, i cannot find the source code. Can it be downloaded from 
 somewhere?
Sure! kmview is not included in our Debian packages yet as it relies on 
(still) non mainstream features (utrace), but the code is available on 
our view-os svn repository.

Check out:
svn co https://view-os.svn.sourceforge.net/svnroot/view-os view-os 

More specifically to browse the code/specifications:
The kmview device protocol is here:
http://wiki.virtualsquare.org/index.php/KMview_module_interface_specifications
The kernel module itself is here:
http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/kmview-kernel-module/
The VMM userland application share most of the code with
umview, the source code for both is here:
http://view-os.svn.sourceforge.net/viewvc/view-os/trunk/xmview-os/xmview/

kmview kernel module (current version) needs the following patches:
utrace
http://www.mail-archive.com/utrace-devel@redhat.com/msg00654.html
http://www.mail-archive.com/utrace-devel@redhat.com/msg00655.html
I am trying to keep everything up to date, but the whole stuff is
evolving in a quite fast way.

Everything has been released under GPLv2.

renzo