RTEMS Targets Issue #1 - daemon()

[Joel Sherrill]

On 03/19/2016 11:15 PM, Yaakov Selkowitz wrote:
> On 2016-03-19 12:01, Joel Sherrill wrote:
>> I built tools using the master of binutils-gdb, newlib, and gcc.
>> All fifteen toolsets built ok. I am building all ~150 RTEMS BSPs.
>> It is still building but I am seeing some warnings and build failures
>> which were not present with the last newlib snapshot. I have not
>> dug in to see what the default feature flags are for RTEMS. I am
>> just going to report issues one at a time as I dig through them.
> Sounds good, I'll respond as best I can.
>
>> First is that the RTEMS ftpd has a static method named daemon().
> [snip]
>> In the last newlib snapshot, daemon() was protected like this:
>>
>> #if defined(__CYGWIN__)
>> int    _EXFUN(daemon, (int nochdir, int noclose));
>> #endif
> In some places ifdef __CYGWIN__ was used for "this isn't POSIX and
> therefore not everyone wants it".
>
>> Now it is like this:
>>
>> #if __BSD_VISIBLE || (__XSI_VISIBLE&&  __XSI_VISIBLE<  500)
>> int    _EXFUN(daemon, (int nochdir, int noclose));
>> #endif
> Which means you are allowed to provide your own daemon() function, so
> long as you are not relying on other BSDisms or SUSv1.
>
>> The ftpd is an RTEMS specific implementation and I don't see an
>> issue with changing the name in RTEMS. Does everyone agree this
>> change in what newlib's unistd.h was presenting is correct now
>> and that RTEMS needs to change?
> As the ftpd code isn't a public API, you could just change it, or if the
> code is e.g. POSIX compliant, then you could compile it with the proper
> value of _POSIX_C_SOURCE.  Your choice.
>

It was a static private method, so we changed it. We should generally
avoid names that conflict with standard use. Plus I suppose it is possible
we might provide daemon() in the future but it would just start a thread
for the service.

Thanks.

--joel