llvm dev - Jun 2016 - [lld] r271569 - Start adding tlsdesc support for aarch64.

On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> Because the patch includes way too much and doesn't explain what it is
doing.
So let me get this straight: someone publishes a patch, you don't like
it, you do some private investigations and commit whatever you want
without even notifying the original authors?

I don't know how you work at your company, but this is not how open
source development works.

This is not the first time either that you step over people's toes
with your "design decisions" that you don't share with anyone.
Last
year, Adhemerval has worked for three months to get the LLD AArch64
back-end working and out of the blue, no warning, the whole back-end
was yanked.

It doesn't matter if it was the right decision or not in the long
term, we don't just yank things, especially not before some
deliberation on the list. See how long is taking for the new pass
manager to be enabled, or FastIsel or the new Selection, or the new
register allocators, etc.

That's not how open source works and I assumed you knew that.

> That is a general problem with aarch64, the documentation is missing
> and comments have to make due. I had a lot of work to rewrite the
> original aarch64 patches to be in line with the rest of lld and I
> didn't want to have to do the same for tls.
You shouldn't be rewriting *any* patch, but asking the original
authors to do that themselves.

There is a pattern that I'm seeing and that's that *you* refuse or
dismiss more patches than most other people. There are many of your
comments on reviews that are just personal, and then you step over
people's toes and commits yourself.

This does not scale. But more importantly, it puts into doubt the
validity of the tool you're so hardly defending.

You see, 3 years ago, I was asked to choose between MCLinker and LLD.
MCLinker was a linker for all purposes, but Chris Lattner convinced me
that LLD is the LLVM linker, and we should be focusing all efforts
there.

It goes against the commercial interests of Linaro members to choose
such a premature technology, and it did put them back years of
development, because MCLinker was very close to ready, and MediaTek,
despite what people said, was very willing to accept our help.

But in the interest of the community, and the open source nature of my
work, I have decided to pursue LLD and managed to convince Linaro to
put two people working on it. But now, I'm re-evaluating all my
strategy, and sincerely, I do not trust the LLD community anymore.

> The delay was because of the above mentioned issues. I wanted to make
> sure there was a solid foundation.
Some patches are quick to review, others take 6 months. If you work in
open source you have *got* to understand that. If you're not willing
to take that cost, than please, refrain from working open source.

> Sorry, no.
I understand your position, but you have to understand mine. I
therefore call into question your ability to care about such an
important project of the LLVM community.

I sincerely believe that your actions are harming the project, and the
people trying to help. I appreciate the value of your contribution, I
really do, but if you don't change your way to handle open source
contributions, LLD will, whether you like it or not, become irrelevant
and be replaced.

Such is the nature of open source.

cheers,
--renato

On 2 June 2016 at 17:21, Renato Golin <renato.golin at linaro.org>
wrote:
> On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> Because the patch includes way too much and doesn't explain what it
is doing.
>
> So let me get this straight: someone publishes a patch, you don't like
> it, you do some private investigations and commit whatever you want
> without even notifying the original authors?
>
> I don't know how you work at your company, but this is not how open
> source development works.
>
> This is not the first time either that you step over people's toes
> with your "design decisions" that you don't share with
anyone. Last
> year, Adhemerval has worked for three months to get the LLD AArch64
> back-end working and out of the blue, no warning, the whole back-end
> was yanked.
lld is a very new project as far as linkers go. I am sorry we failed
to get a perfect design the first time, but we did not. The symbol
table was rewritten, the relocation processing was rewritten. And that
was discussed. In fact, pcc did the final coding of the symbol table
rewrite and rui review the relocation rewrite.

The entirety of the project is subject to being rewritten as we find
better ways of doing things.

Cheers,
Rafael

On Thu, Jun 2, 2016 at 5:21 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 2 June 2016 at 23:22, Rafael Espíndola <rafael.espindola at
gmail.com>
> wrote:
> > Because the patch includes way too much and doesn't explain what
it is
> doing.
>
> So let me get this straight: someone publishes a patch, you don't like
> it, you do some private investigations and commit whatever you want
> without even notifying the original authors?
>
> I don't know how you work at your company, but this is not how open
> source development works.
>
> This is not the first time either that you step over people's toes
> with your "design decisions" that you don't share with
anyone. Last
> year, Adhemerval has worked for three months to get the LLD AArch64
> back-end working and out of the blue, no warning, the whole back-end
> was yanked.
>
> It doesn't matter if it was the right decision or not in the long
> term, we don't just yank things, especially not before some
> deliberation on the list. See how long is taking for the new pass
> manager to be enabled, or FastIsel or the new Selection, or the new
> register allocators, etc.
>
> That's not how open source works and I assumed you knew that.
>
>
> > That is a general problem with aarch64, the documentation is missing
> > and comments have to make due. I had a lot of work to rewrite the
> > original aarch64 patches to be in line with the rest of lld and I
> > didn't want to have to do the same for tls.
>
> You shouldn't be rewriting *any* patch, but asking the original
> authors to do that themselves.
>
> There is a pattern that I'm seeing and that's that *you* refuse or
> dismiss more patches than most other people. There are many of your
> comments on reviews that are just personal, and then you step over
> people's toes and commits yourself.
>
> This does not scale. But more importantly, it puts into doubt the
> validity of the tool you're so hardly defending.
>
> You see, 3 years ago, I was asked to choose between MCLinker and LLD.
> MCLinker was a linker for all purposes, but Chris Lattner convinced me
> that LLD is the LLVM linker, and we should be focusing all efforts
> there.
>
> It goes against the commercial interests of Linaro members to choose
> such a premature technology, and it did put them back years of
> development, because MCLinker was very close to ready, and MediaTek,
> despite what people said, was very willing to accept our help.
>
> But in the interest of the community, and the open source nature of my
> work, I have decided to pursue LLD and managed to convince Linaro to
> put two people working on it. But now, I'm re-evaluating all my
> strategy, and sincerely, I do not trust the LLD community anymore.
>
Not so fast to conclude that the community is not trustworthy, it doesn't
consist of a single person or a single action. I do appreciate all
developers who contribute to the project and want to foster the cooperative
environment. As to the technical point, I honestly don't fully understand
the particular patches in every detail, and since Rafael rewrote that part
of code recently, I trust him that he is the most knowledgeable person who
can make a best technical decision.

