ARM NPTL support for uClibc

Jim Blandy jimb at codesourcery.com
Sun Aug 20 10:05:29 UTC 2006


"Joseph S. Myers" <joseph at codesourcery.com> writes:
> On Fri, 18 Aug 2006, Erik Andersen wrote:
>
>> On Fri Aug 18, 2006 at 08:25:41AM +0530, Sajeev Kesavan wrote:
>> > 
>> > May be a lot of testing might be required.
>> > 
>> > I see that Steve has got a point,as the main line merging may give
>> > problems to others if not testing exhaustly.
>> 
>> I can setup a separate mips+arm nptl merging branch if folks
>> would prefer using that as a staging area.  When this goes into
>> trunk, it will need to go in as a single well tested megapatch.
>> I hate megapatches, but this case calls for one.
>
> I think a new branch based on current trunk would be a good idea.  A 
> problem we found in doing the ARM work was that past merges to the 
> existing branch had been incomplete, including merging some files from 
> some revisions but not other files from those same revisions.  Subversion 
> doesn't provide the infrastructure to track which changes from which 
> revisions have been merged, so preparing a version based on trunk required 
> going through all the diffs line by line to distinguish NPTL changes from 
> diffs relating to changes not merged from trunk to the branch.  With a new 
> branch (which then only gets merges of whole revisions from trunk), it 
> would be easier to be sure that the changes on the branch, which then get 
> merged to trunk, are exactly the changes we want to merge to trunk and 
> don't accidentally revert other trunk patches.

As one of the two people who combed through the smallest trunk
vs. branch patch we could find and sorted out, by hand, the unmerged
stuff from the valuable work so we could have a patch relative to the
head of the trunk, I'd like to second this suggestion,
enthusiastically.  :)

We tested our patch on the ARM, configured with no threads, with the
old LinuxThreads (libpthread/linuxthreads.old), and with the new NPTL.
We didn't see the patch introduce any regressions.  (The new
LinuxThreads, libpthread/linuxthreads, doesn't build on the ARM, on
the unpatched trunk.)  There are full test suite details in my
original post.

The other kind of testing it needs is letting people actually pound on
it.  Again, a branch from the current trunk in the uClibc repository
would be ideal for this.



More information about the uClibc mailing list