This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: How to submit large patch for xtensa-linux?
- From: Michael Eager <eager at mvista dot com>
- To: Bob Wilson <bwilson at tensilica dot com>
- Cc: libc-alpha at sources dot redhat dot com, Joe Taylor <joe at tensilica dot com>
- Date: Tue, 11 May 2004 14:40:39 -0700
- Subject: Re: How to submit large patch for xtensa-linux?
- Organization: MontaVista Software
- References: <40A11EB9.2060803@tensilica.com>
Bob Wilson wrote:
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.
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 don't think that using add-on is appropriate for adding a new arch.
Different configuration options are required to build different
architectures. There are differences in the way that the sources
are organized, which results in differences in builds for architectures
which are "built-in" and "add-on".
My interest is in seeing a single consistent and reproducable structure
for glibc, which permits all architectures to be built in the same way.
Consitent builds will result in improved quality.
Add-ons are appropriate, in my opinion, for features which apply to
all architectures.
Further, I believe that there is benefit in the community if all
of the architecture support is available in the main source tree
rather than only a configuration snippet and perhaps a reference to a
web site. Code which is in the source tree has a higher probabilty
of beeing maintained and compatible with other changes, while sources
stored elsewhere will inevitably become out of date.
--
Michael Eager eager@mvista.com 408-328-8426
MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA 94085