Low-level trace-buffers in CAM

[Stanislav Sedov]

> On Nov 24, 2015, at 6:07 PM, John Baldwin <jhb at 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