Re: [PATCH v2] mm: Introduce coredump parameter structure

[Masami Hiramatsu <mhiramat@redhat.com>]

Ingo Molnar wrote:
> * Masami Hiramatsu<mhiramat@redhat.com>  wrote:
>
>> Andrew Morton wrote:
>>> On Sat, 28 Nov 2009 23:41:19 -0500
>>> Masami Hiramatsu<mhiramat@redhat.com>   wrote:
>>>
>>>> Introduce coredump parameter data structure (struct coredump_params)
>>>> for simplifying binfmt->core_dump() arguments.
>>>>
>>>> Changes in v2:
>>>>     - Don't remove DUMP_WRITE() macro.
>>>
>>> What is the reason for this change?
>>>
>>> Please always include both the "what" and the "why" in changelog text.
>>
>> I see.
>
> I think Andrew wanted to see a longer explanation about precisely what
> we need for these tracepoints and what the various specific usecases are
> to utilize it.

Ah, OK.

>
> I.e. a basic cost/benefit analysis is needed. By looking at the patch we
> can see the cost - but you have to counter-balance that with enough
> stuff in the 'benefits' column of the equation.

Hmm, actually, this tracepoint requirement comes from the viewpoint of
administrators (not developers). Since now we have introduced many
coredump configurations (e.g. dumpable, coredump_filter, core_pattern, etc)
and some of them can be modified by users, we assume it is hard to know
what was actually dumped (or not dumped) after some problem happened on the
system. For example, a process didn't generated core, coredump doesn't have
some sections, etc. In those cases, the coredump tracepoint can help us to
know why the core file is so big or small, or not generated, by recording
all configurations for all processes on the system. That will reduce
system-administration cost.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com