This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] powerpc: New feature - HWCAP/HWCAP2 bits in the TCB


On Tue, Jun 30, 2015 at 01:49:26PM -0400, David Edelsohn wrote:
> On Tue, 2015-06-30 at 18:01 +0200, Torvald Riegel wrote:
> 
> > I don't think we promise to do everything for everyone.  That does not
> > conflict with free software.
> 
> The request is not "do everything for everyone".  That is a strawman argument.
> 
> The issue is: should the GLIBC community and leaders use their
> position to pick favorites for architectures and ABIs.  If the GLIBC
> community wants to say that GLIBC features and architecture and
> framework will be designed for the most prevalent, commodity
> architecture and ABI (Intel x86-64) and all other architectures can
> live on the table scraps when the benevolent dictators magnanimously
> choose to throw them a bone, that's fine as long as it is explicit.
> 
> The proposal is not a request to restructure core, common parts of
> GLIBC in badly designed ways.  The proposal is not advocating use of
> this feature in this programming style as exemplary.  It's a
> least-bad, target-specific patch to deal with a performance problem of
> real-world, customer code seen in the field.
> 
> Admonishing IBM that it should lecture customers on how to write their
> code or essentially declaring that the idioms adopted by most
> programmers because of Intel x86 prevalence are somehow preferred as
> if they were handed down on silver tablets is arrogant and naive.
> 
> If you make your garden too exclusive, don't be surprised when people
> plant alternative gardens.

I fail to see how this has anything to do with giving special
preferred status to Intel architectures. Such a hack for x86 would be
equally disagreeable. The problem is that it's "incurring technical
debt" in making a new ABI contract, which is permanent and can never
be removed, for the same of optimizing a bad programming practice. The
fact that it happens to be PPC customers who are doing this bad
practice is not relevant.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]