Date: Thu, 27 Sep 2007 09:37:44 -0400 From: John Baldwin <jhb@freebsd.org> To: John Birrell <jb@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 126859 for review Message-ID: <200709270937.44791.jhb@freebsd.org> In-Reply-To: <200709270957.l8R9vv81089001@repoman.freebsd.org> References: <200709270957.l8R9vv81089001@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709270937.44791.jhb>