Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261810AbVDEPvm (ORCPT ); Tue, 5 Apr 2005 11:51:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261803AbVDEPrY (ORCPT ); Tue, 5 Apr 2005 11:47:24 -0400 Received: from kanga.kvack.org ([66.96.29.28]:25222 "EHLO kanga.kvack.org") by vger.kernel.org with ESMTP id S261804AbVDEPrF (ORCPT ); Tue, 5 Apr 2005 11:47:05 -0400 Date: Tue, 5 Apr 2005 11:46:41 -0400 From: Benjamin LaHaise To: Trond Myklebust Cc: Suparna Bhattacharya , Andrew Morton , linux-kernel@vger.kernel.org, Linux Filesystem Development , linux-aio@kvack.org Subject: Re: [RFC] Add support for semaphore-like structure with support for asynchronous I/O Message-ID: <20050405154641.GA27279@kvack.org> References: <1112219491.10771.18.camel@lade.trondhjem.org> <20050330143409.04f48431.akpm@osdl.org> <1112224663.18019.39.camel@lade.trondhjem.org> <1112309586.27458.19.camel@lade.trondhjem.org> <20050331161350.0dc7d376.akpm@osdl.org> <1112318537.11284.10.camel@lade.trondhjem.org> <20050401141225.GA3707@in.ibm.com> <20050404155245.GA4659@in.ibm.com> <20050404162216.GA18469@kvack.org> <1112637395.10602.95.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1112637395.10602.95.camel@lade.trondhjem.org> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1475 Lines: 30 On Mon, Apr 04, 2005 at 01:56:35PM -0400, Trond Myklebust wrote: > IOW: the current semaphore implementations really all need to die, and > be replaced by a single generic version to which it is actually > practical to add new functionality. I can see that goal, but I don't think introducing iosems is the right way to acheive it. Instead (and I'll start tackling this), how about factoring out the existing semaphore implementations to use a common lib/semaphore.c, much like lib/rwsem.c? The iosems can be used as a basis for the implementation, but we can avoid having to do a giant s/semaphore/iosem/g over the kernel tree. > Failing that, it is _much_ easier to convert the generic code that needs > to support aio to use a new locking implementation and then test that. > It is not as if conversion to aio won't involve changes to the code in > the area surrounding those locks anyway. Quite true. There's a lot more work to do in this area, and these common primatives are needed to make progress. Someone at netapp sent me an email yesterday asking about aio support in NFS, so there is some demand out there. Cheers, -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/