Michal Suchánek <msucha...@suse.de> writes: > On Thu, Aug 31, 2023 at 12:59:25PM -0500, Nathan Lynch wrote: ... >> You (Michal) seem to favor a kernel-user ABI where user space is allowed >> to invoke arbitrary RTAS functions by name. But we already have that in >> the form of the rtas() syscall. (User space looks up function tokens by >> name in the DT.) The point of the series is that we need to move away >> from that. It's too low-level and user space has to use /dev/mem when >> invoking any of the less-simple RTAS functions. > > We don't have that, directly accessing /dev/mem does not really work. > And that's what needs fixing in my view. > > The rtas calls are all mechanically the same, the function implemented > here should be able to call any of them if there was a way to specify > the call. > > Given that there is desire to have access to multiple calls I don't > think it makes sense to allocate a separate device with different name > for each.
I think it does make sense. We explicitly don't want a general "call any RTAS function" API. We want tightly scoped APIs that do one thing, or a family of related things, but not anything & everything. Having different devices for each of those APIs means permissions can be granted separately on those devices. So a user/group can be given access to the "papr-vpd" device, but not some other unrelated device that also happens to expose an RTAS service (eg. error injection). cheers