lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 06 Dec 2010 19:47:43 -0500 From: Steven Rostedt <rostedt@...dmis.org> To: Arnd Bergmann <arnd@...db.de> Cc: Charles Manning <manningc2@...rix.gen.nz>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, Frederic Weisbecker <fweisbec@...il.com> Subject: Re: [PATCH 3/8] Add yaffs2 file system: guts code On Tue, 2010-12-07 at 00:03 +0100, Arnd Bergmann wrote: > > > > yaffs_trace(YAFFS_TRACE_BUFFERS, > > > > "Out of temp buffers at line %d, other held by lines:",line_no); > > > > for (i = 0; i < YAFFS_N_TEMP_BUFFERS; i++) > > > > yaffs_trace(YAFFS_TRACE_BUFFERS," %d ", dev->temp_buffer[i].line); > > > > yaffs_trace(YAFFS_TRACE_BUFFERS, "\n"); > > > > > > > > Would that be OK? > > > > > > > > I am loath to have to pull out useful code then plug it back in again. > > > > > > I don't think the yaffs_trace() function would be much better than the T() > > > macro, I was talking more about the fact that you have your own nonstandard > > > tracing infrastructure than the ugliness of the interface. > > > > > > The point of pulling it out now would be force you to rethink the > > > tracing. If you think that you'd arrive at the same conclusion, just > > > save the diff between the code with and without tracing so you can > > > submit that patch again later. > > > > > > Having some sort of tracing is clearly useful, but it's also not essential > > > for the basic yaffs2 operation. We want to keep a consistent way of > > > presenting trace points across the kernel, so as long as you do it > > > differently, your code is going to be viewed with some suspicion. > > > > > > Please have a look at how ext4, gfs2 and xfs do tracing. > > > > Looking in Linus' tree, all of those contain custom tracing of the form I > > propose. > > Hmm, yes I guess that's right... > > I was specifically talking about the include/trace/* based trace events > as something to look at, not the random printk based tracing stuff. > Maybe Steven or Frederic can give some more insight on that. > What are all those T() functions? Some look like they should be replaced with printk(KERN_* "") functions, some others for tracing (I guess the ones with YAFFS_TRACE_TRACING). ext4, gfs and xfs all have converted to the TRACE_EVENT() methods. When you have this, you get tracing for free. The work with both ftrace and perf. You can look at the samples/trace_events/ code for examples. Note, if you use TRACE_EVENT() and you want to debug even more, you can simply add trace_printk() and that will also appear in your tracing output. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists