public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Steve McIntyre <steve.mcintyre@linaro.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
	"libc-ports@sourceware.org" <libc-ports@sourceware.org>,
	Marcus Shawcroft <marcus.shawcroft@gmail.com>,
	"Ryan S. Arnold" <ryan.arnold@linaro.org>
Subject: Re: Policy: Require new dynamic loader names for entirely new ABIs?
Date: Mon, 20 Jan 2014 17:10:00 -0000	[thread overview]
Message-ID: <20140120170904.GF21103@linaro.org> (raw)
In-Reply-To: <52DD4BB8.1090901@redhat.com>

On Mon, Jan 20, 2014 at 11:15:52AM -0500, Carlos O'Donell wrote:
>On 01/17/2014 06:04 PM, Andrew Pinski wrote:
>> I withdraw my objection to the patch.  Though I do feel this
>> discussion should have been done on the GCC/glibc list in addition to
>> the linaro cross distro list as not every one knows about that list.
>
>I feel your pain here.

Yes, this could have worked much better. Multiple people spoke about
posting patches and discussing things more widely, but it fell through
the cracks. :-(

>I was also frustrated by lack of transparency
>when it cam to agreement on ABI details for
>ARM hard-float. At the time I was working for
>Mentor Graphics and we had to scramble to
>implement a solution.

ACK. That was more painful because we left things later than we should
have done in terms of defining the ABI, and various groups were
already publically using the same loader name for different things. In
the case of the discussion around the BE AArch64 loader, it seemed
that nobody was (yet) producing anything so there wouldn't be any
problems. Andrew: apologies for the hassle to you here...

>I support it because changing the dynamic loader
>name now is less painful than later, we have
>users that need it, and a workaround.
>
>The only thing I can say is that we make it
>policy that entirely new ABI's should always
>use a unique dynamic loader name unless the
>submitter can argue otherwise.
>
>That way in the future we never see this
>problem.
>
>Thoughts?

That would be lovely. I don't see much of a downside so long as this
is understood up front for new ports/ABIs etc. - there's very little
cost to it at that point.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

      reply	other threads:[~2014-01-20 17:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-01 17:38 [PATCH] [AArch64] Define BE loader name Marcus Shawcroft
2014-01-01 19:31 ` pinskia
2014-01-01 19:57   ` pinskia
2014-01-06 11:06   ` Marcus Shawcroft
2014-01-06 17:16     ` Andrew Pinski
2014-01-08 22:43       ` Carlos O'Donell
2014-01-13 18:17         ` Steve McIntyre
2014-01-17 23:04           ` Andrew Pinski
2014-01-20 15:53             ` Marcus Shawcroft
2014-01-20 16:13               ` Joseph S. Myers
2014-01-20 16:15             ` Policy: Require new dynamic loader names for entirely new ABIs? Carlos O'Donell
2014-01-20 17:10               ` Steve McIntyre [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140120170904.GF21103@linaro.org \
    --to=steve.mcintyre@linaro.org \
    --cc=carlos@redhat.com \
    --cc=libc-ports@sourceware.org \
    --cc=marcus.shawcroft@gmail.com \
    --cc=pinskia@gmail.com \
    --cc=ryan.arnold@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).