Friday 27 July 2012

PID provider...update

Some good news...I wrote the other day that the PID provider now
"works" (for various definitions of 'works'). Having done that,
of course reports came in on the features I had missed.

I've spent a fair bit of time ironing out portability issues
introduced in the latest releases - affecting older kernels, and
lots of GPL-only issues, which are nearly all worked around.

The GPL issues are interesting; I try to stay away from the politics.
The GPL and Linux has its own world to look after, and what with
legal implications of license pollution, they need to be careful
of defending themselves. DTrace comes under the CDDL. From my perspective,
its a bunch of source code, and people are welcome to it. But
the CDDL can give rise to closed source derivatives, which is a shame,
but understandable.

Anyhow, one of the key issues was related to "dtrace -c cmd" not working.
I hadnt tested that.

I also found that the user land dtrace would hang when trying to
attach to a suspended process (eg a backgrounded app asking for terminal
input).

I decided I had to move past the ptrace() interface - its too
limiting to allow dtrace to do what it wants.

A while back I had created the /dev/dtrace_ctl driver - it was designed
to emulate the Solaris /proc interface, but I shied away from doing this,
because it would have been a distraction - attempts to emulate lots
of corner cases from Solaris, made difficult, because the Linux
kernel is not the Solaris kernel. This was a good move. (And someone
suggested I not do this, so it wasnt my idea).

What I did do was resurrect the code in driver/ctl.c, and make it into
a read/write interface for processes - doing what ptrace() does, but
without the semantics of ptrace. Switch dtrace to use this interface
instead of ptrace() immediately fixed the stopped-process problem and
allows the "dtrace -c cmd" to work.

I have some bugs to fix and another kernel/GPL issue to resolve, but
hope to release later today or over the weekend.

I had put off doing the PID provider, because I knew it was going
to be difficult - but I was lucky. The original Solaris code works
a treat, and the only problem was me reading too much into the complex
code.

More later....

Post created by CRiSP v11.0.10a-b6436


No comments:

Post a Comment