Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757200AbdLPQ2W (ORCPT ); Sat, 16 Dec 2017 11:28:22 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:37722 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757172AbdLPQ2Q (ORCPT ); Sat, 16 Dec 2017 11:28:16 -0500 Message-ID: <1513441634.31439.34.camel@oracle.com> Subject: Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program From: Knut Omang To: Joe Perches , linux-kernel@vger.kernel.org Cc: Mauro Carvalho Chehab , Nicolas Palix , Jonathan Corbet , Santosh Shilimkar , Matthew Wilcox , cocci@systeme.lip6.fr, rds-devel@oss.oracle.com, linux-rdma@vger.kernel.org, linux-doc@vger.kernel.org, Doug Ledford , =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= , Shuah Khan , linux-kbuild@vger.kernel.org, Michal Marek Date: Sat, 16 Dec 2017 17:27:14 +0100 In-Reply-To: <1513437684.4647.30.camel@perches.com> References: <1513437684.4647.30.camel@perches.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8747 signatures=668649 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=775 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712160248 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 876 Lines: 30 On Sat, 2017-12-16 at 07:21 -0800, Joe Perches wrote: > On Sat, 2017-12-16 at 15:42 +0100, Knut Omang wrote: > > This patch series implements features to make it easier to run checkers on the > > entire kernel as part of automatic and developer testing. > > This seems like a useful and reasonable series, thanks. thanks, appreciated, > Do please take Julia's grammar updates. will do, > How is this series to be applied? I am open for suggestions. Let's leave patch #3 out for now. It's safe to apply #1 (and #2) alone. Patches #4 and #5 only have value once patch #1 is accepted, and I included them in the set for documentation purposes. They don't break anything by getting into the RDMA or RDS subsystem without patch #1, alternatively they can go together with the set of cleanup patches I have prepared for each of RDMA and RDS after #1 is in. Thanks, Knut