[PATCH v8 00/20] ILP32 for ARM64

[ynorov@caviumnetworks.com (Yury Norov)]

Hi Catalin,

Hope you spent your vacation well.

On Fri, Jul 07, 2017 at 06:11:36PM +0100, Catalin Marinas wrote:
> Hi Yury,
> 
> Just a quick reply as I'm about to go on holiday for the next two weeks.
> 
> On Fri, Jul 07, 2017 at 12:59:02AM +0300, Yury Norov wrote:
> > On Thu, Jun 29, 2017 at 05:10:36PM +0100, Catalin Marinas wrote:
> > > On Mon, Jun 19, 2017 at 06:49:43PM +0300, Yury Norov wrote:
> > > > This series enables aarch64 with ilp32 mode.
> > > 
> > > What I'd like to propose is that Will and I (as arm64 maintainers, maybe
> > > with with the help of others including this series' authors) take over
> > > the series and push it to a staging branch under the arm64 kernel on
> > > git.kernel.org. This is aimed as a commitment to keep the ABI *stable*
> > > and will be rebased with every kernel release (starting with 4.13). The
> > > decision to merge upstream will be revisited every 6 months, assessing
> > > the progress on the points I mentioned above, with a time limit of 2
> > > years when, if still not upstream, we will stop maintaining such branch.
> > 
> > Thanks for the email. I appreciate your concern about long-term
> > support load for a new ABI. I also think that stabilizing the ABI
> > is a good idea.
> > 
> > At this point, most people expect the ABI to not change unless
> > critical issues are uncovered. IMO, if there is a good technical reason
> > to change the ABI -- the change will happen even on the "staging" branch.
> 
> What I would like is that we change the ABI *only* if there is a serious
> bug, otherwise we should try hard to keep it stable. The "good technical
> reason" can be subjective (i.e. let's pass 64-bit arguments in a single
> register because some benchmark is slightly faster; with a wider user
> base, we may get more suggestions for ABI changes that we should
> reject).
> 
> > And vise-versa, if there is no need for a change, the ABI will be stable
> > on my local branch, just like on staging branch you propose. I think it
> > will be that way until there will appear strong community of users who
> > will resist the changing of ABI. From this point of view, I don't see
> > major difference for ILP32 where to host the patchset.
> 
> If we don't treat the ABI as stable now, regardless of the number of
> users, then it is not ready for upstream (we already have a user in the
> openSUSE build).
> 
> The arm64 git.kernel.org suggestion was more of an endorsement from the
> maintainers that the ABI is stable. If you want to maintain it in your
> own tree, that's fine by me. If you want wider visibility, we could
> mirror it to git.kernel.org (though given how many trees are there, it
> may not mean much).

I fully agree with your suggestion and think that it will be the big
support for the project. I only want to clarity some details. But it
doesn't mean I'm skeptic with it.

> > Is my understanding correct that you, Will and me will be responsible
> > for rebasing and maintainance of patches? To be clear, this it not an
> > automatic task - sometimes simple rebase take the whole day of my time,
> > and I rebase almost every week. The rebase in 2-month timeframe may become
> > unpredictable task, by time and amount of work. I think you understand what
> > I mean, as once before you already told that the series is too intrusive.
> 
> I am fully aware there is significant effort to rebase the series and if
> you can help maintain such branch it would be great. I don't see the
> point of rebasing weekly though and it's not just the git handling
> process but doing the validation of such branch, regression testing etc.
> 
> If it's too time consuming, we could do it only for LTS releases.
> 
> > To make it more easy for maintainance, I would suggest to split the series
> > to 3 parts:
> >  - arch and generic patches that not related to ilp32 or arm64 (already
> >    done);
> 
> That's fine.
> 
> >  - arm64 patches that do cleanup and refactoring in aim to apply
> >    ilp32 patches smoothly, but not ilp32-specific;
> 
> If there are such changes, that's fine. However, I wouldn't merge the
> AARCH32_EL0 #ifdef'ery since it's unnecessary if we never merge the
> ILP32 patches.
> 
> > If we'll follow your suggestion, does it mean that you expect the 4.12-based
> > branch from me soon to put on staging?
> 
> We can create one for 4.12 if you want (in about 2-3 weeks time when I'm
> back). If there is no rush we could aim for 4.13 (there are some
> non-trivial conflicts in the sigframe handling code as we are preparing
> it for SVE support).
> 
> > > The decision to merge upstream will be revisited every 6 months,
> > > assessing the progress on the points I mentioned above, with a time
> > > limit of 2 years
> > 
> > IIUC, this is your personal decision based on responses and comments
> > from community?
> 
> Yes, as arm64 kernel maintainer.
> 
> > If so, I would like to ask you to do the first ILP32 community poll
> > now, not in 6 months. So we'll collect opinions and requests from
> > people interested in ILP32, and in 6 month will be able to check the
> > progress. I would like to see this thread public because if we are not
> > taking ILP32 to official sources right now, this is the only way to
> > inform people that the project exists and is ready to use.
> 
> That's an ongoing process, I'm not going to ask for people's opinion
> every 6 months. It's just that I will revisit periodically the progress
> on automated testing, public availability of a cross-toolchain,
> Tested/Acked/Reviewed-by tags on these patches from interested parties.
> Since I haven't seen any of these now, I don't see any point in asking.
> 
> To be clear, I'm not really interested in "we need this too" opinions, I
> get lots of these via the marketing channels. I'm looking for actual
> users with a long-term view of making/keeping ILP32 a first class ABI.

>From my side, there are people who ask me for help with ilo32, and who
write from big companies mailservers. But they don't want to ask
their questions publicly for some reason. From my point of view, there
is not so big but stable interest in ILP32.

Nevertheless.

This is the 4.12 and linux-next - based kernel patches:
https://github.com/norov/linux/tree/ilp32-4.12
https://github.com/norov/linux/tree/ilp32-20170724

And this is the glibc series I've created based on Steve's patches in
glibc-alpha mail list (for reference only):
https://github.com/norov/glibc/tree/ilp32-2.26

I hope I didn't miss any reviewer's comments. But if that happened i
kindly ask to excuse me. Should I resend kernel patches to LKML, or
links above are enough for you?

Yury