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]

Message-Id: <1180353701.4242.68.camel@lov.localdomain>
Date:	Mon, 28 May 2007 14:01:40 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Michael-Luke Jones <mlj28@....ac.uk>
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 Mon, 2007-05-28 at 11:26 +0100, Michael-Luke Jones wrote:
> 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.

It was the response to "pushing a bodge upstream", while we just try to
make things working. :)
We are fighting that broken firmware-loader model for years, but every
driver author seems to have its own idea how that should work in theory,
but they are not even willing to switch to the existing version that is
expected to work better.

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

In our development model, users of an interface are expected to improve
it, because nobody else really knows what's needed. That unfortunately
didn't happen so far.

We get this kind of conversation every few months since a few years now.
I wonder, if we will see code, or at least come up with a better idea
this time. :)

Kay

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