Re: KDTRACE is gone?

On Wed, Nov 22, 2006 at 01:16:17PM -0500, Devon H. O'Dell wrote:
> 2006/11/22, Gavin Atkinson <gavin.atkinson_at_ury.york.ac.uk>:
> >On Wed, 2006-11-22 at 11:57 -0500, Kris Kennaway wrote:
> >> On Wed, Nov 22, 2006 at 05:14:00AM +0000, John Birrell wrote:
> >> > On Tue, Nov 21, 2006 at 09:09:21PM -0800, Cai, Quanqing wrote:
> >> > > Today when I tried to compile my customized kernel, I run "config"
> >> > > command and got this: unknown option "KDTRACE".
> >> > >
> >> > > Who can tell me what's going on?
> >> >
> >> > The KDTRACE option can't work the way I intended it to because
> >> > of licensing restrictions.
> >>
> >> By which John means that it could easily be included in FreeBSD under
> >> 'options KDTRACE' as before so that users could actually use DTRACE in
> >> FreeBSD.  However, it can't be included in GENERIC since the policy of
> >> FreeBSD is and always has been that GENERIC is a BSD-licensed kernel.
> >> With John's preferred change GENERIC would become under the CDDL.
> >
> >I think this is a shame - having used DTrace under Solaris a fair bit,
> >it's great to know that it is always available.  Often, the times I find
> >I need it are exactly the times when I can't reboot to add it into the
> >kernel.
> >
> >I haven't looked at the DTrace code at all - how much code does KDTRACE
> >add to the kernel?  Is it possible to write a specification for the code
> >and have somebody else write the kernel parts, like has been done with
> >GPL code in the past?
> >
> >[ I'm not volunteering, I'm just asking if it _could_ be done ]
> 
> Yeah, it could be done. However, the DTrace provider (providing BEGIN,
> END, and ERROR, and code that allows for other providers to hook in)
> is > 13,000 lines of code and comments, so it'd be a very non-trivial
> task.

Actually all that needs to happen is a) BSD licensed dtrace headers,
either relicensed or reimplemented, b) stubs for the functions that
return a suitable error if dtrace is not available, and c) dtrace
providers available as modules that can be loaded at runtime if
required.

a) is still the nontrivial part, but it's less work that fully
reimplementing the C code.

Of course, what could happen today is that DTRACE could be imported to
FreeBSD as a non-default option that any user could add to their
kernels but which just wouldn't ship with GENERIC.

Kris