i have some bandwidth i can dedicate to writting a kernel module that provides
a command interpreter running in kernel space (think of it as the god mode
console in quake). the purpose for this would be primarily aimed at the
kernel developers so they can reach in and grab variables, dump certain
sections of memory, walk memory, dump code segments, dump processes
(including the kernel data structures for them), anything else i/you can
think of. is this a waste of time, or would that get used?
-------------------
. ~billyrose/make
Followup to: <[email protected]>
By author: Billy Rose <[email protected]>
In newsgroup: linux.dev.kernel
>
> i have some bandwidth i can dedicate to writting a kernel module that provides
> a command interpreter running in kernel space (think of it as the god mode
> console in quake). the purpose for this would be primarily aimed at the
> kernel developers so they can reach in and grab variables, dump certain
> sections of memory, walk memory, dump code segments, dump processes
> (including the kernel data structures for them), anything else i/you can
> think of. is this a waste of time, or would that get used?
>
Google(kgdb).
-hpa
Billy Rose wrote:
> i have some bandwidth i can dedicate to writting a kernel module that provides
> a command interpreter running in kernel space (think of it as the god mode
> console in quake). the purpose for this would be primarily aimed at the
> kernel developers so they can reach in and grab variables, dump certain
> sections of memory, walk memory, dump code segments, dump processes
> (including the kernel data structures for them), anything else i/you can
> think of. is this a waste of time, or would that get used?
I think it would be valuable, especially for embedded developers
when they have trouble getting user space up on a new platform.
Also, it could be something simple and solid. It's a pain to
set up a remote debug session just to poke around in the kernel.
Remote debug setup is complex and often fragile.
I'd be willing to test this if you get something running, and
give you some feedback. For me, it would be best if the module
could be statically linked.
How do you plan to handle symbolic information?
=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: [email protected]
=============================
On Wed, Mar 03, 2004 at 03:57:24AM +0000, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Billy Rose <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > i have some bandwidth i can dedicate to writting a kernel module that provides
> > a command interpreter running in kernel space (think of it as the god mode
> > console in quake). the purpose for this would be primarily aimed at the
> > kernel developers so they can reach in and grab variables, dump certain
> > sections of memory, walk memory, dump code segments, dump processes
> > (including the kernel data structures for them), anything else i/you can
> > think of. is this a waste of time, or would that get used?
> >
>
> Google(kgdb).
Or kdb for that matter.
--
Matt Mackall : http://www.selenic.com : Linux development and consulting
Billy Rose <[email protected]> writes:
> i have some bandwidth i can dedicate to writting a kernel module that provides
> a command interpreter running in kernel space (think of it as the god mode
> console in quake). the purpose for this would be primarily aimed at the
> kernel developers so they can reach in and grab variables, dump certain
> sections of memory, walk memory, dump code segments, dump processes
> (including the kernel data structures for them), anything else i/you can
> think of. is this a waste of time, or would that get used?
It sounds like you're trying to reinvent kdb, sysrq, kgdb, lcrash/crash,
gdb vmlinux /proc/vmlinux
-Andi
Hi,
> set up a remote debug session just to poke around in the kernel.
> Remote debug setup is complex and often fragile.
There is framework called "Kprobes" available, which may
be of use in the cases were remote debugging is a no-no.
After you have applied the kprobes patch, you can put probes
at different portions of the kernel and can dump registers
variables etc.
More details can be found at
http://www-124.ibm.com/linux/projects/kprobes.
Regards,
KK.
--
HomePage: http://puggy.symonds.net/~krishnakumar
On Wednesday 03 March 2004 10:12 pm, Krishnakumar. R wrote:
> Hi,
>
> > set up a remote debug session just to poke around in the kernel.
> > Remote debug setup is complex and often fragile.
>
> There is framework called "Kprobes" available, which may
> be of use in the cases were remote debugging is a no-no.
>
> After you have applied the kprobes patch, you can put probes
> at different portions of the kernel and can dump registers
> variables etc.
>
> More details can be found at
> http://www-124.ibm.com/linux/projects/kprobes.
>
>
> Regards,
> KK.
i think perhaps i need to expound upon what i have a vision of. a kernel mode
console is just that: a console designed to run in kernel mode. it could have
built in commands to allow for quick and dirty examination of stuff (anything
really, like memory dumps) and a command processor for scripted stuff, but
the true power of it comes in when you issue a command that is not internal
to the console. it could run a special debugger, an application that installs
a probe, a memory monitor, etc., etc. in short it is not a debugger per-say,
but a "god mode" console for the linux kernel. that is what i had a vision
of. the executables it would run would necessarily be compiled for that.
again, i ask is that worth the time coding it?
--
. ~billyrose/make
On Thursday 04 March 2004 07:58 pm, you wrote:
> i think perhaps i need to expound upon what i have a vision of. a kernel
> mode console is just that: a console designed to run in kernel mode. it
> could have built in commands to allow for quick and dirty examination of
> stuff (anything really, like memory dumps) and a command processor for
> scripted stuff, but the true power of it comes in when you issue a command
> that is not internal to the console. it could run a special debugger, an
> application that installs a probe, a memory monitor, etc., etc. in short it
> is not a debugger per-say, but a "god mode" console for the linux kernel.
> that is what i had a vision of. the executables it would run would
> necessarily be compiled for that. again, i ask is that worth the time
> coding it?
a kbash? ksh is taken... kash would become instantly confusing to some
english-speakers... fun for some, but others would hear it and think 'cache'
and immediately be thrown out of sync ;)
you could extend proc (or is it just sys?) that way, creating files that can
trigger events ('echo (desired range) > /proc/sh/memdump/range', 'echo 1
> /proc/sh/memdump/go' or even simply 'cat /proc/sh/memdump/out' after
inputting range) and stick with the cat/echo control... some of your
userspace shell's commands could simply be wrappers for ordinary 'echo foo
> /proc/foo' already
OTOH, someone said proc's been abused already, having it do things that aren't
its job and causing disorganization in the kernel. i dunno, that's why im not
in charge
--
Rob Couto
[email protected]
Rules for computing success:
1) Attitude is no substitute for competence.
2) Ease of use is no substitute for power.
3) Safety matters; use a static-free hammer.
--
> i think perhaps i need to expound upon what i have a vision of. a
> kernel mode console is just that: a console designed to run in
> kernel mode.
It could be quite useful for debugging heavily embedded systems where
you don't really have a 'standard' userspace.
John.