All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jakob Østergaard" <jakob@unthought.net>
To: Michael Sinz <msinz@wgate.com>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Core dump file control
Date: Fri, 15 Feb 2002 12:40:36 +0100	[thread overview]
Message-ID: <20020215124036.C23673@unthought.net> (raw)
In-Reply-To: <3C6BE18F.7B849129@wgate.com>
In-Reply-To: <3C6BE18F.7B849129@wgate.com>; from msinz@wgate.com on Thu, Feb 14, 2002 at 11:10:55AM -0500

On Thu, Feb 14, 2002 at 11:10:55AM -0500, Michael Sinz wrote:
> I have, for a long time, wished that Linux had a way to specify where
> core dumps are stored and what the name of the core dump is.  Now that
> I have been building large linux clusters with many diskless nodes,
> this need has become even more important.
...

I just wanted to throw in my 0.02 Euro on this one:

I have not yet tested your patch yet - but this functionality is *very*
important to my company as well.

Anyone developing applications with multiple processes will benefit
significantly from having core files named differnetly than just "core".

A patch was included in the kernel some time ago, to allow the appending of the
PID - however, this is not really good enough. It's better than nothing, but
it's not good.

What I want is "core.[process name]" eventually with a ".[pid]" appended.  A
flexible scheme like your patch implements is very nice.   Actually having
the core files in CWD is fine for me - I mainly care about the file name.

Furthermore, the patch that went in earlier is *horrible* code. Let me give a
few examples:

...
        char corename[6+sizeof(current->comm)+10];
...
        memcpy(corename,"core.", 5);
        corename[4] = '\0';
...
        if (core_uses_pid || atomic_read(&current->mm->mm_users) != 1)
                sprintf(&corename[4], ".%d", current->pid);


Enough said.

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  reply	other threads:[~2002-02-15 11:41 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-14 16:10 [PATCH] Core dump file control Michael Sinz
2002-02-15 11:40 ` Jakob Østergaard [this message]
2002-02-15 11:44   ` Martin Dalecki
2002-02-15 12:11     ` Michael Sinz
2002-02-15 12:13     ` Jakob Østergaard
2002-02-15 12:22       ` Martin Dalecki
2002-02-15 12:32         ` Jakob Østergaard
2002-02-15 12:55         ` Michael Sinz
2002-02-15 12:06   ` Michael Sinz
     [not found] <3C6BE18F.7B849129@wgate.com.suse.lists.linux.kernel>
2002-02-14 16:37 ` Andi Kleen
     [not found] ` <363c044a047f1f07d2@[192.168.1.4]>
2002-02-14 17:09   ` Michael Sinz
     [not found] <361c88b8047e6c07d2@[192.168.1.4]>
2002-02-14 17:53 ` Michael Sinz
  -- strict thread matches above, loose matches on Subject: below --
2002-02-15 17:57 Michael Sinz
2002-02-15 19:07 ` Michael Sinz
2002-02-16 17:37 ` Horst von Brand
2002-02-17 14:36   ` Michael Sinz

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=20020215124036.C23673@unthought.net \
    --to=jakob@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msinz@wgate.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.