Daniel Jacobowitz wrote:
>On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
>
>
>>Daniel-san,
>>GDB based approach seems not fit to our requirements. GDB(ptrace) based
>>functions are basically need to be done when target process is stopping.
>>From our
On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
> Daniel-san,
> GDB based approach seems not fit to our requirements. GDB(ptrace) based
> functions are basically need to be done when target process is stopping.
> From our experience, sometimes patches became to dozens to hundreds
Daniel-san, David-san,
Pannus project has two targets.
One is user-mode application live patching, and the other one is kernel
live patching.
What we posted now is user-mode application live patching function.
>If I'm right, I'm not sure why some of the bits of it were done
>separately instead
On Sun, 17 Apr 2005 14:51:43 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Takashi-san's description was not very clear, but it sounds like it's a
> patching mechanism for userspace applications - not for kernel space.
> So kprobes would not be a good fit.
I saw the presentation of this
On Sat, Apr 16, 2005 at 11:44:39PM -0700, David S. Miller wrote:
>
> Takashi-san, have you ever investigated using kprobes to
> implement this feature? It seems a perfect fit, and would
> allow support on several architectures other than just x86
> and x86_64.
>
> If kprobes does not meet your
Takashi-san, have you ever investigated using kprobes to
implement this feature? It seems a perfect fit, and would
allow support on several architectures other than just x86
and x86_64.
If kprobes does not meet your needs completely, it could
be trivially extended to do so.
I think
Takashi-san, have you ever investigated using kprobes to
implement this feature? It seems a perfect fit, and would
allow support on several architectures other than just x86
and x86_64.
If kprobes does not meet your needs completely, it could
be trivially extended to do so.
I think
On Sat, Apr 16, 2005 at 11:44:39PM -0700, David S. Miller wrote:
Takashi-san, have you ever investigated using kprobes to
implement this feature? It seems a perfect fit, and would
allow support on several architectures other than just x86
and x86_64.
If kprobes does not meet your needs
On Sun, 17 Apr 2005 14:51:43 -0400
Daniel Jacobowitz [EMAIL PROTECTED] wrote:
Takashi-san's description was not very clear, but it sounds like it's a
patching mechanism for userspace applications - not for kernel space.
So kprobes would not be a good fit.
I saw the presentation of this stuff
Daniel-san, David-san,
Pannus project has two targets.
One is user-mode application live patching, and the other one is kernel
live patching.
What we posted now is user-mode application live patching function.
If I'm right, I'm not sure why some of the bits of it were done
separately instead of
On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
Daniel-san,
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
From our experience, sometimes patches became to dozens to hundreds at
Daniel Jacobowitz wrote:
On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
Daniel-san,
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
From our experience,
Hello,
This patch add function called "Live patching" which is defined on
OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.
The live patching allows process to patch on-line (without restarting
process) on i386 and x86_64 architectures, by overwriting jump
Hello,
This patch add function called "Live patching" which is defined on
OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.
The live patching allows process to patch on-line (without restarting
process) on i386 and x86_64 architectures, by overwriting jump
14 matches
Mail list logo
