Re: LWP resume and suspend ptrace(2) API

[christos%astron.com@localhost (Christos Zoulas)]

In article <897028fd-f18a-9ec4-bd5f-3930f40dcaca%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>
>There is one nit... this code (at least to my tests) cannot unstop a
>thread that was created by a tracee with LWP_SUSPENDED.
>
>http://netbsd.org/~kamil/patch-00028-pt_suspend-pt_resume.txt-resume2
>(man pages will be applied in next patch)
>
>Are there needed more actions to be performed? I had some trouble to
>call lwp_continue from ptrace(2) and not managed to make it work.

Write a test and I will take a look.

>There is undocumented behavior that passing LWP ID when a process has
>single thread results in ignoring the passed value and detecting the
>proper one. For example this code will always return proper value for a
>single-threaded process, no matter what the LWP ID is.
>
>ptrace(PT_GETREGS, child, &r, 123)
>
>Can I streamline it and remove fallback to an existing LWP? I don't see
>a "feature" in this "bug".

I think this was for backwards compatibility with unthreaded code. If
it bothers you, remove it. It does not matter since the pthread(2) consumers
are few, and since you are changing already a lot in interface...

>Can a user-space process contain in-kernel threads? Is this used for
>compat with old userland? I was thinking about switching branch for
>in-kernel-thread to KASSERT(). It would make the code cleaner.

What does that mean exactly? Do you mean kernel lwp's that are dedicated
to kernel tasks, instead of kernel lwp started from userland to be used
as in-process threads? You mean the LW_SYSTEM tests? Look in kern_lwp.c,
there are KASSERTS for that already...

>Thank you for the initial review.

You are always welcome :-)

christos