Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers

From: Christoph Hellwig
Date: Fri Aug 28 2009 - 11:47:01 EST

On Thu, Aug 27, 2009 at 10:24:28AM -0700, Ulrich Drepper wrote:
> The problem with O_* extensions is that the syscall doesn't fail if the
> flag is not handled. This is a problem in the open implementation which
> can only be fixed with a new syscall.
> Why cannot just go on and say we interpret O_SYNC like O_SYNC and
> O_SYNC|O_DSYNC like O_DSYNC. The POSIX spec explicitly requires that
> the latter handled like O_SYNC.
> We could handle it by allocating two bits, only one is handled in the
> kernel. If the O_DSYNC definition for userlevel would be different from
> the kernel definition then the kernel could interpret O_SYNC|O_DSYNC
> like O_DSYNC. The libc would then have to translate the userlevel
> O_DSYNC into the kernel O_DSYNC. If the libc is too old for the kernel
> and the application, the userlevel flag would be passed to the kernel
> and nothing bad happens.

What about hte following variant:

- given that our current O_SYNC really is and always has been actuall
Posix O_DSYNC keep the numerical value and rename it to O_DSYNC in
the headers.
- Add a new O_SYNC definition:


and do full O_SYNC handling in new kernels if O_REALLY_SYNC is
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at