[Toybox] [toybox] Add nbd-client. (8525d78)

Isaac Dunham ibid.ag at gmail.com
Fri Jul 18 11:45:51 PDT 2014


On Thu, Jul 17, 2014 at 08:24:07AM -0500, Rob Landley wrote:
> 
> On 07/17/14 08:12, Rob Landley wrote:> On 07/17/14 00:58, technosaurus wrote:
> >> I think this is the same as daemonize() in toybox/lib. Should daemonize
> >> just be defined to daemon(0,0) or is there a reason for it?
> > 
> > daemon() isn't posix, so I have to figure out if it's best to
> > reimplement it for portability, or just stick with the libc function we
> > inherited from BSD and wait for the standard to catch up. In the
> > meantime, it's in lib/pending.c for the same reason toys/pending exists,
> > as toys/pending/README says this stuff needs further review.
> > 
daemon() was removed for SUSv2; glibc makes it available if
_XOPEN_SOURCE < 500 or if _BSD_SOURCE is defined (which includes the default).

Recent OS X versions (>10.5) mark daemon() as deprecated, and use of it there
may cause an FTBFS. Everywhere else (at least on Linux and *BSD), daemon()
is supported and widely used.

glibc, musl, klibc, bionic, presumably olibc: standard;
uclibc, newlib?: optional;
dietlibc: in -lcompat

So if we're still targetting "Linux, and maybe eventually BSD," use daemon().
If we might care about OS X or Darwin (the open source portion of OS X),
maybe put daemonize() in lib/portability.c and probe for daemon(); if building
a test program fails, use the daemonize() code, but otherwise just call
daemon() (or define daemonize to daemon...).
Note: if OS X errors on deprecated functions, using a local daemon() function
also might not work, since there is still the daemon() function in libc...

Thanks,
Isaac Dunham

 1405709151.0


More information about the Toybox mailing list