You can use either dprobes to set up a tracepoint dynamically anywhere you
please see:
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
Or, you can use gkhi to define a hook anywhere in the kernel you please.
You can write a hook exit as a kmod to do whatever you
You can use either dprobes to set up a tracepoint dynamically anywhere you
please see:
http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes
Or, you can use gkhi to define a hook anywhere in the kernel you please.
You can write a hook exit as a kmod to do whatever you
Yes, try the O'Reilly books, especilly Linux Device Drivers by Rubini, ISBN
1-56592-292-1
Richard
Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM
Yes, try the O'Reilly books, especilly Linux Device Drivers by Rubini, ISBN
1-56592-292-1
Richard
Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM
Dprobes is one mechanism for doing what you want. It works the same way
OS/2 dynamic trace did. Another mecnahism, also available from the dprobes
web page is the GKHI (generalised kernel hooks interface). If you know you
want tracepoints in permanently assigned locations then you could code a
Dprobes is one mechanism for doing what you want. It works the same way
OS/2 dynamic trace did. Another mecnahism, also available from the dprobes
web page is the GKHI (generalised kernel hooks interface). If you know you
want tracepoints in permanently assigned locations then you could code a
I can offer the GKHI we put together to make kernel hooks easy to add an
manage. If you know which code paths you need to peek then you can write
you monitor as a kernel mod - user mod pair. The kernel mod will accumulate
the stats, the user mod will extract and report the stats. See the web
I can offer the GKHI we put together to make kernel hooks easy to add an
manage. If you know which code paths you need to peek then you can write
you monitor as a kernel mod - user mod pair. The kernel mod will accumulate
the stats, the user mod will extract and report the stats. See the web
Does linux cater of all the old 386 chip bugs - especially the memory
management oddities?
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,
Does linux cater of all the old 386 chip bugs - especially the memory
management oddities?
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd,
You can get some interesting side effects if you incease the clock speed.
I'm not saying that Linux will suffer, but I have seen problems on other
Intel based systems - it all depends on what you do with the clock
interrupt.
Increasing the seed will give a finer grained pre-emption
You can get some interesting side effects if you incease the clock speed.
I'm not saying that Linux will suffer, but I have seen problems on other
Intel based systems - it all depends on what you do with the clock
interrupt.
Increasing the seed will give a finer grained pre-emption
Stepping is Intel teminology for chip revisions - possibly other
manufacturers have used the same terminology. Intel documents the fixes,
or rather the bugs and work-arounds, for each stepping level in the
addendum to the particular processor's reference manual. Probably, I
haven't checked,
Stepping is Intel teminology for chip revisions - possibly other
manufacturers have used the same terminology. Intel documents the fixes,
or rather the bugs and work-arounds, for each stepping level in the
addendum to the particular processor's reference manual. Probably, I
haven't checked,
I agree, I've changed my mind about the use of a task gate for NMI - Intel
recommend an interrupt gate for a very good reason - NMI's are queued until
the IRET so using an interrup gate for NMI (and keeping interrupts
disabled) will guarantee that NMIs are handled serially.
I think our use of
I agree, I've changed my mind about the use of a task gate for NMI - Intel
recommend an interrupt gate for a very good reason - NMI's are queued until
the IRET so using an interrup gate for NMI (and keeping interrupts
disabled) will guarantee that NMIs are handled serially.
I think our use of
Exactly, and you wouldn't set DPL=3 for interrupt 8 since a double-fault
can only occur from ring 0..
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.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
--
No no. That's that the whole point of a gate. You make a controlled
transition to ring 0 including stack switching. There are complex
protection checking rules, however as long as the DPL of the gate
descriptor is 3 then ring 3 is allowed to make the transition to ring 0. A
stack fault in user
One option, if there's no bespoke mechanism is to use DPorbes and or Linux
Trace Toolkit to set up a trace of file system apis. You could also start
with strace.
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
One option, if there's no bespoke mechanism is to use DPorbes and or Linux
Trace Toolkit to set up a trace of file system apis. You could also start
with strace.
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
No no. That's that the whole point of a gate. You make a controlled
transition to ring 0 including stack switching. There are complex
protection checking rules, however as long as the DPL of the gate
descriptor is 3 then ring 3 is allowed to make the transition to ring 0. A
stack fault in user
Exactly, and you wouldn't set DPL=3 for interrupt 8 since a double-fault
can only occur from ring 0..
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.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
--
Yes, indeed this is the point - we should at least be able to report the
problem even if we can't recover - and we should do that in the standard
kernel. It doesn't seem right to convert a bad problem into an unfathomable
disaster, which is what a trap gate for double-fault does. If you're
You seem to be misunderstanding the point of the argument: R3 stack fault -
no problem - handled by trap gate for idt vector 12 - recovery is possible
if one wants to handle it. R0 stack fault - big problem, exception 12 is
converted to a double-fault, which is converted to a triple-fault
Which surely we can on today's x86 systems. Even back in the days of OS/2
2.0 running on a 386 with 4Mb RAM we used a taskgate for both NMI and
Double Fault. You need only a minimal stack - 1K, sufficient to save state
and restore ESP to a known point before switching back to the main TSS to
Why is double_fault serviced by a trap gate? The problem with this is that
any double-fault caused by a stack-fault, which is the usual reason,
becomes a triple-fault. And a triple-fault results in a processor reset or
shutdown making the fault damn near impossible to get any information on.
Why is double_fault serviced by a trap gate? The problem with this is that
any double-fault caused by a stack-fault, which is the usual reason,
becomes a triple-fault. And a triple-fault results in a processor reset or
shutdown making the fault damn near impossible to get any information on.
Which surely we can on today's x86 systems. Even back in the days of OS/2
2.0 running on a 386 with 4Mb RAM we used a taskgate for both NMI and
Double Fault. You need only a minimal stack - 1K, sufficient to save state
and restore ESP to a known point before switching back to the main TSS to
You seem to be misunderstanding the point of the argument: R3 stack fault -
no problem - handled by trap gate for idt vector 12 - recovery is possible
if one wants to handle it. R0 stack fault - big problem, exception 12 is
converted to a double-fault, which is converted to a triple-fault
Yes, indeed this is the point - we should at least be able to report the
problem even if we can't recover - and we should do that in the standard
kernel. It doesn't seem right to convert a bad problem into an unfathomable
disaster, which is what a trap gate for double-fault does. If you're
You can now use IBM's DProbes with Opersys' Linux Trace Toolkit to provide
a universal (dynamic) tracing capability for Linux.
It is universal because it provides a common tracing mechanism for all
executables whether in user or kernel space. It is dynamic because
tracepoints are defined and
You can now use IBM's DProbes with Opersys' Linux Trace Toolkit to provide
a universal (dynamic) tracing capability for Linux.
It is universal because it provides a common tracing mechanism for all
executables whether in user or kernel space. It is dynamic because
tracepoints are defined and
Not even Intel can spell kernal [sic] - see 486 Programmer's reference -
description of protection mechanism.
BTW one of the enhancements to the Pentium was an improvement in the
spelling of kernel. :-)
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
Please respond to Andrea Arcangeli <[EMAIL PROTECTED]>
To: Richard J Moore/UK/IBM@IBMGB
cc:
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Wed, Nov 15, 2000 at 05:14:57AM +, [EMAIL PROTECTED] wrote:
>
>
> Andrea,
>
> I am very greatful for your detailed
Andrea,
I am very greatful for your detailed analysis. I have yet to digest
everything you commented but will get back to you on all points you raise
very soon. Here are my thoughts so far:
> I think gkhi should be renamed to something like "Fast Unregistered
Kernel
> Hook Interface" to
Please respond to Andrea Arcangeli [EMAIL PROTECTED]
To: Richard J Moore/UK/IBM@IBMGB
cc:
Subject: Re: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)
On Wed, Nov 15, 2000 at 05:14:57AM +, [EMAIL PROTECTED] wrote:
Andrea,
I am very greatful for your detailed analysis. I
Andrea,
I am very greatful for your detailed analysis. I have yet to digest
everything you commented but will get back to you on all points you raise
very soon. Here are my thoughts so far:
I think gkhi should be renamed to something like "Fast Unregistered
Kernel
Hook Interface" to avoid
Not even Intel can spell kernal [sic] - see 486 Programmer's reference -
description of protection mechanism.
BTW one of the enhancements to the Pentium was an improvement in the
spelling of kernel. :-)
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
Andi Kleen wrote:
>I think using dprobes for collecting information is ok, but when you want
>to do actual actions with it (not only using it as a debugger) IMHO it
>is better to patch and recompile the kernel.
I absolutely agree. The only time I ever used this capability was to modify
a
Andi Kleen wrote:
I think using dprobes for collecting information is ok, but when you want
to do actual actions with it (not only using it as a debugger) IMHO it
is better to patch and recompile the kernel.
I absolutely agree. The only time I ever used this capability was to modify
a
Alexander Viro wrote:
> It's not a good idea, it's an obvious fact. Oh, you mean forking the
tree?
Again I find your terminology at odds with mine; what do you mean by
forking the tree? I get the impression that it's a very restrictive notion
where any functional ehancement applied as a patch
Andi Kleen wrote:
> It will just help some people who have a unrational aversion against
kernel
>recompiles and believe in vendor blessed binaries.
An interesting remark Andi, especially in the light of your note to me
regarding your use of DProbes - i.e. you'd rather use DProbes to dump out
Andi Kleen wrote:
It will just help some people who have a unrational aversion against
kernel
recompiles and believe in vendor blessed binaries.
An interesting remark Andi, especially in the light of your note to me
regarding your use of DProbes - i.e. you'd rather use DProbes to dump out
Alexander Viro wrote:
It's not a good idea, it's an obvious fact. Oh, you mean forking the
tree?
Again I find your terminology at odds with mine; what do you mean by
forking the tree? I get the impression that it's a very restrictive notion
where any functional ehancement applied as a patch
No, misunderstood.
GKHI is not implemented using dynamic probes. GKHI places in the kernel
calls to APIs in the DProbes code. Since we'ed rather have Dprobes out of
the kernel then essentially it acts as a loader after the fact, i.e. it
fixes up the DProbes API calls when the DProbe module
Matti,
>Please educate me, what does "our RAS offerings" mean here ?
>(I didn't find "RAS" at your signature-URL site, but I didn't
> poke around very much..)
RAS = Reliabilty, Availability & Serviceability = those things that are are
not mainline to an OS but add the qualities
> Right. So what you're saying is that GKHI is adding complexity to the
> kernel to make it easier for peopel to put in non-standard patches which
> exposes non-standard interfaces which will lead to kernels not supported
> by the Linux Kernel Development Community. Right?
I don't think I
> The problem with the hooks et.al. is very simple - they promote every
> bloody implementation detail to exposed API.
Surely not, having the kernel source does that. The alternative to the hook
is embed a patch in the kernel source. What proveds greater exposure to
internals: hooks of
> That being said, the real problem with the GKHI is that as Al said, it
> does expose internal kernel interfaces --- and the Linux kernel
> development community as a whole refuses to be bound by such interfaces,
> sometimes even during a stable kernel series.
I'm not sure that GKHI exposes
>> Why? I think the IBM GKHI code would be of tremendous value. It would
>
> And we already refuse to support those kernels - your point being?
>
> Making this "commonplace" is a nightmare. Go away with that.
How is so?
Richard Moore - RAS Project Lead - Linux Technology Centre
>> extensions using the GKHI would not be breaking the license agreement, I
>> don't think. There's lots of binary modules right now -- VMWare, Aureal
> sound card drivers, etc.
>
>All of which just cause large numbers of bugs to go in the bitbucket
because
>nobody can tell whose the problem
> Yes, and that's why I am opposing here: Technically you are right, but
> proposing that enterprise Linux should go this way is inviting binary
> only modules due to the lax handling of modules.
Not so sure it does. If a kernel module wants to make use of GKHI then it
will have to
1)
That being said, the real problem with the GKHI is that as Al said, it
does expose internal kernel interfaces --- and the Linux kernel
development community as a whole refuses to be bound by such interfaces,
sometimes even during a stable kernel series.
I'm not sure that GKHI exposes any
The problem with the hooks et.al. is very simple - they promote every
bloody implementation detail to exposed API.
Surely not, having the kernel source does that. The alternative to the hook
is embed a patch in the kernel source. What proveds greater exposure to
internals: hooks of
Right. So what you're saying is that GKHI is adding complexity to the
kernel to make it easier for peopel to put in non-standard patches which
exposes non-standard interfaces which will lead to kernels not supported
by the Linux Kernel Development Community. Right?
I don't think I
No, misunderstood.
GKHI is not implemented using dynamic probes. GKHI places in the kernel
calls to APIs in the DProbes code. Since we'ed rather have Dprobes out of
the kernel then essentially it acts as a loader after the fact, i.e. it
fixes up the DProbes API calls when the DProbe module
Matti,
Please educate me, what does "our RAS offerings" mean here ?
(I didn't find "RAS" at your signature-URL site, but I didn't
poke around very much..)
RAS = Reliabilty, Availability Serviceability = those things that are are
not mainline to an OS but add the qualities named
Let be clear about one thing: the GKHI make no statement about enabling
proprietary extensions and that's a common misconception. GKHI is intended
to make optional facilities easier to co-install and change. We designed it
for DProbes, and when modularised will remain a GPL opensource offering.
Let be clear about one thing: the GKHI make no statement about enabling
proprietary extensions and that's a common misconception. GKHI is intended
to make optional facilities easier to co-install and change. We designed it
for DProbes, and when modularised will remain a GPL opensource offering.
We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI)
see the IBM Linux Technology Centre's web page DProbes link:
http://oss.software.ibm.com/developerworks/opensource/linux
Some folks expressed an interest in this type of facility recently in
discussions concerning
We've just release version 0.6 of Generalised Kernel Hooks Interface (GKHI)
see the IBM Linux Technology Centre's web page DProbes link:
http://oss.software.ibm.com/developerworks/opensource/linux
Some folks expressed an interest in this type of facility recently in
discussions concerning
We have a generic way of doing this which we are about to release - called
GKHI (Generalised Kernel Hooks Interface) would you like a copy to test?
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44)
We have a generic way of doing this which we are about to release - called
GKHI (Generalised Kernel Hooks Interface) would you like a copy to test?
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44)
Andi,
Thanks for your feedback. We are looking at this now. Hopefully we will be
able to give you a response on Monday. If we don't then it's because most
of us are on holiday next week.
I'm interested in getting information on who is using DProbes and how its
being used?
Yes, an also that
Andi,
Thanks for your feedback. We are looking at this now. Hopefully we will be
able to give you a response on Monday. If we don't then it's because most
of us are on holiday next week.
I'm interested in getting information on who is using DProbes and how its
being used?
Yes, an also that
I think you need to use the smp_call_funtion service and define the
function to be a spin_until_notified function. Each other processor will
call spin_until_notified when it receives the IPI for smp_call_function.
You can do what you need, then change some global that's keeping all the
other
We've release v1.1 of DProbes - deatils and code is on the DProbes web
page.
the enhancements include:
- DProbes for kernel version 2.4.0-test7 is now available.
- Provision to invoke other debug facilities (SGI KDB, Crash Dump and
coredumps) from a probe program.
- Probe points can now be
We've release v1.1 of DProbes - deatils and code is on the DProbes web
page.
the enhancements include:
- DProbes for kernel version 2.4.0-test7 is now available.
- Provision to invoke other debug facilities (SGI KDB, Crash Dump and
coredumps) from a probe program.
- Probe points can now be
I think you need to use the smp_call_funtion service and define the
function to be a spin_until_notified function. Each other processor will
call spin_until_notified when it receives the IPI for smp_call_function.
You can do what you need, then change some global that's keeping all the
other
Karim,
I've been back through an initial evaluation we did for LTT, back in May.
One of the feature we highlighted we'd like to see was an ability to
specify custom formatting templates. Our original OS/2 trace facility
allowed the user to generate formatting templates which would specify
Karim,
I've been back through an initial evaluation we did for LTT, back in May.
One of the feature we highlighted we'd like to see was an ability to
specify custom formatting templates. Our original OS/2 trace facility
allowed the user to generate formatting templates which would specify
>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
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
Completely agree - co-operation+integration is the order of the day. They
other thing I didn't mention was that the GKHI was substantially coded
before we discovered your hook capability. Part of the GKHI is also to
allow hooks to be dynamicaly defined i.e. to allow kernel modules to
declare
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
Completely agree - co-operation+integration is the order of the day. They
other thing I didn't mention was that the GKHI was substantially coded
before we discovered your hook capability. Part of the GKHI is also to
allow hooks to be dynamicaly defined i.e. to allow kernel modules to
declare
Daniel,
This is very valuable - thanks for makeing the effort.
You could enhance you document greatly if you provided a few diagrams to
illustrate the structure, especially the example file system. I'd suggest
converting the document to HTML or XML.
Also, I'd like to understand how the
Daniel,
This is very valuable - thanks for makeing the effort.
You could enhance you document greatly if you provided a few diagrams to
illustrate the structure, especially the example file system. I'd suggest
converting the document to HTML or XML.
Also, I'd like to understand how the
What you're seeing is a tripple fault. I don't know why this is happening,
but usually it has something to do with the double-fault mechanism being
damaged (or not set-up) when a double-fault occurs. You mentiuon 386 - I
rememeber in OS/2 we have many work-arounds for Intel processor errata -
What you're seeing is a tripple fault. I don't know why this is happening,
but usually it has something to do with the double-fault mechanism being
damaged (or not set-up) when a double-fault occurs. You mentiuon 386 - I
rememeber in OS/2 we have many work-arounds for Intel processor errata -
Yes we (IBM Linux Technology Center RAS Team) are. If you have
ideas/concerns/requirements please make them known. We are at the point of
deciding what to attack. We have other dumping technologies on other OSs we
could model a Linux enhancement on. There are many things we'd like to see
Yes we (IBM Linux Technology Center RAS Team) are. If you have
ideas/concerns/requirements please make them known. We are at the point of
deciding what to attack. We have other dumping technologies on other OSs we
could model a Linux enhancement on. There are many things we'd like to see
I wouldn't have expected a reset to be done on shutdown -r since that
doesn't force POST to run. My guess is that we go directly to the BIOS to
read the bootstrap (INT 19 is it??)
Richard Moore - RAS Project Lead - Linux Technology Centre.
I wouldn't have expected a reset to be done on shutdown -r since that
doesn't force POST to run. My guess is that we go directly to the BIOS to
read the bootstrap (INT 19 is it??)
Richard Moore - RAS Project Lead - Linux Technology Centre.
The comparison is was making was with OS/2, not MVS, because:
1) all too often MVS is cited as being the paradigm for RAS when infact
there are special architectural features, as you've pointed out, that might
detract from a generalised comparison.
2) OS/2 is an x86 based OS so has the
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
The comparison is was making was with OS/2, not MVS, because:
1) all too often MVS is cited as being the paradigm for RAS when infact
there are special architectural features, as you've pointed out, that might
detract from a generalised comparison.
2) OS/2 is an x86 based OS so has the
90 matches
Mail list logo
