This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v2 12/14] arm: Add optimized addmul_1
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, <libc-ports at sourceware dot org>
- Date: Fri, 25 Oct 2013 15:13:21 -0700 (PDT)
- Subject: Re: [PATCH v2 12/14] arm: Add optimized addmul_1
- Authentication-results: sourceware.org; auth=none
- References: <1362159320-5934-1-git-send-email-rth at twiddle dot net> <1362159320-5934-13-git-send-email-rth at twiddle dot net> <20130301180032 dot C9BA52C0B2 at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1303060114560 dot 27512 at digraph dot polyomino dot org dot uk>
[A very old thread, but I still had it sitting around.]
> On Fri, 1 Mar 2013, Roland McGrath wrote:
>
> > I think the license is a non-problem since FSF is copyright owner.
>
> My understanding was that FSF approval was needed for relicensing code
> from other FSF-owned packages (as opposed to correcting simple mistakes,
> e.g. making the license notice on a file reflect established licensing
> practice for files used in a particular way). (E.g., when license
> exception notices were added to soft-fp for use in libgcc, that involved
> FSF approval for adding those notices.)
Given that we imported GMP code before and had permission, I don't think we
really need new permission for more GMP code being used for the same
purpose. That was 20 years ago and lots of things have changed, but I
still think so. Nonetheless, the most conservative thing would be to ask
the current FSF authorities and make it clear that it is a continuation of
a past exception rather than an entirely fresh one.
> > But if your from-scratch code is good then I don't know there's a
> > strong reason to use GMP's instead, since we haven't been tracking
> > GMP changes in our copies for years anyway AFAIK.
>
> I suspect other architectures might benefit from changes made in GMP to
> improve performance - but certainly this is code that has diverged
> significantly from the GMP versions over time.
Agreed. I think the long-term right thing is to be sharing the code with
GMP. But that requires both verifying that the reasons for the past
libc-local changes are satisfied by new GMP code, and establishing the
relationship with the current GMP maintainers so they understand what code
we are using and what extra constraints being used in libc puts on that
code (probably just name space issues and maybe PLT issues).
Thanks,
Roland