On Sun, Nov 12, 2000 at 11:27:26PM +0000, [EMAIL PROTECTED] wrote:
>
>
>
> 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
> some info from the kernel than recompile it with printks.
When I wrote it I was still misunderstanding GKHI's nature (I was assuming
that it worked on top of dprobes, not under it -- I should have read the
source before commenting, my bad)
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 don't have an aversion to recompiling the kernel - it's great fun - I
> love watching all the meeages go by, waiting with bated breath for a
> compile error, which never seems to happen. Just like watching the National
> Lottery, waiting for your own numbers to come up.
>
> To be a little more serious, it's not recompilation that's a problem, its
> re-working a set of (non-standard) patches together. I'm not that excited
> by that - I'd rather develop new code than rework old. Anyway for a couple
> of example scenarios see the response I made to Michael Rothwell. And by
> the way, I absolutely agree with your approach to kernel problem solving -
> but wouldn't it be a help if you didn't have to put a large or even
> moderate effort into working the DProbes patch into some hot-off-the-press
> version of the kernel?
As far as I can see GKHI is overkill for dprobes alone, the existing
notifier lists would be sufficient because dprobes does not hook into any
performance critical paths.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
