Date: Fri, 21 Sep 2007 09:14:27 +0100 From: Doug Rabson <dfr@rabson.org> To: John Birrell <jb@what-creek.com> Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status Message-ID: <1190362467.1627.13.camel@herring.rabson.org> In-Reply-To: <20070921081106.GA18488@what-creek.com> References: <6385B28C-01D1-459A-9543-E36C89C7F36E@xview.net> <20070920203413.GA13737@what-creek.com> <46F367E0.4000300@freebsd.org> <20070921070347.GA17990@what-creek.com> <1190360869.1627.9.camel@herring.rabson.org> <20070921081106.GA18488@what-creek.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1190362467.1627.13.camel>