[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090326024753.GA27299@srcf.ucam.org>
Date: Thu, 26 Mar 2009 02:47:53 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Kyle Moffett <kyle@...fetthome.net>
Cc: Theodore Tso <tytso@....edu>,
Christoph Hellwig <hch@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jan Kara <jack@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Arjan van de Ven <arjan@...radead.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <npiggin@...e.de>,
Jens Axboe <jens.axboe@...cle.com>,
David Rees <drees76@...il.com>, Jesper Krogh <jesper@...gh.cc>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.29
On Wed, Mar 25, 2009 at 10:44:44PM -0400, Kyle Moffett wrote:
> Perhaps we ought to add a couple extra open flags, O_BARRIER_BEFORE and
> O_BARRIER_AFTER, and rename3(), etc functions that take flags arguments?
> Or maybe a new set of syscalls like barrier(file1, file2) and
> fbarrier(fd1, fd2), which cause all pending changes (perhaps limit to this
> process?) to the file at fd1 to occur before any successive changes (again
> limited to this process?) to the file at fd2.
That's an option, but what would benefit? If rename is expected to
preserve ordering (which I think it has to, in order to avoid breaking
existing code) then are there any other interesting use cases?
--
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists