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
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 th
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 scenario
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.
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 descript
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().
>>>S
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 SCM
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
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 wrote
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 applicatio
Hello,
Chris Wedgwood wrote:
>
>
>
>>On live patching, you never need to use shared memory, just prepare
>>fixed code, and just compile it as shared ibject, that's all. pretty
>>easy and fast to replace the functions.
>>
>>
>
>it requires magic like a comp
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 mak
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 reser
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?
patc
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 y
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
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 *why*
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 tw
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: sen
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, i
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
comp
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 disrupt
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 o
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 ov
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 patche
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
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.
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 t
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* siz
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
requ
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 pa
41 matches
Mail list logo
