Date: Sun, 18 Dec 2016 12:38:23 +0530
From: Yury Norov <ynorov@caviumnetworks.com>
To: <arnd@arndb.de>, <catalin.marinas@arm.com>
CC: <schwidefsky@de.ibm.com>, <heiko.carstens@de.ibm.com>,
        <pinskia@gmail.com>, <broonie@kernel.org>, <joseph@codesourcery.com>,
        <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        <linux-doc@vger.kernel.org>, <bamvor.zhangjian@huawei.com>,
        <szabolcs.nagy@arm.com>, <klimov.linux@gmail.com>,
        <Nathan_Lynch@mentor.com>, <agraf@suse.de>,
        <Prasun.Kapoor@caviumnetworks.com>, <kilobyte@angband.pl>,
        <geert@linux-m68k.org>, <philipp.tomsich@theobroma-systems.com>,
        <manuel.montezelo@gmail.com>, <linyongting@huawei.com>,
        <maxim.kuvyrkov@linaro.org>, <davem@davemloft.net>,
        <zhouchengming1@huawei.com>, <cmetcalf@ezchip.com>
Subject: Re: [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
Message-ID: <20161218070823.GA1153@yury-N73SV>
References: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1477081997-4770-1-git-send-email-ynorov@caviumnetworks.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Dec 2016 07:08:39.2846 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2253
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1248
Lines: 27

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.

Yury.