>> *
jmerkey@wolfmountaingroup.com <jmerkey@wolfmountaingroup.com> wrote:
>>
>>> >
>>> > *
jmerkey@wolfmountaingroup.com <jmerkey@wolfmountaingroup.com>
>>> wrote:
>>> >
>>> >> > On Thu, Aug 14, 2008 at 9:14 AM, <jmerkey@wolfmountaingroup.com>
>>> >> wrote:
>>> >> >> export the task_curr function to the module based kernel debugger
>>> to
>>> >> >> enable
>>> >> >> process back tracing and state display.
>>> >> >>
>>> >> >> Signed-off-by: Jeffrey Vernon Merkey
>>> (
jmerkey@wolfmountaingroup.com)
>>> >> >>
>>> >> >> --- a/kernel/sched.c 2008-08-13 14:22:32.000000000 -0600
>>> >> >> +++ b/kernel/sched.c 2008-08-13 11:56:03.000000000 -0600
>>> >> >> @@ -1736,6 +1736,9 @@
>>> >> >> {
>>> >> >> return cpu_curr(task_cpu(p)) == p;
>>> >> >> }
>>> >> >> +#if defined(CONFIG_MDB_MODULE)
>>> >> >> +EXPORT_SYMBOL_GPL(task_curr);
>>> >> >> +#endif
>>> >> >
>>> >> > We usually don't export symbols conditionally, especially in core
>>> >> kernel
>>> >> > code.
>>> >> >
>>> >>
>>> >> Well,then please suggest how a kernel debugger can be module based
>>> and
>>> >> still be able to get this information some other way that's generic
>>> >> and minimal impact.
>>> >
>>> > FYI, there's a built-in kernel debugger in the upstream kernel
>>> already:
>>> > kernel/kgdb.c - and it does not need that export.
>>> >
>>> > So if you are interested in kernel debuggers i'd suggest to work with
>>> > the KGDB folks to extend it with whatever feature-set is missing.
>>> >
>>> > They are friendly, very easy to work with and are open to the
>>> > thousands-of-years-old scientific method of not duplicating effort,
>>> > working together, going forward gradually, etc.
>>> >
>>> > Ingo
>>> >
>>>
>>> Sorry, but I have my own path and direction, [...]
>>
>> doing things alone is your unalienable personal right, and since thus
>> you apparently didnt intend your patch to be included in the Linux
>> kernel that's as far as my interest in this as a maintainer goes.
>>
>> Thanks,
>>
>> Ingo
>>
