linux-kernel - Re: [PATCH 3/8] Add yaffs2 file system: guts code

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201012071712.12772.manningc2@actrix.gen.nz>
Date:	Tue, 7 Dec 2010 17:12:12 +1300
From:	Charles Manning <manningc2@...rix.gen.nz>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Arnd Bergmann <arnd@...db.de>, 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 Tuesday 07 December 2010 13:47:43 Steven Rostedt wrote:
> 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).

Yes those are very ugly. That is why I proposed changing them to 

yaffs_trace(bit, "format", args).

That gives printk tracing which I can select on the fly by enabling the 
selected bits in the bitmask. eg. If I want to see the OS calls and the mtd 
accesses then I enable YAFFS_TRACE_MTD and YAFFS_TRACE_OS and only those 
grace groups get spat out.

People find this very handy, especially during system integration, so I am 
loath to lose it. It is simple and it works.

Will it not be acceptable to just leave in the printk-style messages and 
perhaps addTRACE_EVENT later?

>
> 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.

>From what I see, ext4 uses both trace_event and wrapped printk tracing, some 
right alongside eachother so it is a duplication - not a replacement.

YAFFS has approx 500 trace lines in it. Some of those would make sense to 
attach to TRACE_EVENT() , but most not. trace/events/ext4.h has 1172 lines 
for around 28 events (== 40-odd lines per event).

Still reading everything I can find on this  (inc, your LWN articles) to get 
an understanding of what capabilities these give me and what heuristic should 
be used to define trace points vs printks.

-- Charles

--
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/