Date: Sun, 6 Apr 2014 19:40:02 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/109478: [libc] [patch] adopt reentrant syslog functions from OpenBSD Message-ID: <201404061940.s36Je2kP006089@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/109478; it has been noted by GNATS.
From: Jilles Tjoelker <jilles@stack.nl>
To: bug-followup@FreeBSD.org, skreuzer@f2o.org
Cc:
Subject: Re: bin/109478: [libc] [patch] adopt reentrant syslog functions from
OpenBSD
Date: Sun, 6 Apr 2014 21:32:34 +0200
In FreeBSD PR bin/109478, you wrote:
> The patch essentially takes OpenBSD's reentrant syslog functions
> (openlog_r, closelog_r, syslog_r and vsyslog_r) and makes them
> available in FreeBSD. Hopefully this will make building of packages
> such as spamd under FreeBSD easier since the source shouldn't require
> modifications.
There may be some point in syslog functions without global data, but I
think OpenBSD's API exposes way too much information about the
implementation and is therefore bad for ABI stability and encapsulation.
Specifically, this kind of struct seems bad (in the header file):
> +/* Used by reentrant functions */
> +
> +struct syslog_data {
> + int log_file;
> + int connected;
> + int opened;
> + int log_stat;
> + const char *log_tag;
> + int log_fac;
> + int log_mask;
> +};
> +
> +#define SYSLOG_DATA_INIT {-1, 0, 0, 0, (const char *)0, LOG_USER, 0xff}
A better way would be for openlog_r() to allocate something and
closelog_r() to free it again.
I don't really like the word "reentrant"; I prefer terms like
"thread-safe" and "async-signal safe" with clear definitions. It seems
that async-signal safe is meant here, since our syslog implementation is
thread-safe by locking.
--
Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404061940.s36Je2kP006089>