AArch64 ILP32 abi in glibc

AArch64 ILP32 abi in glibc

[Szabolcs Nagy]

The patches to support ILP32 in the Linux kernel are not going
into mainline, so the ILP32 port cannot be accepted into glibc
master yet, see

https://lkml.org/lkml/2017/6/29/557

On the glibc side the plan is to create an ILP32 branch once the
known glibc and kernel side issues are resolved. This way we have
a canonical upstream branch for all ILP32 activity and we would
like downstream consumers to use this branch. Contributions to
this branch should go through the libc-alpha review process like
for master and I expect interested parties including Cavium to
help maintaining the branch.

Current glibc policy is that when a glibc port is merged into
mainline it receives an ABI bump. We will do our best to maintain
ABI stability on the branch, but whether the ABI is maintained at
the time of merge depends on the upstream glibc community.

Re: AArch64 ILP32 abi in glibc

[Adhemerval Zanella]

On 29/06/2017 14:13, Szabolcs Nagy wrote:
> The patches to support ILP32 in the Linux kernel are not going
> into mainline, so the ILP32 port cannot be accepted into glibc
> master yet, see
> 
> https://lkml.org/lkml/2017/6/29/557
> 
> On the glibc side the plan is to create an ILP32 branch once the
> known glibc and kernel side issues are resolved. This way we have
> a canonical upstream branch for all ILP32 activity and we would
> like downstream consumers to use this branch. Contributions to
> this branch should go through the libc-alpha review process like
> for master and I expect interested parties including Cavium to
> help maintaining the branch.
> 
> Current glibc policy is that when a glibc port is merged into
> mainline it receives an ABI bump. We will do our best to maintain
> ABI stability on the branch, but whether the ABI is maintained at
> the time of merge depends on the upstream glibc community.
> 

What are the plan for maintenance in near future in case kernel
support never lands?  Would ARM, Cavium, and other interested
parties to keep maintain both kernel and glibc branches indefinitely
in such cases? 

I am asking it because for ABI merge on glibc without the current
requiring bump might be easier to manage if we an outlined plan
(and a fallback one if we continue without kernel support).

Re: AArch64 ILP32 abi in glibc

