On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>
> Changelog v6:
> 1. Experimental changes -- need loads of testing
> Based on the assumption that very far TOC and LR values
> indicate the call happened through a stub and the
> stub return works
On Wed, 9 Mar 2016, Balbir Singh wrote:
>
> The previous revision was nacked by Torsten, but compared to the alternatives
> at hand I think we should test this approach. Ideally we want all the
> complexity
> of live-patching in the live-patching code and not in the patch. The other
> option
>
On 09/03/16 20:19, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>> The previous revision was nacked by Torsten, but compared to the alternatives
> I nacked it because I was confident it couldn't work. Same goes
> for this one, sorry. My good intention was
On Wed 2016-03-09 12:16:47, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote:
> > On Wed, 9 Mar 2016, Torsten Duwe wrote:
> > > was my first choice. Arguments on the stack? I thought we'll deal with
> > > them
> > > once we get there (e.g. _really_ need to patch a
On Wed, Mar 09, 2016 at 11:13:05AM +0100, Jiri Kosina wrote:
> On Wed, 9 Mar 2016, Torsten Duwe wrote:
> > was my first choice. Arguments on the stack? I thought we'll deal with them
> > once we get there (e.g. _really_ need to patch a varargs function or one
> > with a silly signature).
>
>
On Wed, 2016-03-09 at 11:03 +0100, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 10:44:23AM +0100, Petr Mladek wrote:
> > find a solution that would work transparently. I mean that adding
> > an extra hacks into selected functions in the patch might be quite
> > error prone and problems hard to
On Wed, 9 Mar 2016, Torsten Duwe wrote:
> > find a solution that would work transparently. I mean that adding
> > an extra hacks into selected functions in the patch might be quite
> > error prone and problems hard to debug. I think that we all want this
> > but I wanted to be sure :-)
>
> Full
On Wed, Mar 09, 2016 at 10:44:23AM +0100, Petr Mladek wrote:
> find a solution that would work transparently. I mean that adding
> an extra hacks into selected functions in the patch might be quite
> error prone and problems hard to debug. I think that we all want this
> but I wanted to be sure
On Wed 2016-03-09 10:19:04, Torsten Duwe wrote:
> On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
> >
> > The previous revision was nacked by Torsten, but compared to the
> > alternatives
>
> I nacked it because I was confident it couldn't work. Same goes
> for this one, sorry. My
On Wed, Mar 09, 2016 at 05:59:40PM +1100, Balbir Singh wrote:
>
> The previous revision was nacked by Torsten, but compared to the alternatives
I nacked it because I was confident it couldn't work. Same goes
for this one, sorry. My good intention was to save us all some work.
> @@ -1265,6
The previous revision was nacked by Torsten, but compared to the alternatives
at hand I think we should test this approach. Ideally we want all the complexity
of live-patching in the live-patching code and not in the patch. The other
option
is to accept v4 and document the limitation to patch
11 matches
Mail list logo
