Messages in this thread | | | Subject | Re: move gfs2 tracepoints to inclue/trace/events dir | From | Steven Whitehouse <> | Date | Mon, 12 Oct 2009 11:16:15 +0100 |
| |
Hi,
On Mon, 2009-10-12 at 12:00 +0200, Ingo Molnar wrote: > * Steven Whitehouse <swhiteho@redhat.com> wrote: > > > Hi, > > > > On Fri, 2009-10-09 at 19:45 -0400, Christoph Hellwig wrote: > > > On Fri, Oct 09, 2009 at 12:01:16PM -0400, Jason Baron wrote: > > > > hi, > > > > > > > > I'd like to move the gfs2 tracepoints to the the common > > > > include/trace/events directory along with all of the other trace events. > > > > It makes understanding what tracepoints are available easier, and I see > > > > no reason why gfs2 should be different. For example, 'ext4.h' is already > > > > in the include/trace/events directory. > > > > > > Folks, no. Drivers and filesystems should be as self-contained as > > > possible. include/trace/ is an extremly bad idea for everything that's > > > not actually global kernel functionality. There's a reason all other > > > fs headers have moved out of include/linux, too. > > > > > > > That true, although there is an argument about how much such a header > > belongs to tracing and how much it belongs to the subsystem I think. > > yeah. I have no objection to adding it to include/trace/. Tracepoints > are a fundamentally global business. > > Subsystems can opt to hide their tracepoints locally, but it's better to > have a global view about what's out there, so that it can be extended > coherently, etc. > > Would you like to carry the patch or should we apply it to the tracing > tree? > > Ingo
It is already in my tree, but lets wait and see what Christoph says, as maybe we want to organise things differently. Personally I don't really mind where we put it, so long as it makes sense and I know where it is :-)
Steve.
| |