|| ||Ulrich Drepper <drepper-AT-redhat.com> |
|| ||Jamie Lokier <jamie-AT-shareable.org> |
|| ||Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers |
|| ||Fri, 28 Aug 2009 14:08:40 -0700|
|| ||Christoph Hellwig <hch-AT-infradead.org>, linux-fsdevel-AT-vger.kernel.org, linux-kernel-AT-vger.kernel.org|
|| ||Article, Thread
On 08/28/2009 09:44 AM, Jamie Lokier wrote:
> However, for userspace, there's an issue with applications which were
> compiled with an old libc and used O_SYNC. Most of them probably
> expected O_SYNC behaviour but all they got was O_DSYNC, because Linux
> didn't do it right.
Right. But these programs apparently can live with the broken semantics.
I don't worry too much about this. If people really need the fixed O_SYNC
semantics then let them recompile their code.
> When using a newer kernel which actually implements O_SYNC behaviour,
> I'm thinking those applications which asked for O_SYNC should get it,
> even though they're still linked with an old libc.
In general yes, but it's too expensive. Again, existing programs expect
the current behavior and can live with it.
> (Oh, and Ulrich: Why is there a "#define O_RSYNC O_SYNC" in the Glibc
> headers? That doesn't make sense: O_RSYNC has nothing to do with
O_SYNC is a superset of O_RSYNC. In the absence of a true O_RSYNC that's
the next best thing. Of course I didn't know the Linux O_SYNC is really
O_DSYNC. In that context the definition doesn't make sense.
> Although libc's __new_open() could have this:
> /* Old kernels only look at O_DSYNC. It's better than nothing. */
> if (flags& O_SYNC)
> flags |= O_DSYNC;
> Imho, it's better to not do that, and instead have
> #define O_SYNC (O_DSYNC|__O_SYNC_KERNEL)
Why should it be better? You're replacing something the compiler can do
with zero cost with active code.
Again, these O_* constant changes are sufficient.
â§ Ulrich Drepper â§ Red Hat, Inc. â§ 444 Castro St â§ Mountain View, CA â-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)