>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 suggest
are.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)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 Kari
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 Yaghmour
mour <[EMAIL PROTECTED]>
To: 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 o
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 m
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
[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 exis
Rich 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
I think the case for the kernel debugger is better stated as the case for
RAS (Reliability, Serviceability and Availability) in the kernel, in other
words, there is a case for having the right diagnostic, reporting and
recovery tools in the right place at the right time. A kdb does not fulfil
"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 D
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 reply matter
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* avai
e 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
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 b
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 ensu
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, 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.
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 reply matters here - Linus. I ask other people to
refrain from replying to this thread until Linus has had a chance to
read my note and (if h
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 patc
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
> >
** 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
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 kd
23 matches
Mail list logo
