O_RSYNC and O_DSYNC

[Joel Sherrill]

On 11/24/2014 5:59 AM, Corinna Vinschen wrote:
> Hi Joel,
>
> On Nov 23 08:37, Joel Sherrill wrote:
>> Hi
>>
>> 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
>> #else
>>     #define O_RSYNC XXX
>> #endif
>> #endif
>>
>> 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
Cygwin one?

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.
>
>
> Corinna
>

-- 
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