Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro

[Dave Chinner <david@fromorbit.com>]

On Wed, Apr 16, 2014 at 10:51:17AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 16, 2014 at 12:48:50PM -0500, Eric Sandeen wrote:
> > XFS_ERROR was designed long ago to trap return values,
> > but it's not runtime configurable, it's not consistently used,
> > and we can do the same thing today with systemtap, using
> > something like:
> > 
> > probe module("xfs").function("xfs_*").return { if (@defined($return) && $return == VALUE) { ... } }
> 
> Gives me a version just using ftrace, or at least a kprobes based module
> that we can merged in the kernel tree and this would be fine for me.
> 
> Requiring a massive blob of questionable out of tree module code and a
> compiler is an absolute no-go.
> 
> NAK for now.

I think regardless of the systemtap/ftrace replacement, nobody uses
this at the moment, and it's not been used for a long time. It's a
compile time configurable, debug only error trap that is far
less useful than adding printk() or tracepoints at the appropriate
points.

If you've got to recompile the kernel to use it, then you may as
well add meaningful debug rather than hope an error trap that panics
the kernel tells you what you need.  i.e. the error trap code as it
stands is only useful for those running kernel debuggers, and very
few developers actually do that these days.

And, FWIW, it only allows detection of then initial error instance -
too bad if you want the second or third occurrence of the error.

IOWs, I can't see how this is at all useful anymore....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs