Low-level trace-buffers in CAM

[Julian Elischer]

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.