[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: updating COMPAT_LINUX for linux 2.6.x support.
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:
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.
> 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.
Main Index |
Thread Index |