Date: Fri, 21 Sep 2007 08:11:06 +0000 From: John Birrell <jb@what-creek.com> To: Doug Rabson <dfr@rabson.org> Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status Message-ID: <20070921081106.GA18488@what-creek.com> In-Reply-To: <1190360869.1627.9.camel@herring.rabson.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Birrell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070921081106.GA18488>