linux-kernel - Re: [RFC][PATCH -mm 3/3] PM: Disable _request

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]

Date:	Mon, 28 May 2007 11:26:28 +0100
From:	Michael-Luke Jones <mlj28@....ac.uk>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Pavel Machek <pavel@....cz>,
	Alan Stern <stern@...land.harvard.edu>,
	Rob Landley <rob@...dley.net>
Subject: Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

On 28 May 2007, at 10:06, Kay Sievers wrote:

> The underlying issue are the driver authors, that's not so easy to
> fix. :)

Sorry, I know this maybe be unintentional, but comments like this  
make me somewhat angry.

If there is no decent documentation as to how to do it the right way  
(tm), how do you expect people to do it the right way (tm)?

> Any timeout for a
> firmware-request is just a broken concept, the request should wait
> forever, to be fulfilled or canceled from userspace when it's ready.

What I wrote above is especially true when the in-kernel APIs  
themselves do things the wrong way (tm) themselves. Thus, even more  
thought is required to work around this imperfect behaviour in a sane  
manner. And without documentation, every single device driver author  
has to go through this thought process themselves. Unsurprisingly,  
they often get it wrong. But as there's no decent documentation to do  
it right, it's *not* their fault. I'd suggest it's more the fault of  
the core kernel devs who fail to fix up a questionable firmware  
loading interface, then fail to document how to work around its  
shortcomings.

Again, apologies if this sounds angry, I don't want to start an  
argument. But as someone just starting out here, this kind of thing  
can be very frustrating, as even with the best will in the world,  
achieving the right way (tm) is basically impossible if those in the  
know about what the right way (tm) is fail to share this information.

Michael-Luke Jones

-
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/