O_RSYNC and O_DSYNC

O_RSYNC and O_DSYNC

[Joel Sherrill]

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?

Should I just pick the next logical values in sys/_default_fcntl.h
around line 25 and add these around 45?

Thanks.

--joel

Re: O_RSYNC and O_DSYNC

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]

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?

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

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

Re: O_RSYNC and O_DSYNC

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

On Nov 24 16:32, Joel Sherrill wrote:
> On 11/24/2014 5:59 AM, Corinna Vinschen wrote:
> > 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?

To avoid potential clashes, I moved the already defined open flags from
Cygwin's fcntl.h to newlib's _default_fcntl.h.  While I was at it, I
removed the WIN32-specific stuff.

Just add your rtems stuff as you're proposing.  It would be nice to use
the same flags as Cygwin as far as it makes sense.  This way we might be
able to move some of them into generic code at one point.

> And adding a comment above the base defines that they need to stay
> within a sixteen bit integer?

Good idea.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]