linux-kernel - Re: [PATCH 00/13] Discover and probe dependencies

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: <5582E476.6040905@ahsoftware.de>
Date:	Thu, 18 Jun 2015 17:32:06 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Andrzej Hajda <a.hajda@...sung.com>
CC:	Mark Brown <broonie@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	linux-arm-kernel@...ts.infradead.org,
	Alexandre Courbot <gnurou@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Kumar Gala <galak@...eaurora.org>, Len Brown <lenb@...nel.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org, Lv Zheng <lv.zheng@...el.com>,
	Mark Rutland <mark.rutland@....com>,
	Pawel Moll <pawel.moll@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Robert Moore <robert.moore@...el.com>,
	Rob Herring <robh+dt@...nel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Terje Bergström <tbergstrom@...dia.com>,
	Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH 00/13] Discover and probe dependencies

Am 18.06.2015 um 16:49 schrieb Russell King - ARM Linux:

> I think you may need to pick a better example to illustrate your point. :)

It's easy to describe: Sort driver probe calls and forget about the 
whole device-stuff.

The real target is to sort the driver probe calls and ideally the whole 
device stuff could be ignored, leaving it as however it may work.

Unfortunately, that's not as easy to implement as it sounds. ;)

I've too hit the device-stuff very late in my driver-probe-ordering 
experiment and just did it somehow, because I already was at the limit 
of the time I wanted to spend. ;)

So to repeat myself, I think the first target has to be to identify 
drivers either without having to call their initcalls at all, or by 
making sure their initcalls just register and do nothing else (what I've 
called "well-done").

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/