Determining the path to the kernel modules loaded

Now that FreeBSD 7.0 and 6.3 are well on their way through release engineering, it's time to prepare to add things for DTrace that have only been in p4 until now.

First up is a change to kldstat(2) to return the path to the kernel module loaded.

On FreeBSD this is needed because we don't have an object file system like Solaris does.

DTrace, or more specifically, libdtrace, needs to get access to the kernel module file because it contains the CTF data.

A problem with doing this is that the path reported was the one relate to the user's root file system and the file system mount points at the time the module was loaded.

Starting the port again

Now that I've changed my approach, I think I'll start the port again from scratch, using my previous work as a reference.

This will give me a chance to describe what the port required.

I'll start with FreeBSD-CURRENT as of today's cvsup.

Is DTrace on FreeBSD really dead?

Not much has happened on the port of DTrace to FreeBSD lately.

I've been trying to convince Sun to solve the license problems that have been preventing the DTrace hooks from being added to the FreeBSD kernel. I'm disappointed to report that I've had no luck.

Sun's position is that there is nothing stopping FreeBSD from shipping the work I've already done. They say that the CDDL (wiki) isn't viral and that they have no entrenched position on this. I beg to differ.

I've created this blog to (hopefully) explain where the problems lie.

So, I'm here on the web as a blogger to say a few things, some of which will be unpopular.

I'll start by saying that DTrace on FreeBSD is not dead, even if it may have smelled so for the last 6 or so months.


A new direction for FreeBSD with DTrace

This post marks a significant emotional event. My own blog in cyber space.