From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 9/17] locks: add lock cancel command Date: Tue, 10 Apr 2007 17:53:01 -0400 Message-ID: <20070410215301.GL7502@fieldses.org> References: <20070409184144.GB28716@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: akpm@osdl.org, Trond Myklebust , Marc Eshel , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from mail.fieldses.org ([66.93.2.214]:56928 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753807AbXDJVxH (ORCPT ); Tue, 10 Apr 2007 17:53:07 -0400 Content-Disposition: inline In-Reply-To: <20070409184144.GB28716@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Apr 09, 2007 at 07:41:44PM +0100, Christoph Hellwig wrote: > On Thu, Apr 05, 2007 at 07:40:59PM -0400, J. Bruce Fields wrote: > > We do this by adding a new fcntl lock command: FL_CANCELLK. Some day this > > might also be made available to userspace applications that could benefit from > > an asynchronous locking api. > > Should we really add more and more subcases to ->lock that probably don't > share implementation code? I'd much prefer adding different operations. That'd be OK. We considered both-- http://marc.info/?l=linux-fsdevel&m=116616992004056&w=2 --but chose a new ->lock case just because that might provide a cleaner mapping to the userspace interface if we ended up doing that some day. Is there any hard reason why it wouldn't work? --b.