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:	Sat, 19 Mar 2011 17:14:59 -0700
From:	Greg KH <gregkh@...e.de>
To:	Dan Williams <dan.j.williams@...el.com>
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 Fri, Mar 18, 2011 at 06:15:47PM -0700, Dan Williams wrote:
> 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

<snip>

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

That's fine, _BUT_ you are trying to go around the rules for the merge
window, which isn't acceptable.  Also note that your driver isn't
self-contained, it needs this change at the least, right?  Any others?

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

No, sorry, I'll not take this for .40, all of my trees are merged with
Linus now for .40 and I'll only be sending him bugfixes until the .41
merge window opens up.

Remember, it's only a 3 month wait, you knew about this _WAY_ in
advance, so it's not like this is something new, or out of the ordinary
at all.  Because of that, I fail to see why this is somehow not
expected.

On a personal note, I'm going to be very scarse for the next 3 weeks due
to conferences and travel for spring break, so I physically don't have
the time to do any more merges like this with Linus.

thanks,

greg k-h
--
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/