linux-kernel - Re: [PATCH] firmware/efi: export a routine to retrieve efi-variables by GUID

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:	Fri, 18 Mar 2011 18:15:47 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Greg KH <gregkh@...e.de>
CC:	"Jiang, Dave" <dave.jiang@...el.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"Danecki, Jacek" <jacek.danecki@...el.com>,
	"Ciechanowski, Ed" <ed.ciechanowski@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"dmilburn@...hat.com" <dmilburn@...hat.com>,
	"Nadolski, Edmund" <edmund.nadolski@...el.com>,
	Jeff Garzik <jeff@...zik.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH] firmware/efi: export a routine to retrieve efi-variables
 by GUID

On 3/18/2011 5:22 PM, Greg KH wrote:
> On Fri, Mar 18, 2011 at 04:10:10PM -0700, Dan Williams wrote:
>>> I needed all patches in linux-next _before_ the merge window opened to
>>> be able to accept it.
>>
>> Yes, I know, and as dmaengine maintainer I also hate being ambushed by
>> last minute patches, but now I am unfortunately one of those annoying
>> people on the other side of the coin.
>
> Then you should know better than to try to go around the well-known
> rules :)

Yes...

/me about to push his luck

...I also know the rules can sometimes be bent:

$ git describe --contains 9d200153
v2.6.35-rc2~14^2~15

commit 9d20015391dfc47f6371492925cc0333ac403414
Author: Stepan Moskovchenko <stepanm@...eaurora.org>
Date:   Wed May 19 11:03:30 2010 -0700

     Staging: add MSM framebuffer driver

I see you got flamed for that:
"I pulled, but quite frankly, I don't want to see this kind of pull 
request again. There's just no _point_.

I'll take new drivers outside the merge window, but there has to be some
_reason_ for them. See the whole SCSI discussion a few merge windows 
ago. The new driver needs to improve the life of somebody to the point 
where I want to feel that there is a _reason_ for pulling it outside the 
merge window.

These drivers? Not so much. Not even f*cking close.

In other words: tell me why the new drivers couldn't just have waited 
for the next merge window? Really?"

As Jeff pointed out:
"It seemed like this was turning into another driver that would get held 
outside the kernel until it's "perfect."  If that is the case, Linus has 
also made it clear we should get drivers for high volume, shipping 
hardware into the kernel, even if its staging, if the alternative is to 
deny users the driver."

So yes, we are targeting that exception.  I'm up for taking the heat 
directly if you want...  because the pull request will need to backed up 
with justification.

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