RFC: DTrace probes for debugging or testing in userland programs

Domagoj Stolfa domagoj.stolfa at gmail.com
Mon Dec 19 20:47:26 UTC 2016


Hello,

> I'd love to see a unified-ish logging API for FreeBSD applications. I
> always end up reusing some C code I have here that I based on some
> Squid style logging API in ages past. I could always polish it up and
> put it up for review.
>
> I'm not a big fan of requiring dtrace to use it though. On a lot of
> the embedded systems dtrace varies from "it's very big" through to "we
> don't have enough RAM/flash to do this".

DTrace indeed is very heavyweight, this could be an opt-in kind of thing
compile time, hidden somewhere in the logging system employed.
Personally, I think that keeping the diffs in the actual daemons to the
bare minimum(1-2 LoC) should be one of the priorities. Additionally, the
logging system should by default be lightweight, with compile time
options to change the actual logging method(a simple log, DTrace, ...).

> So although I like the sentiment, I don't think using dtrace for
> program logging is the right answer.  I like what apple did to wrap
> the program logging stuff so people didn't just write their own
> libraries (hi!) and so there's a unified-ish way to interact with
> apple programs. I think we could do with that.

This sounds like a pretty clean solution, and the logging method could
be hid somewhere deep in there. I would personally like to see an option
where I could pick DTrace for logging, as it allows for some interesting
scripts to be written, however I tend to agree that this should not be
the default.

-- 
Best regards,
Domagoj Stolfa.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20161219/410f87ea/attachment.sig>


More information about the freebsd-current mailing list