On Fri, Dec 04, 2020 at 01:20:00AM +0100, Frederic Weisbecker wrote:
> On Wed, Dec 02, 2020 at 03:38:42PM -0300, Marcelo Tosatti wrote:
> > +Usage
> > +=====
> > +``PR_TASK_ISOLATION_FEATURES``:
> > + Returns the supported features. Features are defined
> > + at include/uapi/linux/isolation.h.
> > +
> > + Usage::
> > +
> > + prctl(PR_TASK_ISOLATION_FEATURES, ifeat, 0, 0, 0);
> > +
> > + The 'ifeat' argument is a pointer to a struct isolation_features:
> > +
> > + struct isolation_features {
> > + __u32 flags;
> > + __u32 pad[3];
> > + };
> > +
> > + Where flags contains bit sets for the features the kernel supports.
> > +
> > + FIXME: describe error codes
> > +
> > +``PR_TASK_ISOLATION_SET``:
> > + Enables task isolation mode. The type of task isolation is specified
> > + via
> > +
> > + struct isolation_control {
> > + __u32 flags;
> > + __u32 pad[15];
> > + };
> > +
> > +``PR_TASK_ISOLATION_GET``:
> > + Retrieves the currently configured task isolation mode and
> > + parameters.
>
> So, I guess we can think of two kinds of calls here:
>
> * Modes, or isolation states: signal on disallowed kernel entry, arrange for not taking
> some IPIs toward delayed processing, etc...
>
> For such "mode" it makes sense to have set() and get(), because the mode can be turned
> on and off.
>
> * Oneshot requests: quiescing (eg: vmstat), flush some pending events.
>
> For that it makes no sense to have a get().
>
>
> I would rather decouple the above with, for modes:
>
> PR_TASK_ISOLATION_SET
> PR_TASK_ISOLATION_GET
>
> And for oneshot requests:
>
> PR_TASK_ISOLATION_REQUEST
>
> Thanks.
Yes, this was annoying.
Will extend the interface to split SET/GET per command as well (so
its easier to know from which feature the error comes from),
and use REQUEST to finally enter isolated mode.
Thanks for the suggestion!
