-----Original Message-----
From: John Baldwin <j...@freebsd.org> Date: 2015-11-24, Tuesday at 18:07 To: "freebsd-hack...@freebsd.org" <freebsd-hack...@freebsd.org> Cc: Adrian Chadd <adrian.ch...@gmail.com>, Ravi Pokala <rpok...@panasas.com>, "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org>, "k...@freebsd.org" <k...@freebsd.org>, "sco...@freebsd.org" <sco...@freebsd.org>, "freebsd-s...@freebsd.org" <freebsd-s...@freebsd.org>, "i...@freebsd.org" <i...@freebsd.org> Subject: Re: Low-level trace-buffers in CAM >On Monday, October 26, 2015 09:52:25 PM Adrian Chadd wrote: >> Hi, >> >> ok. So this is where I create work for people. :-) >> >> Something I've been tossing up for quite some time is a generic >> version of this that exposes a ring-buffer of entries back to >> userland. For things like this, things like ALQ/KTR, etc, it's all >> just a producer-consumer ring based thing. You don't even care about >> multiple readers; that's a userland thing. >> >> So, I'm a big fan of this. I did this for the ath driver to debug >> descriptors and register accesses and it was a big help. I'd really >> like to see a more generic way we can expose this data in an efficient >> manner! > >I actually think bpf might not be a bad interface (as I suggested at >the vendor summit), though I think we need a way to enumerate BPF taps >that aren't network interfaces (if we fix this then we can remove the >fake USB ifnets and make glebius@ happy as well). Then you can look >at these things in wireshark (which would be a bit bizarre perhaps) Wait, you're talking about using Berkeley Packet Filter in the context of storage command tracing? That's giving me a major parse error... -Ravi >-- >John Baldwin _______________________________________________ freebsd-geom@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-geom To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
