Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Takashi Ikebe]

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 patching doesn't change that
>  
>
What I want to say is takeover may makes memory unstable, because there
are extra operations to reserve current (unstable) status to memory.
Live patching never force target process to reserve status to memory. Is
this make sense?

>>Some process use critical resources such as fixed network listen
>>port can not speed up so.
>>    
>>
>
>hand the fd off to another process
>  
>
I think the point is how long does it takes to hand the fd off to
another process.(means how long time the network port is unavailable??)

>>More importantly, the only process who prepare to use this mechanism
>>only allows to use quick process takeover.
>>    
>>
>
>no, i can mmap state or similar, hand fd's off and switch to another
>process in a context switch... hot patching i bet is going to be
>slower
>
>how about you show up some code that needs this?
>  
>
>>This cause software development difficult.
>>    
>>
>
>i honestly doubt in most cases you can hand live patch faster and more
>easily than having the application sensibly written and passing it off
>
>please, prove me wrong, show us some code
>  
>
Please see and try http://pannus.sourceforge.net
There includes commands and some samples.
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.

-- 
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi@xxxxxxxxxxxxx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/