This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: munroesj at linux dot vnet dot ibm dot com, Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, Joseph Butler <jbutler at redhat dot com>
- Cc: libc-alpha at sourceware dot org, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, Carlos Eduardo Seo <cseo at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Thu, 02 Jul 2015 23:21:37 -0400
- Subject: Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB
- Authentication-results: sourceware.org; auth=none
- References: <55760314 dot 6070601 at linux dot vnet dot ibm dot com> <20150609163835 dot GI17573 at brightrain dot aerifal dot cx> <1435777940 dot 7125 dot 132 dot camel at oc7878010663>
On 07/01/2015 03:12 PM, Steven Munroe wrote:
> This discussion has metastasizes into so many side discussions, meta
> discussion, personal opinions etc that i would like to start over at the
> point where we where still discussing how to implement something
> reasonable.
I want to make few higher level comments as an FSF steward for the glibc project.
* IBM has consistently provided hardware and developer resources to maintain
POWER for glibc. IBM is the POWER maintainer, and the ultimate responsibility
for the machine rests with IBM. Today that responsibility is with Steven Munroe
(IBM) who is the POWER maintainer for glibc. The machine maintainership provides
Steven with a veto for machine-specific features, ABIs and APIs, much like all
the other machine port maintainers. Steven is expected to use this veto to
further the goals of the glibc project, and serve the needs of POWER users, and
balance the two.
* Consensus need not be agreement, it may be that we discuss the options, find
no sustained opposition, and move forward with a solution. People can disagree
bitterly and we can still have consensus. Developers can have strong and polarizing
opinions about exactly how to use the limited resource of `thread-pointer + offset`
accessible data, but at the end of the day consensus can be reached.
* Healthy and active discussion, like the discussion on this particular topic,
are good for the community. Topics surrounding optimizations are rife with
complex tradeoffs, and require discussion, summaries, and a developer to
champion a position of consensus. I see nothing wrong with this kind of behaviour.
The discussions should stay on point, be technical, provide feedback, and
indicate clearly if the comment amounts to sustained opposition.
Cheers,
Carlos.