linux-kernel - Re: [PATCHv5] dmaengine: Add support for BCM2835

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]

Date:	Sat, 16 Nov 2013 12:22:44 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Andy Shevchenko <andy.shevchenko@...il.com>,
	"Shevchenko, Andriy" <andriy.shevchenko@...el.com>,
	Florian Meier <florian.meier@...lo.de>,
	"Koul, Vinod" <vinod.koul@...el.com>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv5] dmaengine: Add support for BCM2835

On Sat, Nov 16, 2013 at 11:41:34AM +0000, Russell King - ARM Linux wrote:
> On Sat, Nov 16, 2013 at 11:27:54AM +0000, Mark Brown wrote:

> > We should in general be moving in that direction however it does need a
> > bit of care to make sure that there aren't any dependencies which do
> > things like discard error codes, fail to check errors or treat errors as
> > hard failures.

> I don't agree: on platforms which have done this, it's very difficult to
> tell from reading the kernel message log whether things came up correctly
> because there's soo much spew from deferred probing it's virtually
> impossible to tell whether component X initialised or whether that error
> about resource Y missing was ever resolved.

I do agree that deferred programming is far too chatty - there's a
usability issue there.  This bites me a lot on some of my systems too, I
tend to read my logs with grep a lot which isn't awesome.

> If we want kernel boot logs to be useful, we really need to shut up *all*
> the drivers and subsystems whinging about being deferred probing, and only
> have the driver model core reporting this status - maybe only allow
> output about why at debug level or similar.

Yes, some sort of standardisation of how this stuff gets reported would
give us much better control of these things.

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