> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior
> wrote:
>
> On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
>> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
>> objects.
> why?
>
I’m requesting for comments of a new feature called
> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior
> wrote:
>
> On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
>> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
>> objects.
> why?
>
I’m requesting for comments of a new feature called __ro_mostly_after_init
On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
> objects.
why?
Sebastian
On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
> objects.
why?
Sebastian
It would be good that `__ro_mostly_after_init` is marked to cpuhp state
objects. They can not be simply marked as `__ro_after_init` because they
should be writable during module_init/exit. Now that they can be read-only
except during module_init/exit
Signed-off-by: Hoeun Ryu
It would be good that `__ro_mostly_after_init` is marked to cpuhp state
objects. They can not be simply marked as `__ro_after_init` because they
should be writable during module_init/exit. Now that they can be read-only
except during module_init/exit
Signed-off-by: Hoeun Ryu
---
kernel/cpu.c |
6 matches
Mail list logo