[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080815122510.GF20442@elte.hu>
Date: Fri, 15 Aug 2008 14:25:10 +0200
From: Ingo Molnar <mingo@...e.hu>
To: jmerkey@...fmountaingroup.com
Cc: Pekka Enberg <penberg@...helsinki.fi>,
linux-kernel@...r.kernel.org, jason.wessel@...driver.com
Subject: Re: [PATCH 2.6.27-rc3 26/29] mdb: export task_curr
* jmerkey@...fmountaingroup.com <jmerkey@...fmountaingroup.com> wrote:
> > On Thu, Aug 14, 2008 at 9:14 AM, <jmerkey@...fmountaingroup.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@...fmountaingroup.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists