ARM NPTL support for uClibc

[Peter S. Mazinger]

On Mon, 14 Aug 2006, Jim Blandy wrote:

> 
> "Steven J. Hill" <sjhill at realitydiluted.com> writes:
> > As I plainly stated last week, no NPTL will be allowed into the mainline,
> > only on the branch. The decision still stands.
> 
> You're referring to this:
> 
> http://uclibc.org/lists/uclibc/2006-August/016086.html
> 
> I don't see a solid reason uClibc should wait until the end of the
> year to have NPTL support, if an acceptable patch is available sooner.
> Inclusion of NPTL in the trunk should be determined by public,
> technical criteria agreed to by the uClibc development community.
> When any implementation is available that meets those criteria,
> according to the uClibc maintainers willing to review the code, it
> should be included in the trunk right away.  To spend from now through
> December tracking trunk changes doesn't make sense.
> 
> We'd suggest the following criteria:
> 
> - Does not break existing LinuxThreads and no-threads configurations,
>   as judged by the test suite.

Lets expand those testsuites with all that is available in glibc at least, 
many of them won't pass in linuxthreads_old, but that could be guarded 
against, the new linuxthreads is based on linuxthreads current cvs (not 
yet working though) but should not be left out of the game due to the 
need for 2.4 kernels.

> - Works well enough on at least one target that any remaining fixes
>   will probably not require major infrastructure changes.
> 
> - Meets established uClibc coding conventions and good coding practice.

Ok with me, although not a developer anymore, my oppinion does not count ...

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2