[Top] [All Lists]

Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_a

To: Timothy Shimmin <tes@xxxxxxx>, Christoph Hellwig <hch@xxxxxx>, Miklos Szeredi <miklos@xxxxxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: XFS_ERROR use - was Re: [PATCH] prevent NULL returns from d_obtain_alias
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 16 Oct 2008 22:04:58 -0500
In-reply-to: <20081017015301.GK25906@disturbed>
References: <20081015192839.GA867@xxxxxx> <E1KqWzC-00087u-TG@xxxxxxxxxxxxxxxxxxx> <20081016180947.GA26285@xxxxxx> <48F7D814.2080705@xxxxxxx> <20081017015301.GK25906@disturbed>
User-agent: Thunderbird (Macintosh/20080914)
Dave Chinner wrote:
> On Fri, Oct 17, 2008 at 11:11:00AM +1100, Timothy Shimmin wrote:
>> Fair enough.
>> But XFS_ERROR is used throughout the function.
>> I've found the whole idea of when and when not to use XFS_ERROR annoying :)
>> I've never used it (other than calling it to stay consistent with the code).
>> Looking at the code, it is used to BUG and print a msg on particular error 
>> codes set in xfs_etrap[] -
>> and it does this in xfs_error_trap().
>> Can one not decide to do this at any error point?
>> I can't see where we hook in to set up xfs_etrap.
> You break into the debugger, modify the xfs_etrap array to contain
> the set of errors you want to catch, then continue onwards.

bleah :)

Could these just be turned into tracepoints eventually?  Or maybe for
now allow modifying the array via proc or something... would be easier
to ask a user to do that if you don't have direct access to their kdb
console ;)  It is a handy thing to have, though.


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