gnn@ to create a mailing list associated with OpenDTrace
gnn@ has finished
markj@ has put a change to USDT relocations (https://reviews.freebsd.org/D9374) that addresses the use of undefined behavior in the linker. rwatson@ points out that there are several folks on the project with linker experience at the moment.
domagoj@ has looked into how to better integrate his virtual machine RFD with the work being done by Graeme on CADETS. domagoj@ would like to eliminate the need for zookeeper to identify the nodes. rwatson@ says that we are more interested in getting the distributed DTrace thing correct. For the purposes of hypervisors rwatson@ does not think we should not converge these two things but take advantage of the fact that hypervisors do not have the communication issues that networked systems do.
There remains the question of where to keep the probe list, in the kernel or in user space. Domagoj suggests that it can remain in the kernel in a matrix. rwatson@ suggests that we experiment with the simplest possible system and that points us back towards the kernel.
James asks about updating scripts on the fly. rwatson@ says that this is done in the DDTrace system by updating the DIF on the fly. The question is bast asked of Graeme.
gnn@ says he'll be submitting RFDs for if() and do/while().
gnn@ has imported the lastest xnu and macos-dtrace tarballs into the opendtrace repos
shrikanth@ wants to talk about CTF sections becoming huge when dealing with more embedded systems. shrikanth@ and the Juniper folks are looking at being able to load the CTF sections on demand. markj@ says that this should be doable with libproc but that this has not yet been MFC'd to STABLE/11. James says that they'd like to move to DWARF since all their other tools are DWARF but that has only been a prototype. There is a CTF compressed flag but no one knows is the sections are actually compressed or not.
rwatson@ mentions that emaste@ is working on libelf like things and gnn@ will talk to him about CTF features in that arena
Domgaoj asks about having anonymous tracing switch to using a file once we've gone multi-user. markj@ thinks we'll need a filesystem to make this all work so there is a question of where to switch over.
We'd like to bring over the stack tracing for Python. Isilon does have patches for this, but they're invasive.
gnn@ will ask Graeme about the patches to libdtrace that might still be outstanding.
Damogoj is looking at instance local variables.
Those with access to Phabricator should join the DTrace group therein