Low-level trace-buffers in CAM

[Pokala, Ravi]

-----Original Message-----


From: Adrian Chadd <adrian.chadd at gmail.com>
Date: 2015-10-26, Monday at 19:52
To: Ravi Pokala <rpokala at panasas.com>
Cc: "freebsd-geom at freebsd.org" <freebsd-geom at freebsd.org>, "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>, "ken at freebsd.org" <ken at freebsd.org>, "imp at freebsd.org" <imp at freebsd.org>, "scottl at freebsd.org" <scottl at freebsd.org>
Subject: Re: Low-level trace-buffers in CAM

>Hi,
>
>ok. So this is where I create work for people. :-)

Tsk, tsk! *I* would never do such a thing! ;-)

>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'm having trouble parsing that - it's been a long day. You're talking about creating a generic in-kernel ring-buffer implementation, that we could leverage for (CAM tracing | KTR | whatever)? Like we did for various list and queue types in <sys/queue.h>? That's a good idea, but I go cross-eyed any time I look too closely at all the preprocessor-fu in there. :-)

-Ravi

>-a