Re: How to submit large patch for xtensa-linux?

[Bob Wilson <bwilson at tensilica dot com>]

Ulrich Drepper wrote:
> All these non-mainstream architectures will from now on have to live in
> add-ons.  We plan to add some magic to the main configure file to allow
> add-ons provide the base_machine/machine definitions but that's it.
> Everything else can be handled in add-ons.  So, just reorganize your
> code to have to appropriate structure and, for the time being, provide a
> little patch to the main configure file.  Then distribute the add-on
> from your side.

Is this a new policy?  The current glibc sources certainly contain a number of 
ports that I would consider "non-mainstream".  Are they going to be removed in 
future releases?  Who decides when an architecture becomes mainstream?  Can you 
explain how this works?

I'm just feeling surprised to hear this.  The FSF seems to encourage the 
contribution of new ports to various GNU projects, and the GCC and Binutils 
projects have welcomed the addition of Xtensa ports.  (We're hoping to 
contribute our GDB port soon, too.)  Judging from the FSF's insistence on 
copyright assignments for GNU projects, I would think they would not like the 
idea of having separate add-ons for which they cannot enforce the GPL (since an 
add-on distributed by a 3rd party won't require a copyright assignment to the FSF).

What is the motivation for wanting to keep new ports as add-ons?  It seems like 
everyone benefits from collaborating on a single source base.  I'm sure Joe is 
willing to maintain the Xtensa port of glibc, so there should be minimal effort 
required by the core glibc developers, especially since the port-specific code 
can be so nicely separated.  Xtensa users and partners will certainly prefer to 
have the Xtensa port included in the main glibc sources.  Why do you want to 
reject contributions for new architectures?

I'd appreciate whatever explanations you can provide, and I hope you will 
reconsider this decision.  I've been really looking forward to getting our glibc 
port contributed -- it's disappointing to hear that it might not happen :-(

--Bob