On Wed, Jul 16, 2014 at 03:16:40PM -0400, Jeff Layton wrote: > > > > Seems a little confusing as we didn't turn the code into a REVOKED_DELEG > > stateid type yet, but given that destroy_revoked_delegation doesn't > > care this is probably fine. > > > > True, but since we're destroying it anyway we don't need to revoke it. > Still it is less confusing and since I'm respinning for other reasons, > I can change that too... It might make sense to just rename it to destroy_delegation and use it for both types. There's another opencoded instance later on as well. > > Reviewed-by: Christoph Hellwig <hch@xxxxxx> > > > > (would have been a little nicer to read if you had kept > > destroy_revoked_delegation, otherwise diff obsfucates the fact that it > > didn't change at all.. > > Thanks. Do you mean destroy_delegation? destroy_revoked_delegation > still exists -- destroy_delegation is removed, but it's just a wrapper > around nfs4_put_delegation at this point... I meant keept in the same place. You added a function above it, and removed one below it, so diff makes a mess of it despite the function not changing at all. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
