Michal Suchanek <msucha...@suse.de> writes:
> Additional patch suggestion to go with the rtas devices:
>
> -----------------------------------------------------------------------
>
> With most important rtas functions available through different
> interfaces the sys_rtas interface can be disabled completely.
>
> Do not remove it for now to make it possible to run older versions of
> userspace tools that don't support other interfaces.
Thanks. I hope making sys_rtas on/off-configurable will make sense
eventually, and I expect this series to get us closer to that. But to me
it seems too early and too coarse. A kernel built with RTAS_SYSCALL=n is
not something I'd want to support or run in production soon. It would
break too many known use cases, and likely some unknown ones as well.
It could be more useful in the near term to construct a configurable
list of RTAS functions that sys_rtas is allowed to expose.
Something like:
if PPC_RTAS
config RTAS_SYSCALL_ALLOWS_SET_INDICATOR
bool "sys_rtas allows calling set-indicator"
default y
config RTAS_SYSCALL_ALLOWS_GET_SENSOR_STATE
bool "sys_rtas allows calling get-sensor-state"
default y
config RTAS_SYSCALL_ALLOWS_GET_VPD
bool "sys_rtas allows calling ibm,get-vpd"
default y
... etc etc
endif
Distro kernels could configure their allowed set of calls according to
the capabilities of the user space components they ship, with the
expectation that they will be able to shrink that set as user space
adopts the preferred ABIs over time.
That's just a sketch of an idea though, and I'm not sure it needs to be
part of this series.
