>Hence, yes I can provide an interface from the kernel to log a trace event
>with a variable length buffer, but I don't think that taking away the
statically
>defined trace points is the right thing to do. (I might have gotten this
>completely wrong, though ... My presumption about your
)7768-298183
> IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
>
> Karim Yaghmour <[EMAIL PROTECTED]> on 06/10/2000 09:16:12
>
> Please respond to Karim Yaghmour <[EMAIL PROTECTED]>
>
> To: Richard J Moore/UK/IBM@IBMGB
> cc: [
Hence, yes I can provide an interface from the kernel to log a trace event
with a variable length buffer, but I don't think that taking away the
statically
defined trace points is the right thing to do. (I might have gotten this
completely wrong, though ... My presumption about your suggestion
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
Karim
Richard J Moore/UK/IBM@IBMGB
cc: [EMAIL PROTECTED]
Subject: Re: The case for a standard kernel debugger
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified consequently.
As for "multiple exits registered per hook", if you
Yes, we looked at that and it didn't seem to provide the generality we
needed - multipe exits registered per hook, ability to arm a set of hooks
atomically, ability to prioritise dispatching order of a hook exit, MP
complient. I may be wrong but the Linux Trace Toolkit hooks like like they
were
Yes, we looked at that and it didn't seem to provide the generality we
needed - multipe exits registered per hook, ability to arm a set of hooks
atomically, ability to prioritise dispatching order of a hook exit, MP
complient. I may be wrong but the Linux Trace Toolkit hooks like like they
were
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism would have been modified consequently.
As for "multiple exits registered per hook", if you
/UK/IBM@IBMGB
cc: [EMAIL PROTECTED]
Subject: Re: The case for a standard kernel debugger
Hello Richard,
Part of your analysis is correct. The hooks were designed to take care of
static tracepoints only. That said, dynamic allocation of event IDs was
next on my list and the hooking mechanism
Thought I'd let you know that I will reply to your suggestions (which
are quite interesting by the way) ... but I need to catch up some sleep
as it's close to 7AM here in Montreal and my brains are failing ... ;)
===
Karim
[EMAIL PROTECTED] wrote:
> One big argument against RAS of any sort is that it bloats the kernel and
> not every one wants it (until they have a problem). A further argument with
> Linux is that you may have to do quite a bit of hard work to get the subset
> of RAS you need to co-exist, if it
[EMAIL PROTECTED] wrote:
One big argument against RAS of any sort is that it bloats the kernel and
not every one wants it (until they have a problem). A further argument with
Linux is that you may have to do quite a bit of hard work to get the subset
of RAS you need to co-exist, if it exists
describes would do to improve fault
isolation
and resolution.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 15, 2000 5:43 AM
To: Keith Owens
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The case for a standard kernel debugger
I think
000 10:49:50 PM
Please respond to Keith Owens <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED] (bcc: Richard J Moore/UK/IBM)
Subject: The case for a standard kernel debugger
Resend, this time with cc: torvalds.
This note puts the case for including a ker
describes would do to improve fault
isolation
and resolution.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 15, 2000 5:43 AM
To: Keith Owens
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The case for a standard kernel debugger
I think
"TRG hereby offers to SGI Corporation exclusive, unlimimited, perpetual,
transferable, licensee rights to the Linux port of the MANOS debugger
and upon TRG posting this debugger code to the Linux community, agrees
to grant to SGI the rights to maintain and create derivative works from
the MANOS
I think he did already Keith -- he said he would reject any kernel
debugger submissions.
:-)
Jeff
Keith Owens wrote:
>
> Various people have replied to my note on "The case for a standard
> kernel debugger" discussing whether or not it is a good idea. However
> o
I am porting the MANOS debugger to Linux. No changes here. Linus will
reject it for the tree, but the offer for SGI and Keith Owens to take it
over and merge it with his kdb effort is also genuine.
:-)
Jeff
Daniel Phillips wrote:
>
> Marco Colombo wrote:
> > BTW, a kernel debugger *is*
or there are consequences, it would be difficult to live without one.
-Original Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 13, 2000 5:57 PM
To: Keith Owens
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The case for a standard kernel debugger
Amen
Andi Kleen wrote:
>
> On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> > The hardest problem: how do you do the block read? Possibilities:
> >
> > - Ignore the problem, use normal block device I/O
> > - Use the real mode bios, needs V86 support
>
> And it requires a sync
On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
> The hardest problem: how do you do the block read? Possibilities:
>
> - Ignore the problem, use normal block device I/O
> - Use the real mode bios, needs V86 support
And it requires a sync before every possible crash to
Marco Colombo wrote:
> BTW, a kernel debugger *is* available. And maybe even a more powerful
> one will be if Jeff decides to port and publicly release it.
One that subject, I would *love* to take the time to see how small a
subset of Ext2 I could write to have a (mostly) non-invasive source
On Thu, 14 Sep 2000, Frederic Magniette wrote:
[...]
> In that way, I think that a kernel debugger could be a powerful coding
> tool and not only a patching tool as you say.
I don't have enough background to judge on the merits of a kernel
debugger. I simply trust Linus' feelings on the
Frederic Magniette wrote:
>
> This can be really awful if your code is called very often and then saturate the
> logs.
One trick you can pull is:
if (current->uid == )
printk(stuff);
and then exercise the offending code path as user . It
works for some things.
Marco Colombo wrote:
>
>
> 2) apply tight filters on what people produce (patches, features) not on
>how they produce. If Linus is right (and in the end I believe it),
>'debugger people' will produce low quality patches (the ones that fix
>the syntoms not the problems), and those
On Wed, 13 Sep 2000, Timur Tabi wrote:
> ** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000
> 08:49:50 +1100
>
>
> > (5) Easier for kernel beginners to learn the kernel internals. Having
> > worked on 10+ operating systems over the years, I can testify that
> >
Frederic Magniette wrote:
This can be really awful if your code is called very often and then saturate the
logs.
One trick you can pull is:
if (current-uid == )
printk(stuff);
and then exercise the offending code path as user . It
works for some things.
-
On Thu, 14 Sep 2000, Frederic Magniette wrote:
[...]
In that way, I think that a kernel debugger could be a powerful coding
tool and not only a patching tool as you say.
I don't have enough background to judge on the merits of a kernel
debugger. I simply trust Linus' feelings on the matter.
Marco Colombo wrote:
BTW, a kernel debugger *is* available. And maybe even a more powerful
one will be if Jeff decides to port and publicly release it.
One that subject, I would *love* to take the time to see how small a
subset of Ext2 I could write to have a (mostly) non-invasive source
code
On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
The hardest problem: how do you do the block read? Possibilities:
- Ignore the problem, use normal block device I/O
- Use the real mode bios, needs V86 support
And it requires a sync before every possible crash to ensure
Andi Kleen wrote:
On Thu, Sep 14, 2000 at 02:21:44PM +0200, Daniel Phillips wrote:
The hardest problem: how do you do the block read? Possibilities:
- Ignore the problem, use normal block device I/O
- Use the real mode bios, needs V86 support
And it requires a sync before every
I am porting the MANOS debugger to Linux. No changes here. Linus will
reject it for the tree, but the offer for SGI and Keith Owens to take it
over and merge it with his kdb effort is also genuine.
:-)
Jeff
Daniel Phillips wrote:
Marco Colombo wrote:
BTW, a kernel debugger *is*
I think he did already Keith -- he said he would reject any kernel
debugger submissions.
:-)
Jeff
Keith Owens wrote:
Various people have replied to my note on "The case for a standard
kernel debugger" discussing whether or not it is a good idea. However
only one person's rep
"TRG hereby offers to SGI Corporation exclusive, unlimimited, perpetual,
transferable, licensee rights to the Linux port of the MANOS debugger
and upon TRG posting this debugger code to the Linux community, agrees
to grant to SGI the rights to maintain and create derivative works from
the MANOS
** Reply to message from Keith Owens <[EMAIL PROTECTED]> on Thu, 14 Sep 2000
08:49:50 +1100
> (5) Easier for kernel beginners to learn the kernel internals. Having
> worked on 10+ operating systems over the years, I can testify that
> some form of kernel/OS tracing facility is
Amen Brother
Jeff
Keith Owens wrote:
>
> Resend, this time with cc: torvalds.
>
> This note puts the case for including a kernel debugger in the master
> tarballs. These points do not only apply to kdb, they apply to any
> kernel debugger. Comments about the perceived deficiencies of
Resend, this time with cc: torvalds.
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant
Resend, this time with cc: torvalds.
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant
Amen Brother
Jeff
Keith Owens wrote:
Resend, this time with cc: torvalds.
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
** Reply to message from Keith Owens [EMAIL PROTECTED] on Thu, 14 Sep 2000
08:49:50 +1100
(5) Easier for kernel beginners to learn the kernel internals. Having
worked on 10+ operating systems over the years, I can testify that
some form of kernel/OS tracing facility is extremely
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant here, nor are
questions about how or when
This note puts the case for including a kernel debugger in the master
tarballs. These points do not only apply to kdb, they apply to any
kernel debugger. Comments about the perceived deficiencies of kdb,
kgdb, xmon or any other debugger are not relevant here, nor are
questions about how or when
43 matches
Mail list logo
