On Tue 2015-03-10 12:53:21, Rusty Russell wrote:
> Petr Mladek writes:
> > On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
> >> I don't think you should handle going modules at all. Rarely happens,
> >> and it should happen fast.
> >
> > I would like to handle it correctly. It would be pity to b
Petr Mladek writes:
> On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
>> I don't think you should handle going modules at all. Rarely happens,
>> and it should happen fast.
>
> I would like to handle it correctly. It would be pity to break a system
> just because of a module removal. Also the ex
On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
> Petr Mladek writes:
> > Existing live patches are removed from going modules using a notify handler.
> > There are two problems with the current implementation.
> >
> > First, new patch could still see the module in the GOING state even after
> >
Petr Mladek writes:
> Existing live patches are removed from going modules using a notify handler.
> There are two problems with the current implementation.
>
> First, new patch could still see the module in the GOING state even after
> the notifier has been called. It will try to initialize the r
On Thu, Mar 05, 2015 at 04:45:14PM +0100, Petr Mladek wrote:
> Existing live patches are removed from going modules using a notify handler.
> There are two problems with the current implementation.
>
> First, new patch could still see the module in the GOING state even after
> the notifier has bee
Existing live patches are removed from going modules using a notify handler.
There are two problems with the current implementation.
First, new patch could still see the module in the GOING state even after
the notifier has been called. It will try to initialize the related
object structures but t
6 matches
Mail list logo
