| 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.
Thanks,
-Eric
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro, Christoph Hellwig |
|---|---|
| Next by Date: | Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro, Eric Sandeen |
| Previous by Thread: | Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro, Christoph Hellwig |
| Next by Thread: | Re: [PATCH 2/2] xfs: Nuke XFS_ERROR macro, Eric Sandeen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |