Move kern_ctf to the dtrace module?

[Paul Goyette]

Currently, if you include KDTRACE_HOOKS in your kernel, we automatically
include src/sys/kern/kern_ctf.[co] in the resulting kernel.

kern_ctf defines only one global symbol, mod_ctf_get(), according to the
generated netbsd.map file, and there are no references anywhere else in
the kernel to this routine; the only reference is within the sub-module
dtrace_fbt.kmod

I would like to suggest that kern_ctf be removed from the kernel, and
added to the dtrace_fbt module. And, since kern_ctf references stuff in
net/zlib.c, the dtrace_fbt module should depend on zlib module. And
finally, the ktrace_hooks dependency can be removed from the zlib.c line
in net/files.net

The bottom line is that zlib code won't be included in kernels that
don't need it, yet will still be available when using dtrace (which is
only available as a module).


If I don't see any significant objections, I'll post diffs in a day or
so before making any commits.



+------------------+--------------------------+------------------------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+

[Paul Goyette]

On Mon, 12 Sep 2016, Paul Goyette wrote:

> Currently, if you include KDTRACE_HOOKS in your kernel, we automatically
> include src/sys/kern/kern_ctf.[co] in the resulting kernel.
>
> kern_ctf defines only one global symbol, mod_ctf_get(), according to the
> generated netbsd.map file, and there are no references anywhere else in the
> kernel to this routine; the only reference is within the sub-module
> dtrace_fbt.kmod
>
> I would like to suggest that kern_ctf be removed from the kernel, and added
> to the dtrace_fbt module. And, since kern_ctf references stuff in
> net/zlib.c, the dtrace_fbt module should depend on zlib module. And finally,
> the ktrace_hooks dependency can be removed from the zlib.c line in
> net/files.net
>
> The bottom line is that zlib code won't be included in kernels that don't
> need it, yet will still be available when using dtrace (which is only
> available as a module).
>
>
> If I don't see any significant objections, I'll post diffs in a day or so
> before making any commits.

Diffs are attached here.

I plan to commit within the next couple of days...

[Paul Goyette]

It was suggested to me in private Email that perhaps the file
sys/kern/kern_ctf.c should be moved out of src/sys and into "the
module's [source] directory."

I'd rather not move the file into src/external/..../dtrace/dev/fbt/
because kern_ctf.c and the existing file both include some headers with
the same name, but expecting different files to be included! (dtrace
provides its own versions of sys/kobj.h and sys/kobj_impl.h headers.)

We generally don't put actual source files into src/sys/modules/* but it
might be appropriate in this case.

Either way, I'm not really happy about using file-specific CPP_FLAGS in
sys/modules/dtrace/fbt/Makefile but the only other way to make this work
would be to create a dtrace_fbt_ctf module, on which dtrace_fbt would
depend. This introduces an additional layer of module-autoload, and
would occupy a slightly larger in-memory footprint, but should not have
any other impact.

So, questions to be answered:

* Where should sys/kern/kern_ctf.c reside?
* Should kern_ctf.c be a separate (sub)module?

Any thoughts?