[lkml]   [2000]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [ANNOUNCE] Generalised Kernel Hooks Interface (GKHI)

> 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 more interfaces than embedding a patch
directly into the kernel would.

It has the potential to to make patches easier to re-work for different
kernel versions, and to enable development maintence and fixing of the
patch to be done independently of a kernel build. And it also has the
potential of helping with co-existence. If for example the RAS community
could agree on a number of hooks (I'm thinking here of crash dump, trace,
dprobes and maybe KDB as well) then you'd probably find a good may on them
using then same hooks. The modifications to the kernel would be minimal and
the user would be left an easy means of installing a co-existing subset of
the offerings supported by hooks.

An example: DProbes is down to three hooks - that's three lines of code in
the kernel + three lines in ksyms.c

Patching DProbes onto any custom kernel is a doddle.

Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.045 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site