Re: RTEMS Targets Issue #1 - daemon()

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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