linux-kernel - Re: sysfs deferred

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] [day] [month] [year] [list]

Message-ID: <20170114131511.GA26879@kroah.com>
Date:   Sat, 14 Jan 2017 14:15:11 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Ben Hutchings <ben.hutchings@...ethink.co.uk>
Cc:     Rob Herring <robh@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Mark Brown <broonie@...nel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: sysfs deferred_probe attribute

On Thu, Jan 12, 2017 at 06:26:11PM +0000, Ben Hutchings wrote:
> On Thu, 2017-01-12 at 18:41 +0100, Greg Kroah-Hartman wrote:
> > On Thu, Jan 12, 2017 at 11:27:01AM -0600, Rob Herring wrote:
> > > I just noticed that we have a new device attribute 'deferred_probe'
> > > added in 4.10 with this commit:
> > > 
> > > commit 6751667a29d6fd64afb9ce30567ad616b68ed789
> > > Author: Ben Hutchings <ben.hutchings@...ethink.co.uk>
> > > Date:   Tue Aug 16 14:34:18 2016 +0100
> > > 
> > >     driver core: Add deferred_probe attribute to devices in sysfs
> > > 
> > >     It is sometimes useful to know that a device is on the deferred probe
> > >     list rather than, say, not having a driver available.  Expose this
> > >     information to user-space.
> > > 
> > >     Signed-off-by: Ben Hutchings <ben.hutchings@...ethink.co.uk>
> > >     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > > 
> > > 
> > > It seems like a bad idea to add an ABI for an internal kernel feature.
> > > When/if we replace deferred probe with something better based on
> > > functional dependencies are we going to keep this attr around? Or
> > > remove it and assume no userspace uses it?
> 
> It should be removed then (and replaced with some kind of representation
> of dependencies).

Ok, now reverted.

thanks,

greg k-h