linux-kernel - Re: [RFC PATCH 0/5] device property: Introducing software nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181017145317.GA14912@kuha.fi.intel.com>
Date:   Wed, 17 Oct 2018 17:53:17 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [RFC PATCH 0/5] device property: Introducing software nodes

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@...ux.intel.com> 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