linux-kernel - Re: [RFC 02/15] drivers/base: add restrack framework

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 12 Dec 2014 16:52:30 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Andrzej Hajda <a.hajda@...sung.com>
Cc:	open list <linux-kernel@...r.kernel.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mike Turquette <mturquette@...aro.org>,
	Russell King <linux@....linux.org.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Inki Dae <inki.dae@...sung.com>,
	Kishon Vijay Abraham I <kishon@...com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	"moderated list:ARM/CLKDEV SUPPORT" 
	<linux-arm-kernel@...ts.infradead.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
	"open list:DRM PANEL DRIVERS" <dri-devel@...ts.freedesktop.org>,
	"moderated list:ARM/S5P EXYNOS AR..." 
	<linux-samsung-soc@...r.kernel.org>,
	"open list:OPEN FIRMWARE AND..." <devicetree@...r.kernel.org>,
	boris.brezillon@...e-electrons.com
Subject: Re: [RFC 02/15] drivers/base: add restrack framework

On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote:
> restrack framework allows tracking presence of resources with dynamic life
> time. Typical example of such resources are all resources provided by device

I don't know about anyone else but I'm having a hard time reading the
restrack name, it looks like a misspelling of restack to me.

At a high level my biggest questions here are the relationship between
this and the component code and usability.  The usability concern I have
is that I see no diagnostics or trace here at all.  This means that if a
user looks at their system, sees that the device model claims the driver
for a device bound to the device but can't see any sign of the device
doing anything they don't have any way of telling why that is other than
to look in the driver code, see what resources it was trying to depend
on and then go back to the running system to try to understand which of
those resources hasn't appeared.

> +int restrack_up(unsigned long type, const void *id, void *data)

> +int restrack_down(unsigned long type, const void *id, void *data)

Again I'm not sure that the up and down naming is meaningful in the
context of this interface.

> +static void restrack_itb_cb(struct track_block *itb, void *data, bool on)
> +{

itb_cb?

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)