Date: Wed, 25 Nov 2015 16:20:50 -0800 From: Stanislav Sedov <stas@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, 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: <EE59EA24-B500-4AD4-8604-C32323C5B887@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 Nov 24, 2015, at 6:07 PM, John Baldwin <jhb@freebsd.org> wrote: >=20 > 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) This is an interesting idea! Wireshark access does not sound too = bizzare actually -- wireshark supports FC protocol parsing as well as generic = SCSI dissecting. This is immensely useful when debugging FC communication problems, and I can imaging it would be helpful in other situations as = well. On the other hand, if we are talking about generic ring buffer logger with userland access -- isn't DTrace essentialy that? DTrace provides a very efficient data collection framework with the filtering = capabilities not unlike BPF. We can already access most of the information the new = proposed framework hopes to provide without any kernel code modifications = (including raw CDBs), and by adding the missing static DTrace probes we can provide an easy access to the same data both BPF and an ad-hoc framework would = while also giving a flexibility of accessing auxiliary data without code = modifications. This will allow for a pure-userland pcap generation as well (or any kind = of custom reporting). Something to think about as well. -- Stanislav Sedov ST4096-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE59EA24-B500-4AD4-8604-C32323C5B887>