nptl refactoring; nacl port

[Roland McGrath <roland at hack dot frob dot com>]

As part of my ongoing work on the NaCl port (NaCl == Google Native Client),
I'm now embarking on porting pthreads (i.e. nptl/).  This will be the first
time the NPTL code gets used in a non-Linux port.  There are lots of
Linuxoid assumptions scattered about the code, which I will be teasing
apart.  There is also lots of code that doesn't really assume Linux, but
just assumes that there is a futex facility.  As NPTL is fundamentally
based on the futex facility, I don't think there will ever be an attempt to
port it to a system without such a facility.  (NaCl has a futex facility
and the Hurd's GNU Mach might grow one someday.)

There are a bunch of things under nptl/sysdeps/ that don't seem like they
are placed where they really ought to be.  Many of these don't affect
immediate work on non-Linux NPTL ports, but they are just wrong in
principle.  For example lots of nptl/sysdeps/pthread/ is stuff that is not
specific to NPTL in any way, it's just dependent on the public pthreads
API; those things should move to sysdeps/pthread/ (outside of nptl/).  I'll
start moving these around just for cleanliness purposes as the whim takes
me.  But that's not my priority.

The ones of practical concern are things under
nptl/sysdeps/unix/sysv/linux/ that are not actually Linux-specific at all.
For example lowlevellock.c depends only on lowlevellock.h's lll_futex_*
internal API, not on any Linux-specific APIs.  I had originally thought it
made sense to start moving things into nptl/sysdeps/futex/.  (Then both
sysdeps/unix/sysv/linux/Implies and sysdeps/nacl/Implies would contain
futex.)  But on further reflection, I don't think there is any reason for
"has futex" to be a sysdeps category.  Rather, nptl/ as a whole is only for
configurations that have futex, so things like lowlevellock.c just belong
in nptl/ directly.  So I think that's the kind of moves I'll make.

Does that sound reasonable?


A somewhat related matter is how I will or should eventually integrate my
NaCl port.  I've been working on it for some time as an add-on.  Of course,
my intent has always been that this will eventually be integrated into the
main tree, but it's not very close to finished yet.  I've been abusing the
glibc.git repo to hold my add-on's tree too: the roland/nacl-port "branch"
is not actually a branch at all, but a separate tree for the add-on.  I
don't want to keep a ChangeLog or particularly useful commit log messages
while the work is in progress.  (But certainly everyone is free to look at
what's there and give me feedback any time!)  Of course, once it is in a
fully working state and goes in, then further changes will follow all the
usual procedures.

As I do the nptl refactoring, there will likely be cases where to make
sense of how I'm organizing things folks will want to see the corresponding
new sysdeps/nacl code.  I'll always push the latest add-on changes to
roland/nacl-port at the same time I post main tree changes for review (and
push them to some roland/* branch) so folks can see them there.  But if
people would prefer that I just start integrating the nacl-port bits into
the main tree before it's all done, I can do that instead.  Opinions?


Thanks,
Roland