Re: [PATCH] firmware/efi: export a routine to retrieve efi-variablesby GUID
From: Dan Williams
Date: Fri Mar 18 2011 - 21:16:04 EST
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
/me about to push his luck
...I also know the rules can sometimes be bent:
$ git describe --contains 9d200153
Author: Stepan Moskovchenko <stepanm@xxxxxxxxxxxxxx>
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
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/