Re: Dtrace port status

From: Doug Rabson <dfr_at_rabson.org>
Date: Fri, 21 Sep 2007 09:14:27 +0100
On Fri, 2007-09-21 at 08:11 +0000, John Birrell wrote:
> On Fri, Sep 21, 2007 at 08:47:48AM +0100, Doug Rabson wrote:
> > For something like this example, I would suggest putting those fields in
> > a separate structure declared in a CDDL licensed file and then embed
> > that structure in our thread. I'm guessing not all of your problems are
> > quite this tidy though.
> 
> Then it can't be in GENERIC by default. That cuts out one of the
> major DTrace features - you are supposed to be able to run DTrace
> at any time, even if it involves loading kernel modules (which
> Solaris does on demand).
> 
> For the example I used, every thread has to have the space allocated
> even though the DTrace modules aren't loaded. And to do that it
> has to be entirely BSD licensed code. The DTrace modules themselves
> can be CDDL'd just like kernel modules may be GPL'd. So there
> can't be any include file tricks. If it's code that has to be in the
> GENERIC kernel, then all the headers have to be BSD licensed.

I see your problem. How about adding a char td_dtrace_reserved[some
number] which can be cast into a dtrace structure in dtrace code but
which is opaque to normal kernel code?
Received on Fri Sep 21 2007 - 06:14:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:17 UTC