[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

Hi,

On Fri, 2009-10-09 at 12:01 -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.
> 
> thanks,
> 
> -Jason
> 
I've no objection to that, it sounds like a good plan. Should I stick
this in the GFS2 tree, or would you rather keep it in the trace tree? I
was thinking probably the GFS2 tree would be better as it reduces the
chances of any future conflicts.

> 
> Signed-off-by: Jason Baron <jbaron@redhat.com>
> 
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

Steve.

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

Hi,

On Fri, 2009-10-09 at 12:01 -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.
> 
> thanks,
> 
> -Jason
> 
I've no objection to that, it sounds like a good plan. Should I stick
this in the GFS2 tree, or would you rather keep it in the trace tree? I
was thinking probably the GFS2 tree would be better as it reduces the
chances of any future conflicts.

> 
> Signed-off-by: Jason Baron <jbaron@redhat.com>
> 
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

Hi,

On Fri, 2009-10-09 at 12:20 -0400, Jason Baron wrote:
> On Fri, Oct 09, 2009 at 05:05:19PM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Fri, 2009-10-09 at 12:01 -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.
> > > 
> > > thanks,
> > > 
> > > -Jason
> > > 
> > I've no objection to that, it sounds like a good plan. Should I stick
> > this in the GFS2 tree, or would you rather keep it in the trace tree? I
> > was thinking probably the GFS2 tree would be better as it reduces the
> > chances of any future conflicts.
> 
> gfs2 tree works for me.
> 
> thanks,
> 
> -Jason
> 
Ok, done. Should be appearing shortly. Thanks,

Steve.

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

Hi,

On Fri, 2009-10-09 at 12:20 -0400, Jason Baron wrote:
> On Fri, Oct 09, 2009 at 05:05:19PM +0100, Steven Whitehouse wrote:
> > Hi,
> > 
> > On Fri, 2009-10-09 at 12:01 -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.
> > > 
> > > thanks,
> > > 
> > > -Jason
> > > 
> > I've no objection to that, it sounds like a good plan. Should I stick
> > this in the GFS2 tree, or would you rather keep it in the trace tree? I
> > was thinking probably the GFS2 tree would be better as it reduces the
> > chances of any future conflicts.
> 
> gfs2 tree works for me.
> 
> thanks,
> 
> -Jason
> 
Ok, done. Should be appearing shortly. Thanks,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Christoph Hellwig]

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.

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

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.
I'll drop the patch from my tree at the next update, until that can be
resolved,

Steve.

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Steven Whitehouse]

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.

[Cluster-devel] Re: move gfs2 tracepoints to inclue/trace/events dir

[Christoph Hellwig]

On Mon, Oct 12, 2009 at 12:00:37PM +0200, Ingo Molnar wrote:
> 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.

We're lacking quite a bit coherence even with it.  The originally reason
why there were global was that the infrastructure couldn't cope with
having the either in modules or elsewhere in the source tree at all.

We have managed to avoid global directories for drivers/filesystems for
as much as we can lately.  Having everything in a directory makes sure
it's self-contained and people don't use it accidentally from other
modules, which also applies to trace events - we don't want people
accidentally use gfs2 tracepoints from a driver (and if you think
that's far fetched look at the recent example of a driver using
debugging macros from the networking code that got pulled in
accidentally somewhere).