linux-um archives
 help / color / mirror / Atom feed
From: "D. Bahi" <dbahi@enterasys.com>
To: Gerd Knorr <kraxel@bytesex.org>
Cc: Jeff Dike <jdike@addtoit.com>,
	uml devel <user-mode-linux-devel@lists.sourceforge.net>
Subject: Re: [uml-devel] Re: [ann] kraxel's 2.6.8 uml patch kit
Date: Wed, 15 Sep 2004 16:59:16 -0400	[thread overview]
Message-ID: <4148AD24.1040408@enterasys.com> (raw)
In-Reply-To: <20040914123658.GB29562@bytesex>

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

actually it's worse than that in my current implementation:

static int panic_coreonpanic(struct notifier_block *self, unsigned long 
unused1,
                 void *unused2)
{
    if ( uml_coreonpanic ) {
        /* cleanup so we have less to cleanup [linux] on the host */
        /* could panic in uml_cleanup though so we need a check */
        if ( uml_exitcode++ < 1 ) {
            uml_cleanup();
        }
        /* to prevent keyboard from causing terminal to spew during dump */
        block_signals();
        abort();
    }
    return(0);
}


Gerd Knorr wrote:

>>I liked this too. Here's a pass at it if you like (attached).
>>    
>>
>
>Sorry for the delay, going over this while being busy updating my
>patches right now ...
>
>  
>
>>+static int panic_coreonpanic(struct notifier_block *self, unsigned long unused1,
>>+			     void *unused2)
>>+{
>>+	if(uml_coreonpanic){
>>+		uml_cleanup();
>>+		block_signals();
>>+		abort();
>>    
>>
>
>What is the point of doing that?  I'd just let it dump core without any
>cleanups, to get the state of the uml kernel dumped to the disk with few
>modifications as possible.  Any changes might make the analysis of the
>crash harder or even impossible.
>
>  Gerd
>
>  
>

-- 
db


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

  reply	other threads:[~2004-09-15 20:59 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-20 12:24 [uml-devel] [ann] kraxel's 2.6.8 uml patch kit Gerd Knorr
2004-08-20 13:14 ` Geert Uytterhoeven
2004-08-20 16:52   ` Gerd Knorr
2004-08-20 19:01 ` [uml-devel] " Jeff Dike
2004-08-20 21:05   ` Geert Uytterhoeven
2004-08-21 19:28     ` Gerd Knorr
2004-08-22 13:22       ` Werner Almesberger
2004-08-23 11:06         ` Gerd Knorr
2004-08-22 11:17   ` Gerd Knorr
2004-08-31  0:25     ` D. Bahi
2004-09-14 12:36       ` Gerd Knorr
2004-09-15 20:59         ` D. Bahi [this message]
2004-09-16 10:29           ` [uml-devel] [patch] core-on-panic next take ;) Gerd Knorr

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=4148AD24.1040408@enterasys.com \
    --to=dbahi@enterasys.com \
    --cc=jdike@addtoit.com \
    --cc=kraxel@bytesex.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /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