Date: Thu, 26 Nov 2015 11:27:53 +0800 From: Julian Elischer <julian@freebsd.org> To: John Baldwin <jhb@freebsd.org>, freebsd-hackers@freebsd.org Cc: Adrian Chadd <adrian.chadd@gmail.com>, "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org>, "ken@freebsd.org" <ken@freebsd.org>, "Pokala, Ravi" <rpokala@panasas.com>, "scottl@freebsd.org" <scottl@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "imp@freebsd.org" <imp@freebsd.org> Subject: Re: Low-level trace-buffers in CAM Message-ID: <56567C39.6050002@freebsd.org> In-Reply-To: <1676097.ULW1yzL7e7@ralph.baldwin.cx> References: <A760883F-317D-46C9-AD7C-B8F5D96A49DA@panasas.com> <CAJ-Vmo=cfvA5k5rQt=KHpuCypHn2%2BfqYm8gBiG5eMYspBwfuNw@mail.gmail.com> <1676097.ULW1yzL7e7@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 25/11/2015 10:07 AM, John Baldwin wrote: > 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) I disagree. the advent of iSCSI makes this a natural thing. I would be very surprised if there were not already patches for wireshark to interpret scsi command blocks. I agree with you on this, it is a very logical way to do it. We may need to define a new form of interface for it but it makes perfect sense.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56567C39.6050002>