On Wed 2018-01-31 17:09:21, Joe Lawrence wrote:
> On 01/30/2018 09:03 AM, Petr Mladek wrote:
> > On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
> >>
> >> In my experience, it was quite convenient sometimes to just "replace all
> >> binary patches the user currently has loaded with this single
On 01/30/2018 09:03 AM, Petr Mladek wrote:
> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
>>
>> In my experience, it was quite convenient sometimes to just "replace all
>> binary patches the user currently has loaded with this single one". No
>> matter what these original binary patches did
On Fri, Jan 26, 2018 at 11:23:26AM +0100, Petr Mladek wrote:
> So, we are talking about a lot of rather non-trivial code.
> IMHO, it might be easier to run just the callbacks from
> the new patch. In reality, the author should always know
> what it might be replacing and what needs to be done.
>
>
> IMHO, it might be easier to run just the callbacks from
> the new patch. In reality, the author should always know
> what it might be replacing and what needs to be done.
I agree. I don't see a good solution to the problem. Imagine a crazy
situation in which someone would like to patch the ent
On 30.01.2018 22:24, Joe Lawrence wrote:
On 01/30/2018 01:19 PM, Jason Baron wrote:
[ ... snip ... ]
Our main interest in 'atomic replace' is simply to make sure that
cumulative patches work as expected in that they 'replace' any prior
patches. We have an interest primarily in being able to app
On 01/30/2018 02:24 PM, Joe Lawrence wrote:
> On 01/30/2018 01:19 PM, Jason Baron wrote:
>> [ ... snip ... ]
>>
>> Our main interest in 'atomic replace' is simply to make sure that
>> cumulative patches work as expected in that they 'replace' any prior
>> patches. We have an interest primarily in
On 01/30/2018 01:19 PM, Jason Baron wrote:
> [ ... snip ... ]
>
> Our main interest in 'atomic replace' is simply to make sure that
> cumulative patches work as expected in that they 'replace' any prior
> patches. We have an interest primarily in being able to apply patches
> from the stable trees
On 01/30/2018 10:06 AM, Evgenii Shatokhin wrote:
> On 30.01.2018 17:03, Petr Mladek wrote:
>> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
>>> On 26.01.2018 13:23, Petr Mladek wrote:
On Fri 2018-01-19 16:10:42, Jason Baron wrote:
>
>
> On 01/19/2018 02:20 PM, Evgenii Shat
On 30.01.2018 17:03, Petr Mladek wrote:
On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
On 26.01.2018 13:23, Petr Mladek wrote:
On Fri 2018-01-19 16:10:42, Jason Baron wrote:
On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
On 12.01.2018 22:55, Jason Baron wrote:
There is one more thin
On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
> On 26.01.2018 13:23, Petr Mladek wrote:
> > On Fri 2018-01-19 16:10:42, Jason Baron wrote:
> > >
> > >
> > > On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
> > > > On 12.01.2018 22:55, Jason Baron wrote:
> > > > There is one more thing that
On 26.01.2018 13:23, Petr Mladek wrote:
On Fri 2018-01-19 16:10:42, Jason Baron wrote:
On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
On 12.01.2018 22:55, Jason Baron wrote:
There is one more thing that might need attention here. In my
experiments with this patch series, I saw that unpatch
On Fri 2018-01-19 16:10:42, Jason Baron wrote:
>
>
> On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
> > On 12.01.2018 22:55, Jason Baron wrote:
> > There is one more thing that might need attention here. In my
> > experiments with this patch series, I saw that unpatch callbacks are not
> > call
On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote:
> On 12.01.2018 22:55, Jason Baron wrote:
>> Hi,
>> While using livepatch, I found that when doing cumulative patches,
>> if a patched
>> function is completed reverted by a subsequent patch (back to its
>> original state)
>> livepatch does not r
On 12.01.2018 22:55, Jason Baron wrote:
Hi,
While using livepatch, I found that when doing cumulative patches, if a patched
function is completed reverted by a subsequent patch (back to its original
state)
livepatch does not revert the funtion to its original state. Specifically, if
patch A
On Fri 2018-01-12 14:55:13, Jason Baron wrote:
> Hi,
>
> While using livepatch, I found that when doing cumulative patches, if a
> patched
> function is completed reverted by a subsequent patch (back to its original
> state)
> livepatch does not revert the funtion to its original state. Specifi
Hi,
While using livepatch, I found that when doing cumulative patches, if a patched
function is completed reverted by a subsequent patch (back to its original
state)
livepatch does not revert the funtion to its original state. Specifically, if
patch A introduces a change to function 1, and patch
16 matches
Mail list logo
