All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Dike <jdike@karaya.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	Julian Seward <jseward@acm.org>
Subject: Re: [PATCH] Allow UML kernel to run in a separate host address space
Date: Sun, 29 Dec 2002 00:12:49 -0500	[thread overview]
Message-ID: <200212290512.AAA05601@ccure.karaya.com> (raw)
In-Reply-To: Your message of "28 Dec 2002 20:03:41 PST." <1041134621.17117.3.camel@ixodes.goop.org>

jeremy@goop.org said:
> I suspect Valgrind could use this too at some point.  There hasn't
> been much discussion about it yet, but I think Valgrind may well move
> towards a more complete virtualization in a later round of
> development, and isolating the virtual virtual address space from the
> Valgrind's real virtual address space would be very useful.  (Jeff
> suggested the idea of merging Valgrind and UML at some level, which
> does raise some interesting possibilities.) 

Yes, valgrind already has a pseudo-scheduler, a psuedo-threads library, it
delivers signals by hand, and it wants to run its client in a separate
thread so it can get out of the business of being an LD_PRELOAD shared
library.

This is all stuff that UML has, that UML does right (/me crosses fingers),
and that is usable by Valgrind (and anything else that's interested) with 
some repackaging of UML as a library.

Replacing Valgrind's signal delivery with UML's is a no-brainer.  Replacing
its scheduler and threads library would involve it creating UML processes
by calling UML's do_fork().  Valgrind would need to provide the low-level
switch_to, I think.  There are probably other things that Valgrind would
need to provide, but I see no reason this wouldn't work.

				Jeff


  reply	other threads:[~2002-12-29  5:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-28 15:47 [PATCH] Allow UML kernel to run in a separate host address space Jeff Dike
2002-12-28 19:34 ` Linus Torvalds
2002-12-28 20:24   ` Jeff Dike
2002-12-28 20:50     ` Linus Torvalds
2002-12-28 23:37       ` Jeff Dike
2002-12-29  4:13         ` Linus Torvalds
2002-12-29  5:12           ` Jeff Dike
2002-12-29  0:59       ` Daniel Jacobowitz
2002-12-29  4:03     ` Jeremy Fitzhardinge
2002-12-29  5:12       ` Jeff Dike [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-17 23:24 Jeff Dike

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=200212290512.AAA05601@ccure.karaya.com \
    --to=jdike@karaya.com \
    --cc=jeremy@goop.org \
    --cc=jseward@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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.