[Carlos O'Donell]

On 06/29/2017 01:13 PM, Szabolcs Nagy wrote:
> The patches to support ILP32 in the Linux kernel are not going
> into mainline, so the ILP32 port cannot be accepted into glibc
> master yet, see
> 
> https://lkml.org/lkml/2017/6/29/557
> 
> On the glibc side the plan is to create an ILP32 branch once the
> known glibc and kernel side issues are resolved. This way we have
> a canonical upstream branch for all ILP32 activity and we would
> like downstream consumers to use this branch. Contributions to
> this branch should go through the libc-alpha review process like
> for master and I expect interested parties including Cavium to
> help maintaining the branch.
> 
> Current glibc policy is that when a glibc port is merged into
> mainline it receives an ABI bump. We will do our best to maintain
> ABI stability on the branch, but whether the ABI is maintained at
> the time of merge depends on the upstream glibc community.

Vendor branches for both sounds like a good plan.

I particularly like the idea that patches should get review on
libc-alpha following the normal process. That's a very good idea
if the eventual goal is to merge to master.

We can start another thread about new ports and vendor branch
merge policy.

-- 
Cheers,
Carlos.

Re: AArch64 ILP32 abi in glibc

[Szabolcs Nagy]

On 29/06/17 18:47, Adhemerval Zanella wrote:
> On 29/06/2017 14:13, Szabolcs Nagy wrote:
>> The patches to support ILP32 in the Linux kernel are not going
>> into mainline, so the ILP32 port cannot be accepted into glibc
>> master yet, see
>>
>> https://lkml.org/lkml/2017/6/29/557
>>
>> On the glibc side the plan is to create an ILP32 branch once the
>> known glibc and kernel side issues are resolved. This way we have
>> a canonical upstream branch for all ILP32 activity and we would
>> like downstream consumers to use this branch. Contributions to
>> this branch should go through the libc-alpha review process like
>> for master and I expect interested parties including Cavium to
>> help maintaining the branch.
>>
>> Current glibc policy is that when a glibc port is merged into
>> mainline it receives an ABI bump. We will do our best to maintain
>> ABI stability on the branch, but whether the ABI is maintained at
>> the time of merge depends on the upstream glibc community.
>>
> 
> What are the plan for maintenance in near future in case kernel
> support never lands?  Would ARM, Cavium, and other interested
> parties to keep maintain both kernel and glibc branches indefinitely
> in such cases? 
> 

then the branch will be left alone as a reminder
for future generations.

> I am asking it because for ABI merge on glibc without the current
> requiring bump might be easier to manage if we an outlined plan
> (and a fallback one if we continue without kernel support).
> 

we are proposing the branch to make it possible to
build and test ilp32 from a canonical source, which
should help seeding the user base and ecosystem
(lack of which the kernel side was concerned about).

this is more work compared to upstream maintenance
(on both glibc and linux side), but the point of it
is that it avoids the even more work of indefinite
maintenance of a target that nobody might care about
in two years time. with this in mind i don't think
indefinite out-of-mainline maintenance is realistic.

Re: AArch64 ILP32 abi in glibc

[Florian Weimer]

On 06/29/2017 07:13 PM, Szabolcs Nagy wrote:
> On the glibc side the plan is to create an ILP32 branch once the
> known glibc and kernel side issues are resolved. This way we have
> a canonical upstream branch for all ILP32 activity and we would
> like downstream consumers to use this branch. Contributions to
> this branch should go through the libc-alpha review process like
> for master and I expect interested parties including Cavium to
> help maintaining the branch.

I'm worried that the existence of such a branch will interact poorly
with cleanups in master, say if some baroque constructs aren't needed
anymore by any supported port, but ILP32 happens to benefit from it.  In
some cases, the branch might get away with not merging the cleanup, but
in others, the ripple-on effect might be too severe.

Can we do without a branch instead?  I don't see how things are simpler
for non-ILP32 developers without the branch.  I expected that I'll deal
with fallout on ILP32 like I deal with other not-exactly-mainstream
architectures, and the separate branch makes that harder.

Thanks,
Florian

Re: AArch64 ILP32 abi in glibc

[Joseph Myers]

On Fri, 7 Jul 2017, Florian Weimer wrote:

> Can we do without a branch instead?  I don't see how things are simpler
> for non-ILP32 developers without the branch.  I expected that I'll deal

I think any port in master should build with mainline upstream kernel 
headers (and other components), or at least a kernel port we can be 
confident will be upstream in the next release or two.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: AArch64 ILP32 abi in glibc

[Carlos O'Donell]

On 07/06/2017 06:07 PM, Florian Weimer wrote:
> On 06/29/2017 07:13 PM, Szabolcs Nagy wrote:
>> On the glibc side the plan is to create an ILP32 branch once the
>> known glibc and kernel side issues are resolved. This way we have
>> a canonical upstream branch for all ILP32 activity and we would
>> like downstream consumers to use this branch. Contributions to
>> this branch should go through the libc-alpha review process like
>> for master and I expect interested parties including Cavium to
>> help maintaining the branch.
> 
> I'm worried that the existence of such a branch will interact poorly
> with cleanups in master, say if some baroque constructs aren't needed
> anymore by any supported port, but ILP32 happens to benefit from it.  In
> some cases, the branch might get away with not merging the cleanup, but
> in others, the ripple-on effect might be too severe.

As ILP32 is not on master, the port will need to adjust to any changes
we make, not the other way around.

I expect Szabolcs and other to act professionally in this regard, and
not block positive changes to master because it creates work for the
ILP32 branch.

We should be completely free to make any cleanups we see fit on master
without any significant consideration to ILP32. That doesn't mean that
the ILP32 developers cannot ask for consideration, but they must put
forth a very strong rationale.

-- 
Cheers,
Carlos.

Re: AArch64 ILP32 abi in glibc

[Florian Weimer]

On 07/07/2017 05:08 PM, Joseph Myers wrote:
> On Fri, 7 Jul 2017, Florian Weimer wrote:
> 
>> Can we do without a branch instead?  I don't see how things are simpler
>> for non-ILP32 developers without the branch.  I expected that I'll deal
> 
> I think any port in master should build with mainline upstream kernel 
> headers (and other components), or at least a kernel port we can be 
> confident will be upstream in the next release or two.

My comments were based on the Hurd and NaCl experiences.  I don't want
another port which is effectively out of tree, but with an expectation
to keep things going there.  If we can pretend that the port does not
exist, that's fine, but why would we coordinate this matter on
libc-alpha if that's the goal?

Thanks,
Florian

Re: AArch64 ILP32 abi in glibc

[Carlos O'Donell]

On 07/27/2017 03:49 AM, Florian Weimer wrote:
> On 07/07/2017 05:08 PM, Joseph Myers wrote:
>> On Fri, 7 Jul 2017, Florian Weimer wrote:
>>
>>> Can we do without a branch instead?  I don't see how things are simpler
>>> for non-ILP32 developers without the branch.  I expected that I'll deal
>>
>> I think any port in master should build with mainline upstream kernel 
>> headers (and other components), or at least a kernel port we can be 
>> confident will be upstream in the next release or two.
> 
> My comments were based on the Hurd and NaCl experiences.  I don't want
> another port which is effectively out of tree, but with an expectation
> to keep things going there.  If we can pretend that the port does not
> exist, that's fine, but why would we coordinate this matter on
> libc-alpha if that's the goal?

To set clear expectations.

To avoid people like you and I wondering if we need to do anything special
for the ARM vendor branch.

To describe the long term goal of merging the branch in the future.

As a volunteer you are free to *help* maintain that ILP32 branch if
you so choose.

All of these things are an important part of clear and open communication.

At this point you can ignore the branch in good conscience and focus on those
things that are important for you.

-- 
Cheers,
Carlos.