Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Sep 2007 21:57:09 +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:  <20070921215709.GA23720@what-creek.com>
In-Reply-To: <1190362467.1627.13.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> <20070921081106.GA18488@what-creek.com> <1190362467.1627.13.camel@herring.rabson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 21, 2007 at 09:14:27AM +0100, Doug Rabson wrote:
> 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?

I am going to allocate the DTrace part like the scheduler stuff
gets allocated - at the end using the uma zone calls. That way
it will really be opaque. When the DTrace modules want to get at
their private variables they can just offset the thread pointer.
Unlike the td_sched, there won't be a pointer in the visible
struct thread to retain binary compatibility with the release.

--
John Birrell



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070921215709.GA23720>