[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Wed, 16 Apr 2014 12:55:57 -0500
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140416175117.GA23643@xxxxxxxxxxxxx>
References: <534EC073.8090006@xxxxxxxxxxx> <534EC282.7010905@xxxxxxxxxxx> <20140416175117.GA23643@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
On 4/16/14, 12:51 PM, 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.

Ok, fair point.
> NAK for now.

Even if we don't have a replacement, I have yet to find anyone who has
ever used it...

Anyway, I'll look into options besides systemtap.


<Prev in Thread] Current Thread [Next in Thread>