Date: Tue, 27 Oct 2015 04:21:58 +0000 From: "Pokala, Ravi" <rpokala@panasas.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "ken@freebsd.org" <ken@freebsd.org>, "imp@freebsd.org" <imp@freebsd.org>, "scottl@freebsd.org" <scottl@freebsd.org> Subject: Re: Low-level trace-buffers in CAM Message-ID: <B32BA835-EF8D-4A90-B4EB-A7E69AA78F07@panasas.com> In-Reply-To: <CAJ-Vmo=cfvA5k5rQt=KHpuCypHn2%2BfqYm8gBiG5eMYspBwfuNw@mail.gmail.com> References: <A760883F-317D-46C9-AD7C-B8F5D96A49DA@panasas.com> <CAJ-Vmo=cfvA5k5rQt=KHpuCypHn2%2BfqYm8gBiG5eMYspBwfuNw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----Original Message----- From: Adrian Chadd <adrian.chadd@gmail.com> Date: 2015-10-26, Monday at 19:52 To: Ravi Pokala <rpokala@panasas.com> Cc: "freebsd-geom@freebsd.org" <freebsd-geom@freebsd.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "ken@freebsd.org" <ken@freebsd.org>, "imp@freebsd.org" <imp@freebsd.org>, "scottl@freebsd.org" <scottl@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B32BA835-EF8D-4A90-B4EB-A7E69AA78F07>