Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Support for memory-backed file description #24
This abstracts the creation of the temporary ELF file to allow for two possible approaches:
The new approach his beneficial for two reasons:
libusdt does something similar, where it just valloc's directly into the processes address space, so there is no need for a temporary file to clean up.
Overall, I find that doing tho whole thing in memory and having it be automatically cleaned up with the process's lifecycle is a bit more elegant.
The drawbacks to this approach are:
I think the drawbacks are mitigated by hiding it behind a preprocessor macro check, as the behavior remains unchanged. In the future, hopefully once iovisor/bcc#2314 is in a major bcc release, we could remove the macro and default to a memory-based shared object, falling back to temporary file if we detect that
Attaching a probe (
And if we check out the file descriptors for the process:
So if we check for elf notes on that fd:
And if I run tplist -p
Or use my latest branch of bpftrace with wildcard USDT support:
I can attach to the probe by that path, or by PID (using my bcc branch)
If I disable the provider, the file descriptor is closed and the elf file is removed from the memory map.
Awesome! I was not aware of
IMO memfd should be the default, and we should fall back to tmpfs only if necessary. Also, it might be useful to have a way to choose which filesystem to use during runtime?
@mmarchini great - i'll remove the macro then, and make it the default, falling back only if we can't find the necessary call.
to do this I'll need to add a new method signature for providerLoad probably, to force using /tmp files. If the original interface is called, it will go through the fallback path.
I'll modify this PR accordingly :)