Being said that, for this particular instance, I wouldn't submit right away
but send it to review and explain why I think better. I'm totally fine if
someone who knows more than me write a better patch than mine as a result
of code review for my patch, but I would be surprised if an alternative is
just submitted. I'm not sure if this needs to be reverted, but at least,
could you send it review next time in a similar situation, Rafael?
> The delay was because of the above mentioned issues. I wanted to make
> > sure there was a solid foundation.
>
> Some patches are quick to review, others take 6 months. If you work in
> open source you have *got* to understand that. If you're not willing
> to take that cost, than please, refrain from working open source.
>
>
> > Sorry, no.
>
> I understand your position, but you have to understand mine. I
> therefore call into question your ability to care about such an
> important project of the LLVM community.
>
> I sincerely believe that your actions are harming the project, and the
> people trying to help. I appreciate the value of your contribution, I
> really do, but if you don't change your way to handle open source
> contributions, LLD will, whether you like it or not, become irrelevant
> and be replaced.
>
> Such is the nature of open source.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/e272af1f/attachment.html>

On 3 June 2016 at 01:53, Rui Ueyama <ruiu at google.com>
wrote:
> Not so fast to conclude that the community is not trustworthy, it
doesn't
> consist of a single person or a single action.
This is not an isolated incident. This seems to be the general
behaviour around LLD, which is less so in the rest of the LLVM
projects.

The obliteration of the old ELF back-end was discussed only between a
few people, not on the list. The technical reasoning could have been
solid for a new back-end, but not for destroying fresh code. The
removal was weeks after Adhemerval had LLD bootstrapping Clang on
AArch64 upstream.

There were backlashes to that decision, as well as other decisions in
this list, and many people have already demonstrated discontent with
how LLD patches and decisions are handled.

During EuroLLVM's LLD presentation, a lot of people asked technical
questions about the implementation of wanted features like library
order, linker scripts, version scripts, and all answers were "it's not
that hard, it's all in my head, don't worry about it".

If this was a closed source project, and you, Rafael, Nick and PCC
were the team developing it, it'd be expected that the team lead would
have some leeway on the implementation and the consumers would have to
wait until it's ready. But this is open source, and that's absolutely
*not* how things work out here. That is *precisely* the problem, not
this one incident. This incident was just the tipping point.

That is why I personally don't trust the LLD community to act in the
open source way. I have seen it consistently repeated over the last
two years that I'm following. It makes no difference if this is a new
project or not, this is open source, and in open source we work
collaboratively. If you refuse people's patches because "you know
better", you're not doing open source and people doing it will move
elsewhere. This is not about you, me or Rafael, this is about the LLVM
linker.

So, I'll now be going back looking at MCLinker and see if we can make
a Linux/BSD ARM/AArch64 upstream linker out of it, compatible with the
GNU environment. As you can see [1], the development is still active,
up-to-date with modern LLVM and there are ARM and MIPS support
already, and the community there is far more receptive than LLD's.

We'll continue to work on ARM and AArch64 patches to LLD, but if
MCLinker proves an easier route to achieve our final goal, which is to
have a Lesser-licensed open source ARM/AArch64 linker for GNU/BSD
environments, and LLD's community continues to offer resistance and
bad behaviour, we'll slowly de-phase LLD in favour of MCLinker, at
least at Linaro.

Such is the nature of open source.

cheers,
--renato

[1] https://github.com/mclinker/mclinker

> Being said that, for this particular instance, I wouldn't submit right
away
> but send it to review and explain why I think better. I'm totally fine
if
> someone who knows more than me write a better patch than mine as a result
of
> code review for my patch, but I would be surprised if an alternative is
just
> submitted. I'm not sure if this needs to be reverted, but at least,
could
> you send it review next time in a similar situation, Rafael?

I honestly don't see what is the issue, so I don't think I be able to
judge. The rule of the thumb for ahead of time commit is how confident
someone is. I spend quite a few hours figuring out how tls works on
aarch64 and as a result wrote a patch that used the same Expr names as
the original patch. Really, diff both diffs and notice it is quite
different. Also notice that the commit message includes information
about aarch64 that I simply haven't seen written anywhere, including
the original patch.

Once more is implemented I will document the details I found on how
dlopen works.

Cheers,
Rafael