From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: linux rdma 3.14 merge plans Date: Thu, 16 Jan 2014 13:58:57 -0800 Message-ID: <20140116215857.GA29776@kroah.com> References: <52CD1C68.4050406@mellanox.com> <1389645171.5567.459.camel@haakon3.risingtidesystems.com> <1389820541.5567.543.camel@haakon3.risingtidesystems.com> <1389906852.5567.668.camel@haakon3.risingtidesystems.com> <20140116213717.GA24718@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Or Gerlitz Cc: "Nicholas A. Bellinger" , Roland Dreier , Hefty Sean , Or Gerlitz , Sagi Grimberg , linux-rdma , "Martin K. Petersen" List-Id: linux-rdma@vger.kernel.org On Thu, Jan 16, 2014 at 11:42:19PM +0200, Or Gerlitz wrote: > On Thu, Jan 16, 2014 at 11:37 PM, Greg Kroah-Hartman > wrote: > > On Thu, Jan 16, 2014 at 01:14:12PM -0800, Nicholas A. Bellinger wrote: > >> On Thu, 2014-01-16 at 12:13 -0800, Roland Dreier wrote: > >> > > On Mon, 2014-01-13 at 12:32 -0800, Nicholas A. Bellinger wrote: > >> > > > Hi Roland & Co, > >> > > > Just curious if your planning to take a look at this series soon for > >> > > > v3.14 code..? > >> > > > > >> > > > As you might imagine, I'd like to see it merged this round in order to > >> > > > move forward on iser-target protection for v3.15. > >> > > > > >> > > > Are there any specific issues that you'd like to see addressed for an > >> > > > initial merge..? > >> > > >> > I haven't really had a chance to look at the new API and decide if it > >> > makes sense as the way to expose these features. Have you looked at > >> > the new kernel API? Any thoughts? > >> > >> I've reviewed the API from the perspective of what's required for > >> implementing protection support in iser, and currently don't have any > >> recommendations or objections beyond what has been proposed by Sagi & Co > >> in PATCH-v4 code. > >> > >> > How does it compare with how other subsystems have exposed protection > >> > info? > >> > > >> > >> So there is not a interface in SCSI land for interacting (directly) with > >> hardware protection support, as it's primarily just telling SCSI what > >> protection modes are supported while the rest is implemented in vendor > >> specific firmware interfaces. (CC'ing MKP) > >> > >> > Right now I'm dealing with fixing the fallout from picking up the "IP > >> > addressing for IBoE" and other patch sets that were supposedly "ready > >> > to merge for a long time" so I'm not sure I'll get to the protection > >> > changes in time for 3.14. > >> > > >> > >> Pretty please for v3.14..? > > > > It's _really_ late in the development cycle for new stuff for 3.14. My > > trees have been closed for almost a week now, for major stuff, and for > > anything else for a few days now. It would be good if you could get > > your patchsets into the 0-day testing bot earlier to shake out any build > > issues that might happen with them, please work with that developer to > > help make the merging of the code easier. > > Greg, > > The T10 patches were posted whole three months ago (V0 Oct 15th). I > don't see why another cycle should get lost just because there was no > maintainer feedback on them throughout this whole period. There's > enough time for us to fix things that will show up in the testing bot > before Roland sends his pull request over the two weeks merge window. There's the rule that things need to be in linux-next for a week or so to shake things out before going to Linus, and that new things can't be added to a maintainer tree after Linus does a release before -rc1 is out. We can't break those rules unless you want to answer to the linux-next developer and Linus for it. Yes, I know your patches have been pending for a long time, this merge window was tough in that it covered two major holidays, your patches aren't the only thing that is going to miss 3.14 by a long-shot, there are lots of other developers who also didn't get stuff in due to maintainers taking long vacations. Which is fine, and is why we have 3 month release cycles, there's nothing wrong with waiting for 3.15 if there are build issues that are cropping up this late in the cycle. That's why I suggest you get your trees into the 0-day bot test systems, so that a maintainer has a semblance of confidence that the build will not break, and the "obvious" security issues are resolved, if they take your patches. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html