Re: RFC: DTrace probes for debugging or testing in userland programs

*mumble* damnit jordan this requires libdispatch *mumble* -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: syslogd no longer listens (or sends) on a network socket

Michael Butler wrote in : im> On 12/19/16 12:12, Hiroki Sato wrote: im> > Michael Butler wrote im> > in : im> >

Re: RFC: DTrace probes for debugging or testing in userland programs

Adrian Chadd wrote in : ad> On 19 December 2016 at 16:04, Jordan Hubbard wrote: ad> > ad> > On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: ad> >

Re: RFC: DTrace probes for debugging or testing in userland programs

> On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: > > 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

Re: syslogd no longer listens (or sends) on a network socket

On 12/19/16 12:12, Hiroki Sato wrote: Michael Butler wrote in : im> It appears that SVN r309925 and onward no longer opens a network im> socket unless the command-line explicitly contains "-b :syslog"

Re: RFC: DTrace probes for debugging or testing in userland programs

On 19 December 2016 at 16:04, Jordan Hubbard wrote: > > On Dec 19, 2016, at 12:27 PM, Adrian Chadd wrote: > > 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 >

RFC: DTrace probes for debugging or testing in userland programs

Hello, > To be clear: my proposal is to replace only debug logging (i.e. for > developers), not the other logging in general, as the subject line > says. Although I agree that DTrace is not lightweight, I think > impact of just adding tracing probes is small. > > -- Hiroki I believe this

RFC: DTrace probes for debugging or testing in userland programs

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

RFC: DTrace probes for debugging or testing in userland programs

Hello, > You can try to compile a new syslogd, run it, and then attach > dtrace(1) to the syslogd process by "dtrace -q -CI./ > -s ./syslogd_trace.d -p `pgrep syslogd`" in the same directory. one thing that comes to mind is the lack of a way to actually fire these probes without running

Re: RFC: DTrace probes for debugging or testing in userland programs

Hi, 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

RFC: DTrace probes for debugging or testing in userland programs

Hi, I am trying to rewrite userland programs (especially daemons) to support userland DTrace probes to make it possible to trace the behavior by using dtrace(1). The purpose is to provide a consistent interface to enable/collect debug log and show internal states. A lot of daemons define

Re: Revision 309657 to stack_machdep.c renders unbootable system

On Fri, Dec 16, 2016 at 03:19:09PM -0800, John Baldwin wrote: > > So the hack in pause() is probably not as necessary now. In particular, I > think we only need it for thread0, not for other threads. The patch below > worked for me with SPEW's config: > > Index: kern_synch.c >

Re: syslogd no longer listens (or sends) on a network socket

Michael Butler wrote in : im> It appears that SVN r309925 and onward no longer opens a network im> socket unless the command-line explicitly contains "-b :syslog" :-( im> im> This also stops one syslog