lkml.org 
[lkml]   [2008]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/6] Extend completions to provide XFS object flush requirements
On Thu, Jun 26, 2008 at 03:46:36AM -0400, Christoph Hellwig wrote:
> On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote:
> > XFS object flushing doesn't quite match existing completion semantics. It
> > mixed exclusive access with completion. That is, we need to mark an object as
> > being flushed before flushing it to disk, and then block any other attempt to
> > flush it until the completion occurs.
> >
> > To do this we introduce:
> >
> > void init_completion_flush(struct completion *x)
> > which initialises x->done = 1
> >
> > void completion_flush_start(struct completion *x)
> > which blocks if done == 0, otherwise decrements done to zero and
> > allows the caller to continue.
> >
> > bool completion_flush_start_nowait(struct completion *x)
> > returns a failure status if done == 0, otherwise decrements done
> > to zero and returns a "flush started" status. This is provided
> > to allow flushing to begin safely while holding object locks in
> > inverted order.
> >
> > This replaces the use of semaphores for providing this exclusion
> > and completion mechanism.
>
> Given that the only API call shared with normal completions is
> complete() I'd rather make this a primitive of it's own, even if
> internally implemented as completions.

Ok, so that involves exactly what? A new header file, a new API name
(ideas anyone?) and kerneldoc comments?

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com


\
 
 \ /
  Last update: 2008-06-26 13:23    [W:0.517 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site