On Tue, Oct 16, 2018 at 05:35:50PM +0300, Andy Shevchenko wrote: > On Fri, Oct 12, 2018 at 2:41 PM Heikki Krogerus > <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > > > > Hi guys, > > > > To continue the discussion started by Dmitry [1], this is my proposal > > that I mentioned in my last mail. In short, the idea is that instead > > of trying to extend the support for the currently used struct > > property_set, I'm proposing that we introduce a completely new, > > independent type of fwnode, and replace the struct property_set with > > it. I'm calling the type "software node" here. > > > > The reason for a complete separation of the software nodes from the > > generic property handling code is the need to be able to create the > > nodes independently from the devices that they are bind to. > > > > The way this works is that every node that is created will have a > > kobject registered. That will take care the ref counting for us, and > > also allow us to for example display the properties in sysfs. > > > > There are a few more details in patch 3/5 about the software nodes in > > the commit message. > > > > [1] https://lkml.org/lkml/2018/9/17/1067 > > In private discussion I brought a concern that we exposed properties > as a part of ABI, but at the same time we have not strict rules which > might lead to ambiguous reading, e.g. there is no type exported and > thus no possibility to tell what kind of property it is. > > Examples: > 1. 0x1 and 0x1 ??? are they of the same type? > 2. 0x1 ??? is it an array or single value? > 3. 0x12345678 ??? is it string or hex? > 4. 25 ??? is it hex or decimal? This is mostly a note to self, but also to let everybody know: After thinking about this a bit more I realised that the user space has to know what the property it is reading contains. An array of integers can actually be a string in reality, just like a string may contain an integer value(s). String or string array could describe a data structure, or even supply the values for one. In reality the type of the property, or the fact that it's an array or not, do not help at all to determine the content of the property. So the user space has to know what a property returns if it wants to use it, and once the user space knows that, the user space will also know the type and other details about the property, including knowing is it an array or not. Based on that, I'm against any kind of grouping or naming of the properties, was it based on the type of the property or is it an array or not, or supplying any details about the properties in any way to the user space. That would only complicate the life for the user space, as the grouping or naming, or supplying the details about the properties in any way, does not provide any information that the user space does not already have. The details about the properties would just be a sort of a useless noise for the user space that just has to be filtered out. Therefore I'm going to continue to propose that we expose the properties exactly the way I'm doing now: we'll have the "properties" directory that contains an attribute file for every property named with the names of the properties, and nothing else. The output formats we can still debate about, but Andy had already good proposals for that. I'm still not planning to include the property exposure at the first stage. Well add it after the initial support is in. Thanks, -- heikki
