From owner-p4-projects@FreeBSD.ORG Thu Sep 27 13:38:08 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id C1E4B16A4A1; Thu, 27 Sep 2007 13:38:07 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB4916A4D4; Thu, 27 Sep 2007 13:38:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 70C4A13C44B; Thu, 27 Sep 2007 13:38:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 092BB1A4D9A; Thu, 27 Sep 2007 06:38:07 -0700 (PDT) From: John Baldwin To: John Birrell Date: Thu, 27 Sep 2007 09:37:44 -0400 User-Agent: KMail/1.9.7 References: <200709270957.l8R9vv81089001@repoman.freebsd.org> In-Reply-To: <200709270957.l8R9vv81089001@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709270937.44791.jhb@freebsd.org> Cc: Perforce Change Reviews Subject: Re: PERFORCE change 126859 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 13:38:08 -0000 On Thursday 27 September 2007 05:57:57 am John Birrell wrote: > http://perforce.freebsd.org/chv.cgi?CH=126859 > > Change 126859 by jb@jb_freebsd1 on 2007/09/27 09:57:33 > > To avoid infecting the GENERIC kernel with Sun's CDDL, the > additional fields that would have just been added to > 'struct thread' have to be made opaque. > > The easiest way I can think of to do this is to allocate > extra space when the thread structure is allocated. The > value of KDTRACE_THREAD_SIZE is the extra space required. > It is then left to the DTrace modules to do the pointer > arithmetic to offset 'struct thread *td' to point to the > DTrace-specific thread data. > > I get conflicting opinions about what is protected by > copyright and what is not. None of these opinions come > from lawyers. However, even if they were from lawyers > they would still just be opinions which have no legal > precedent. > > I am accused by one person from Sun of "effectively making > up [my] own law, and then complaining that [I'm] > forcing [myself] to follow it". > > I am also accused of making Sun a "straw man" and that I'm > "more interested in having the problem than solving it". > > I have asked Sun for legal clarity. It's notable that, > of all the emails I've received from Sun, exactly ZERO > have come from anyone with any legal responsibility in > Sun. > > So this is the way forward... obfuscate the bloody code > so that it doesn't directly reference any CDDL code. > > And life goes on. How about doing something like this: struct thread { ... char td_dtrace_data[KDTRACE_THREAD_SIZE]; }; Then you don't have to allocate it separately or maintain specific offsets variables, etc. and using it can become easier. In the dtrace code itself you could have: struct thread_dtrace { /* per-thread dtrace fields */ void *foo; int bar; struct blah baz; }; CTASSERT(sizeof(struct thread_dtrace) <= KDTRACE_THREAD_SIZE); ... int some_dtrace_func(struct thread *td, ...) { struct thread_dtrace *dt; dt = (struct thread_dtrace *)td->td_dtrace_data; ... } -- John Baldwin