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>