On Sun, Jul 24, 2005 at 11:36:34PM +0100, Christoph Hellwig wrote: > On Sun, Jul 24, 2005 at 11:17:02PM +0100, Christoph Hellwig wrote: > > On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote: > > > In order to allow for interruptible and asynchronous versions of > > > lock_page in conjunction with the wait_on_bit changes, we need to > > > define low-level lock page routines which take an additional > > > argument, i.e a wait queue entry and may return non-zero status, > > > e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames > > > __lock_page to lock_page_slow, so that __lock_page and > > > __lock_page_slow can denote the versions which take a wait queue > > > parameter. > > > > How many users that don't use a waitqueue parameter will be left > > once all AIO patches go in?
Since these patches are intended only for aio reads and (O_SYNC) writes, that still leaves most other users of regular lock_page() as they are. > > Actually looking at the later patches we always seem to pass > current->io_wait anyway, so is there a real point for having the > argument? > Having the parameter enables issual of synchronous lock_page() within an AIO path, overriding current->io_wait, (for example, consider the case of a page fault during AIO !), and thus avoids the need to convert and audit more paths to handle -EIOCBRETRY propagation (though it is possible to do so as and when the need arises). This is why I decided to keep this parameter explicit at the low level, and let the caller decide how to invoke it and handle the return value propagation. Does that make sense ? BTW, there is also a potential secondary benefit of a low level primitive for asynchronous page IO operations etc directly usable by kernel threads, without having to use the whole gamut of AIO interfaces. Thanks for reviewing the code ! Regards Suparna -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
