Re: updating COMPAT_LINUX for linux 2.6.x support.

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, May 04, 2010 at 10:54:27AM +0000, Andrew Doran wrote:
> On Sun, May 02, 2010 at 07:32:09PM -0700, Chuck Silvers wrote:
> 
> >     I tried following the suggestion in PR 37437 (moving the ps_sigignore
> >     and ps_sigcatch fields from struct sigctx to struct sigacts, which is
> >     shared between linux threads), and I moved p_sigpend from struct proc
> >     to struct sigacts as well.  this, together with other fixes allows
> >     all of the netbsd libpthread regression tests to pass (except the one
> >     that also fails natively on linux), and gives much improved results
> >     on the LTP/posixtest tests.  I put my current diff (still larded with
> >     debug stuff and with linux stuff hardcoded instead of called through
> >     new emul callbacks) in:
> >     ftp://ftp.netbsd.org/pub/NetBSD/misc/chs/linux/diff.linux-nptl.4
> 
> I think there should be no reason for sigacts to have its own lock.
> I changed things so that cloned processes share the same p->p_lock.
> If you check fork1() to ensure that p->p_lock is always shared
> if any kind of signal state is shared by the child, then the sigacts
> lock can be removed.

I was wondering about that when I was doing the first version of this,
it wasn't clear what the sigacts lock really protected.


> >     before continuing down this path, I was wondering if it would be
> >     possible to move from the current way of supporting linux threads
> >     (each linux thread is a separate netbsd process, with extra sharing
> >     happening behind the scenes) to the native netbsd way (1 process with
> >     multiple LWPs)?  the only problem I can think of is that something
> >     might assume that linux thread IDs are globally unique, or that the
> >     thread ID of the original thread is the same as the process ID.
> >     but that seems a bit unlikely, since I don't see any place that the
> >     linux thread ID is used (thought I could easily have missed that).
> >     does anyone know of any reason why this wouuldn't work?
> 
> I wish we could go back in time and undo clone(), it makes a hash of the
> the process data structures.

well, I'll see if I can clean up the implementation a bit once I finish
with this NPTL stuff.

-Chuck