From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MMSSz-000323-I0
	for qemu-devel@nongnu.org; Thu, 02 Jul 2009 16:01:09 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MMSSy-00031p-1m
	for qemu-devel@nongnu.org; Thu, 02 Jul 2009 16:01:09 -0400
Received: from [199.232.76.173] (port=60571 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MMSSx-00031l-VA
	for qemu-devel@nongnu.org; Thu, 02 Jul 2009 16:01:07 -0400
Received: from naru.obs2.net ([84.20.150.76]:41441)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <nchip@kos.to>) id 1MMSSx-0002Po-B1
	for qemu-devel@nongnu.org; Thu, 02 Jul 2009 16:01:07 -0400
Date: Thu, 2 Jul 2009 23:01:03 +0300
From: Riku Voipio <riku.voipio@iki.fi>
Subject: Re: [Qemu-devel] [PATCH 3/5] linux-user: do not avoid dumping of
	qemu itself
Message-ID: <20090702200102.GA7219@kos.to>
References: <cover.1246370192.git.riku.voipio@iki.fi>
	<200907020032.00212.paul@codesourcery.com>
	<20090702021921.GB18372@shareable.org>
	<200907021419.30327.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200907021419.30327.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, Arnaud Patard <arnaud.patard@rtp-net.org>

On Thu, Jul 02, 2009 at 02:19:29PM +0100, Paul Brook wrote:
> > > [1] A host core dump may be useful for debugging qemu itself, but that's
> > > a fairly specialized corner case, and not necessarily something we want
> > > to be exposing to users.

> > It would make sense to set RLIMIT_CORE to zero very early in
> > qemu-user, and then someone debugging qemu-user can easily change
> > RLIMIT_CORE from gdb while it is running.

> Sounds reasonable, as long as you're careful to avoid breaking guest 
> applications that call {get,set}rlimit(RLIMIT_CORE).

The host process coredump is still not very useful, as kernel creates it
only after we come out of our signal handler? Also, I don't think there
is any real world application that would behave unexpectedly if one
of it's child processes dies without the coredump bit being set...

For now, I'll drop this patch and ask pulling the rest in.