Hi Christoph
On Thu, 11 Aug 2022 at 16:09, Christoph Hellwig hch@lst.de wrote:
On Fri, Aug 05, 2022 at 03:15:53PM +0100, Mike Leach wrote:
You are correct - in this patchset we are adding the use of a binary attribute to load and unload Coresight configurations and features - which action has a side effect of adding and removing entries in particular sub-directories in our configfs sub-system.
I don't think configfs was designed to be that dynamic. Especially the fact that a write to a binary attribute, which is intended to be just for passthrough to hardware is a bit concerning.
configfs may not have originally been intended to be used in quite this way, but the system is robust and well designed, and the APIs work perfectly well in the this way. The model of user programming a configuration item for kernel backed elements that have a userspace lifetime (as described in configfs.rst) is precisely the model we need to successfully leverage the coresight subsystem. Our requirements are more complex than the ACPI tables or USB gadget drivers that use configfs, as we are potentially configuring multiple coresight devices. What the user sees in the configfs directories for the configurations are only the user adjustable features of these configurations. The rest of the programming is set on the relevant devices.
From your further description it sounds like this binary attribute is loading structured data interpreted by the kernel, which really isn't how binary attributes in configfs or sysfs are intended to be used.
If you look at the ACPI configfs, then this is in fact loading an ACPI table structure into the kernel, through a binary attribute, that is validated and added to a list of tables, if it passes the validation. This is also an example of using a binary attribute to pass structured data into the kernel for subsequent interpretation - and this example is why I chose to use binary attributes in this way.
The data passed through the coresight 'load' binary attribute is validated, and then only if valid loaded into the coresight subsystem for use when coresight trace is activated and the user decides to use the configuration. (coresight configurations are loaded, but are only used if specifically selected during a trace session).
Regards
Mike