On Mon, 18 Jul 2022, 1:54am, Daniel Wagner wrote: > Hi > > [adding Steven Rostedt] > > On Thu, Jul 14, 2022 at 11:02:23PM -0700, Nilesh Javali wrote: > > From: Arun Easi <aeasi@xxxxxxxxxxx> > > > > Adding a message based tracing mechanism where > > a rotating number of messages are captured in > > a trace structure. Disable/enable/resize > > operations are allowed via debugfs interfaces. > > I really wonder why you need to this kind of infrastructure to your > driver? As far I know the qla2xxx is already able to log into > ftrace. Why can't we just use this infrastructure? > Many times when a problem was reported on the driver, we had to request for a repro with extended error logging (via driver module parameter) turned on. With this internal tracing in place, log messages that appear only with extended error logging are captured by default in the internal trace buffer. AFAIK, kernel tracing requires a user initiated action to be turned on, like enabling individual tracepoints. Though a script (either startup or udev) can do this job, enabling tracepoints by default for a single driver, I think, may not be a preferred choice -- particularly when the trace buffer is shared across the kernel. That also brings the extra overhead of finding how this could be done across various distros. For cases where the memory/driver size matters, there is an option to compile out this feature, plus choosing a lower default trace buffer size. Regards, -Arun
