O_RSYNC and O_DSYNC
Mon Nov 24 22:32:00 GMT 2014
On 11/24/2014 5:59 AM, Corinna Vinschen wrote:
> Hi Joel,
> On Nov 23 08:37, Joel Sherrill wrote:
>> Looking through old RTEMS PRs, someone reported these
>> are missing in newlib. If no target has needed them
>> should we add them for completion?
>> If so, Linux has them wrapped like this:
>> #if __USE_POSIX1999309 || defined __USE_UNIX98
>> #define O_DSYNC XXX
>> #if defined(__O_RSYNC)
>> #define O_RSYNC __ORSYNC
>> #define O_RSYNC XXX
>> How/if should we guard the definitions of O_RSYNC/O_DSYNC?
>> Open Group just cites them as C Library extensions. Linux is
>> marking is as 1999. Does that correspond to newlib's
>> __XSI_VISIBLE >= 600?
> Hmm, good question. What about __POSIX_VISIBLE >= 199309?
>> Should I just pick the next logical values in sys/_default_fcntl.h
>> around line 25 and add these around 45?
> Have a look at lines 48-50. These are already defined for ages on
> Cygwin (no idea, though, who thought _WIN32 would ever be useful).
> Cygwin also defines additional values in its own fcntl.h, and you never
> know if other targest define their own values, too. It would be nice
> not to introduce clashing values in the default fcntl header.
> Here's what Cygwin defines in /usr/include/fcntl.h:
> /* sys/_default_fcntl.h defines values up to 0x40000 (O_NOINHERIT). */
> #define _FDIRECT 0x80000
> #define _FNOFOLLOW 0x100000
> #define _FDIRECTORY 0x200000
> #define _FEXECSRCH 0x400000
> #define O_DIRECT _FDIRECT
> #define O_NOFOLLOW _FNOFOLLOW
> #define O_DSYNC _FSYNC
> #define O_RSYNC _FSYNC
> #define O_DIRECTORY _FDIRECTORY
> #define O_EXEC _FEXECSRCH
> #define O_SEARCH _FEXECSRCH
> As you can see, O_DSYNC and O_RSYNC are == O_SYNC == _FSYNC.
> Given the potential implementation differences between targets and given
> their state as optional in SUSv4, shouldn't the definitions stay outside
> of sys/_default_fcntl.h?
I agree they would have to be guarded by OS but for the purposes
of RTEMS, I think I would be happy to do what Cygwin has done.
But unless we want to split out a target specific fcntl() support file
and move the existing Cygwin support, I am prone to just add
RTEMS support like that for Cygwin.
Any opposition to the addition of an "if rtems" section after the
And adding a comment above the base defines that they need to stay
within a sixteen bit integer? That slipped my mind so I think a comment
will help the next person.
> Also, for 16 bit targets the O_DSYNC and O_RSYNC values, as well as any
> other value, should override values from lines 10 to 25 not used in the
> open call (_FMARK, _FDEFER, etc), otherwise we're out of 16 bit flag values.
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the Newlib