posix threading plans

[Carmelo AMOROSO]

Mike Frysinger wrote:
> On Sunday 06 May 2007, Steven J. Hill wrote:
>   
>> Daniel Jacobowitz wrote:
>>     
>>> I don't think revisiting the unfortunate circumstances is going to get
>>> us anywhere.  Is there some way we can move on, and end up with a
>>> unified port?  I don't care how we end up with an up-to-date branch as
>>> long as we do; from my experience with long-running branch development
>>> I tend to think that Joseph is right and that rebasing on top of a
>>> clean trunk branch is the way to go.
>>>       
>> Do whatever you guys want and I will deal with it.
>>     
>
> this isnt exactly a helpful stance to take ...
>
> so what i'm hearing is:
>  - mips/nptl only exists in branches/uClibc-nptl/
>  - the uClibc-nptl branch is in an unrecoverable state compared to trunk
>  - arm/nptl exists against trunk
>  - sjhill's work and codesourcery's work have some design decisions that need 
> to be reconciled
>
> Carmelo: what's the status of the SuperH stuff ?
>   
Hi Mike,
here it's the SuperH (specifically sh4 core) status:
- code base is uClibc-nptl branch: svn revision 17694 (Feb 2007)
                                                    **** BUT ****
- all patch I've already posted to the ML and committed to trunk (by 
you, Jocke, and others) are included
   into nptl port (some of them are sh4 specific, some other general)
- the build system is essentially trunk based (i.e. we use 
libc-y/libc-shared-y/libc-static-y while nptl branch
  currently is using the old implementation based on libc-so-y)
- the common TLS part of the dynamic linker differs from the current 
nptl branch version as I've already
  highlighted in a old post (see message: 
http://www.uclibc.org/lists/uclibc/2006-August/016263.html),
  and seems the Codesourcery patch address this similarly.
- the design I applied to handle cancellation point differs from the 
mips solution,
  and is essentially based on Codesourcery patch (see the message above)
- Some fixes committed to trunk have already merged with our nptl port

so, even if we have a few patches suitable to produce, starting from the 
official nptl branch (as checked out from SVN),
a complete nptl port for sh4, I'd prefer starting from a freshen branch 
based on latest trunk.
This should avoid in my opinion any extra effort and bring into the nptl 
work all the latest work done on trunk.
> so it would seem the best way forward is to rebranch trunk and move 
> mips/arm/sh to that ... then once that has settled, we can move that branch 
> back to trunk ... i have some things i'd like done for trunk, but nothing 
> critical so it can wait (build system changes)
>
> seems like it'd be sane to bring at least Joseph and Carmelo on board ?
>   
Thanks Mike,
I'll try to do the best I can... should I need a svn account with write 
rights?

Regards,
Carmelo
> -mike
>