On Fri 2015-03-06 08:54:23, Josh Poimboeuf wrote:
> On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote:
> > This brings me back to the original idea with that boolean that
> > marks the state before and after the coming notifier (module_init).
> > We could use a bitfield instead of the two
On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote:
> This brings me back to the original idea with that boolean that
> marks the state before and after the coming notifier (module_init).
> We could use a bitfield instead of the two booleans when requested.
Yeah, that would work. Though
On Fri 2015-03-06 11:20:32, Petr Mladek wrote:
> On Thu 2015-03-05 13:34:33, Josh Poimboeuf wrote:
> > On Thu, Mar 05, 2015 at 04:45:13PM +0100, Petr Mladek wrote:
> > > Existing live patches are applied to loaded modules using a notify
> > > handler.
> > > There are two problems with this approac
On Thu 2015-03-05 13:34:33, Josh Poimboeuf wrote:
> On Thu, Mar 05, 2015 at 04:45:13PM +0100, Petr Mladek wrote:
> > Existing live patches are applied to loaded modules using a notify handler.
> > There are two problems with this approach.
> >
> > First, errors from module notifiers are ignored an
On Thu, Mar 05, 2015 at 04:45:13PM +0100, Petr Mladek wrote:
> Existing live patches are applied to loaded modules using a notify handler.
> There are two problems with this approach.
>
> First, errors from module notifiers are ignored and could not stop the module
> from being loaded. But we will
Existing live patches are applied to loaded modules using a notify handler.
There are two problems with this approach.
First, errors from module notifiers are ignored and could not stop the module
from being loaded. But we will need to refuse the module when there are
semantics dependencies betwee
6 matches
Mail list logo
