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: > > 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>