From owner-freebsd-current@FreeBSD.ORG Fri Sep 21 08:14:29 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55DD616A420 for ; Fri, 21 Sep 2007 08:14:29 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (unknown [IPv6:2001:618:400::50b1:e8f2]) by mx1.freebsd.org (Postfix) with ESMTP id DA8C113C458 for ; Fri, 21 Sep 2007 08:14:28 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [80.177.232.250] (herring.rabson.org [80.177.232.250]) by itchy.rabson.org (8.13.3/8.13.3) with ESMTP id l8L8ERIh028174; Fri, 21 Sep 2007 09:14:27 +0100 (BST) (envelope-from dfr@rabson.org) From: Doug Rabson To: John Birrell 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> Content-Type: text/plain Date: Fri, 21 Sep 2007 09:14:27 +0100 Message-Id: <1190362467.1627.13.camel@herring.rabson.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/4356/Fri Sep 21 08:19:47 2007 on itchy.rabson.org X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: Dtrace port status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2007 08:14:29 -0000 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?