Ralf Baechle wrote:
I'd try a shared library based approach for on the fly updates.
The version that I've seen imposed requirements on the application for
this to work properly.
There are tradeoffs either way.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Rik van Riel wrote:
On Wed, 20 Apr 2005, Takashi Ikebe wrote:
Well, as many said Live patching is very historical & authoritative
function on especially carrier, telecom vendor.
If linux want to be adopted on mission critical world, this function is
esseintial.
Yes, if you want to use Linux in
On Mon, Apr 18, 2005 at 02:25:06AM -0700, Chris Wedgwood wrote:
> > The call switching folks have been doing live patching at least
> > since I worked on it, over 25 years ago. This is not just
> > marketing.
>
> That still doesn't explain *why* live patching is needed.
The more optimization a
On Wed, 20 Apr 2005, Takashi Ikebe wrote:
> Well, as many said Live patching is very historical & authoritative
> function on especially carrier, telecom vendor.
> If linux want to be adopted on mission critical world, this function is
> esseintial.
Yes, if you want to use Linux in those
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote:
> Only for AF_UNIX..
I'm sure that means AF_UNIX is restricted for the socket you use to
pass the file descriptors, not a restriction on the file descriptors
themselves. I don't see why the kernel would care what the
descriptors
Chris Wedgwood wrote:
> On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
>
>
>>hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
>>AF_UNIX can not use as inter-nodes communication.
>
>
> You can send file descriptors (the actually file
In article <[EMAIL PROTECTED]>,
Takashi Ikebe <[EMAIL PROTECTED]> wrote:
>Chris Wedgwood wrote:
>> On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:>
>>
>>>To takeover the application status, connection type
>>>communications(SOCK_STREAM) are need to be disconnected by close().
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
> hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
> AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over
Chris Wedgwood wrote:
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:>
To takeover the application status, connection type
communications(SOCK_STREAM) are need to be disconnected by close().
Same network port is not allowed to bind by multiple processes
AF_UNIX socket with
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
> I think basic assumption between us and you is not match...
No, I think at a high-level they do.
> Our assumption, the live patching is not for debug, but for the real
> operation method to fix very very important process which
Hi,
I think basic assumption between us and you is not match..
Our assumption, the live patching is not for debug, but for the real
operation method to fix very very important process which can not stop.
Live patchin fix the important process's bug without disrupting process.
Chris Wedgwood
Hi,
I think basic assumption between us and you is not match..
Our assumption, the live patching is not for debug, but for the real
operation method to fix very very important process which can not stop.
Live patchin fix the important process's bug without disrupting process.
Chris Wedgwood
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
I think basic assumption between us and you is not match...
No, I think at a high-level they do.
Our assumption, the live patching is not for debug, but for the real
operation method to fix very very important process which can
Chris Wedgwood wrote:
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
To takeover the application status, connection type
communications(SOCK_STREAM) are need to be disconnected by close().
Same network port is not allowed to bind by multiple processes
AF_UNIX socket with
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over a
In article [EMAIL PROTECTED],
Takashi Ikebe [EMAIL PROTECTED] wrote:
Chris Wedgwood wrote:
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
To takeover the application status, connection type
communications(SOCK_STREAM) are need to be disconnected by close().
Same network port
Chris Wedgwood wrote:
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote:
Only for AF_UNIX..
I'm sure that means AF_UNIX is restricted for the socket you use to
pass the file descriptors, not a restriction on the file descriptors
themselves. I don't see why the kernel would care what the
descriptors are.
On Wed, 20 Apr 2005, Takashi Ikebe wrote:
Well, as many said Live patching is very historical authoritative
function on especially carrier, telecom vendor.
If linux want to be adopted on mission critical world, this function is
esseintial.
Yes, if you want to use Linux in those scenarios
On Mon, Apr 18, 2005 at 02:25:06AM -0700, Chris Wedgwood wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain *why* live patching is needed.
The more optimization a modern
Rik van Riel wrote:
On Wed, 20 Apr 2005, Takashi Ikebe wrote:
Well, as many said Live patching is very historical authoritative
function on especially carrier, telecom vendor.
If linux want to be adopted on mission critical world, this function is
esseintial.
Yes, if you want to use Linux in
Ralf Baechle wrote:
I'd try a shared library based approach for on the fly updates.
The version that I've seen imposed requirements on the application for
this to work properly.
There are tradeoffs either way.
Chris
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote:
> Well, Live patching is just a patch, so I think the developer of
> patch should know the original source code well.
In which case they could fix the application.
> Well, as you said some application can do that, but some
Takashi Ikebe wrote:
>Sorry, I may mistake the point,
>Chris Wedgwood wrote:
>
>
>>that would also be a problem for live patching too, if you have bad
>>state, you have bad state --- live patching doesn't change that
>>
>>
>What I want to say is takeover may
Takashi Ikebe wrote:
Sorry, I may mistake the point,
Chris Wedgwood wrote:
that would also be a problem for live patching too, if you have bad
state, you have bad state --- live patching doesn't change that
What I want to say is takeover may makes memory
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote:
Well, Live patching is just a patch, so I think the developer of
patch should know the original source code well.
In which case they could fix the application.
Well, as you said some application can do that, but some application
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
> What I want to say is takeover may makes memory unstable, because
> there are extra operations to reserve current (unstable) status to
> memory.
mmap is coherent between processes
> Live patching never force target process to
Sorry, I may mistake the point,
Chris Wedgwood wrote:
>>For me, is seems very dangerous to estimate the primary copy is not
>>broken through status takeover..
>>
>>
>
>that would also be a problem for live patching too, if you have bad
>state, you have bad state ---
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
> this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
Rik van Riel wrote:
>On Mon, 18 Apr 2005, Takashi Ikebe wrote:
>
>
>
>>I believe process status copy consume more time, may be below sequences are
>>needed;
>>- Stop the service on ACT-process.
>>- Copy on memory/on transaction status to shared memory.
>>
>>
> That still doesn't explain *why* live patching is needed.
True enough.
When a requirement is based in 30 years of tradition and practice, it
takes work to to back it up to the essentials that would distinguish
accurately between adequate and inadequate alternatives. And that I
presume is what
On Mon, 18 Apr 2005, Takashi Ikebe wrote:
> I believe process status copy consume more time, may be below sequences are
> needed;
> - Stop the service on ACT-process.
> - Copy on memory/on transaction status to shared memory.
No need for this, the process could ALWAYS store its
status in a
Hello,
Rik van Riel wrote:
On Mon, 18 Apr 2005, Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain
On Mon, 18 Apr 2005, Chris Wedgwood wrote:
> On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
>
> > The call switching folks have been doing live patching at least
> > since I worked on it, over 25 years ago. This is not just
> > marketing.
>
> That still doesn't explain *why* live
Takashi Ikebe <[EMAIL PROTECTED]> wrote:
> systr_pmem_read() and systr_pmem_write() just calls ptrace
> PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
> process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
> The call switching folks have been doing live patching at least
> since I worked on it, over 25 years ago. This is not just
> marketing.
That still doesn't explain *why* live patching is needed.
-
To unsubscribe from this list:
Chris wrote:
> Linux doesn't guarantee you'll get scheduled
> (strictly speaking) in n milliseconds usually.
The general case load doesn't apply here. Those doing call switching
know what they have running, and know that it won't give the scheduler
any opportunities to not run what must be run,
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote:
> I can only think of one other system that might benefit from live
> updates, and that is set top boxes, so bugs can be fixed without the
> user knowing.
hardly mission critical and usually don't have the resources to do
Chris Friesen wrote:
> Chris Wedgwood wrote:
>
>> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
>>
>>
>>> From our experience, sometimes patches became to dozens to hundreds
>>> at one patching, and in this case GDB based approach cause target
>>> process's availability descent.
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote:
> As you said, if we can migrate the data to new process without
> stopping service, it is OK, but the real applications need to
> takeover data very much(sometimes it's over gigabytedepends on
> service, and causes service
I'm sorry, I can not catch the point well,
but what I want to say is, we do not want stop the service due to bug fix.
As you said, if we can migrate the data to new process without stopping
service, it is OK, but the real applications need to takeover data very
much(sometimes it's
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote:
> The software does not allow to stops over 100 milliseconds at worst
> case.
Out of interest, how do you ensure the process doesn't stop for that
long right now? Linux doesn't guarantee you'll get scheduled
(strictly speaking) in n
For example, please think about telephone switching software.
The software does not allow to stops over 100 milliseconds at worst
case.(this depends on how many customers are using, the more customers
are using, the allowable stopping time goes to shorter.)
And the system is required
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote:
> In the telecom space it's quite common to want to modify multiple
> running binaries with as little downtime as possible.
OK
> (Beyond a threshold it becomes FCC-reportable in the US, and
> everyone wants to avoid that...)
That's
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.
could you perhaps explain some *real* *world*
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> From our experience, sometimes patches became to dozens to hundreds
> at one patching, and in this case GDB based approach cause target
> process's availability descent.
i don't really buy that it can't be done or you complex
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.
i don't really buy that it can't be done or you complex patches
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.
could you perhaps explain some *real* *world*
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote:
In the telecom space it's quite common to want to modify multiple
running binaries with as little downtime as possible.
OK
(Beyond a threshold it becomes FCC-reportable in the US, and
everyone wants to avoid that...)
That's
For example, please think about telephone switching software.
The software does not allow to stops over 100 milliseconds at worst
case.(this depends on how many customers are using, the more customers
are using, the allowable stopping time goes to shorter.)
And the system is required
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote:
The software does not allow to stops over 100 milliseconds at worst
case.
Out of interest, how do you ensure the process doesn't stop for that
long right now? Linux doesn't guarantee you'll get scheduled
(strictly speaking) in n
I'm sorry, I can not catch the point well,
but what I want to say is, we do not want stop the service due to bug fix.
As you said, if we can migrate the data to new process without stopping
service, it is OK, but the real applications need to takeover data very
much(sometimes it's
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote:
As you said, if we can migrate the data to new process without
stopping service, it is OK, but the real applications need to
takeover data very much(sometimes it's over gigabytedepends on
service, and causes service
Chris Friesen wrote:
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.
could you
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote:
I can only think of one other system that might benefit from live
updates, and that is set top boxes, so bugs can be fixed without the
user knowing.
hardly mission critical and usually don't have the resources to do
Chris wrote:
Linux doesn't guarantee you'll get scheduled
(strictly speaking) in n milliseconds usually.
The general case load doesn't apply here. Those doing call switching
know what they have running, and know that it won't give the scheduler
any opportunities to not run what must be run, in
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain *why* live patching is needed.
-
To unsubscribe from this list: send
Takashi Ikebe [EMAIL PROTECTED] wrote:
systr_pmem_read() and systr_pmem_write() just calls ptrace
PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target
process whenever patch modules is loading
You'll have to do that anyway, since you'll need to atomically store two
On Mon, 18 Apr 2005, Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain *why* live patching
Hello,
Rik van Riel wrote:
On Mon, 18 Apr 2005, Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote:
The call switching folks have been doing live patching at least
since I worked on it, over 25 years ago. This is not just
marketing.
That still doesn't explain
On Mon, 18 Apr 2005, Takashi Ikebe wrote:
I believe process status copy consume more time, may be below sequences are
needed;
- Stop the service on ACT-process.
- Copy on memory/on transaction status to shared memory.
No need for this, the process could ALWAYS store its
status in a shared
That still doesn't explain *why* live patching is needed.
True enough.
When a requirement is based in 30 years of tradition and practice, it
takes work to to back it up to the essentials that would distinguish
accurately between adequate and inadequate alternatives. And that I
presume is what
Rik van Riel wrote:
On Mon, 18 Apr 2005, Takashi Ikebe wrote:
I believe process status copy consume more time, may be below sequences are
needed;
- Stop the service on ACT-process.
- Copy on memory/on transaction status to shared memory.
No need
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote:
this makes software developer crazy
are you serious? how is live patching of .text easier than some of
the other suggestions which all are more or less sane and things like
gdb, oprofile, etc. will deal with w/o problems?
Sorry, I may mistake the point,
Chris Wedgwood wrote:
For me, is seems very dangerous to estimate the primary copy is not
broken through status takeover..
that would also be a problem for live patching too, if you have bad
state, you have bad state --- live
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote:
What I want to say is takeover may makes memory unstable, because
there are extra operations to reserve current (unstable) status to
memory.
mmap is coherent between processes
Live patching never force target process to reserve
Davide Libenzi wrote:
>On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
>
>
>
>>On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
>>
>>
>>>GDB based approach seems not fit to our requirements. GDB(ptrace) based
>>>functions are
On Mon, 18 Apr 2005 00:42:23 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based
> > functions are basically need to be done when target process is
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based
> > functions are basically need to be done when target process is stopping.
> > In addition to
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based
> > functions are basically need to be done when target process is stopping.
> > In addition to
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> GDB based approach seems not fit to our requirements. GDB(ptrace) based
> functions are basically need to be done when target process is stopping.
> In addition to that current PTRACE_PEEK/POKE* allows us to copy only a
> *word*
Hello,
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
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.
I;m curious as to what people decided this was a necessary
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
> 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.
I;m curious as to what people decided this was a necessary
requirement.
> The live
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
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.
I;m curious as to what people decided this was a necessary
requirement.
The live
Hello,
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
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.
I;m curious as to what people decided this was a necessary
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
In addition to that current PTRACE_PEEK/POKE* allows us to copy only a
*word*
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
In addition to that
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
In addition to that
On Mon, 18 Apr 2005 00:42:23 -0400
Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
In
Davide Libenzi wrote:
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be
80 matches
Mail list logo
