From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933768AbdAFOsZ (ORCPT ); Fri, 6 Jan 2017 09:48:25 -0500 Received: from foss.arm.com ([217.140.101.70]:49602 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754502AbdAFOrL (ORCPT ); Fri, 6 Jan 2017 09:47:11 -0500 Date: Fri, 6 Jan 2017 14:47:04 +0000 From: Catalin Marinas To: Yury Norov Cc: arnd@arndb.de, linux-doc@vger.kernel.org, szabolcs.nagy@arm.com, heiko.carstens@de.ibm.com, cmetcalf@ezchip.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, zhouchengming1@huawei.com, Prasun.Kapoor@caviumnetworks.com, agraf@suse.de, geert@linux-m68k.org, kilobyte@angband.pl, manuel.montezelo@gmail.com, pinskia@gmail.com, linyongting@huawei.com, klimov.linux@gmail.com, broonie@kernel.org, bamvor.zhangjian@huawei.com, linux-arm-kernel@lists.infradead.org, maxim.kuvyrkov@linaro.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com, davem@davemloft.net Subject: Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64 Message-ID: <20170106144704.GD12863@e104818-lin.cambridge.arm.com> References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com> <20161218070823.GA1153@yury-N73SV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161218070823.GA1153@yury-N73SV> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 18, 2016 at 12:38:23PM +0530, Yury Norov wrote: > On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote: > > This series enables aarch64 with ilp32 mode, and as supporting work, > > introduces ARCH_32BIT_OFF_T configuration option that is enabled for > > existing 32-bit architectures but disabled for new arches (so 64-bit > > off_t is is used by new userspace). > > > > This version is based on kernel v4.9-rc1. It works with glibc-2.24, > > and tested with LTP. > > Hi Arnd, Catalin > > For last few days I'm trying to rebase this series on current master, > and I see significant conflicts and regressions. In fact, every time > I rebase on next rc1, I feel like I play a roulette. > > This is not a significant problem now because it's almost for sure > that this series will not get into 4.10, for reasons not related to > kernel code. And I have time to deal with regressions. But in general, > I'd like to try my patches on top of other candidates for next merge > window. I cannot read all emails in LKML, but I can easily detect > problems and join to the discussion at early stage if I see any problem. > > This is probably a noob question, and there are well-known branches, > like Andrew Morton's one. But at this stage it's very important to > have this series prepared for merge, and I'd prefer to ask about it. I'm not entirely sure what the question is. For development, you could base your series on a final release, e.g. 4.9. For reviews and especially if you are targeting a certain merging window, it's useful to rebase your patches on a fairly recent -rc, e.g. 4.10-rc3. I would entirely skip any non-tagged kernel states (like middle of the merging window) or out of tree branches. There may be a case to rebase on some other developer's branch but only if there is a dependency that can't be avoided and usually with prior agreement from both the respective developer (as not to rebase the branch) and the involved maintainers. -- Catalin