Robin,
On 28/5/19 18:53, Robin wrote:
Only problem here is that syslog as implemented in gLibc
expects a user to issue a call to openlog first. Maybe I can make the
call to openlog implicit and thus make it compatible to both API‘s.
The standard works in our favor here:
"The use of openlog() is optional" and " The use of closelog() is
optional". We can have no-ops for both functions:
#define openlog(ident, option, facility) (void)((ident), (option),
(facility))
Another solution could be to extend the log module with a bootstrap/init
function which defaults to do nothing in most cases.
Should not be needed if we do what unix syslog does, initialize it on
the first call to syslog() if necessary.
One problem with the generic LOG approach that comes to my mind is that
it looks like a all or nothing approach.
I suggest the choice should not be between serial backend and syslog
backend, but rather between serial backend (used for most simple
applications) and IPC/message queue backend. At the end of the quie is
the logic deciding how the packet should be sent.
An advantage of this approach is that is is also useful for serial-only
loggers where one wants to ensure strings don't intermingle. Also the
current implementation of uart logging inherits the blocking
characteristics of the UART, meanings that logging blocks until the
message has been sent.
Of course, most applications are fine with just writing directly to UART
backend and having the queue by default would be overkill.
When I implement the syslog
implementation as a log module it wouldn’t be possible anymore for the
user to decide which logs should be shipped via syslog and which logs
only should be send over serial line.
With a queue, the decision can be made according to the PID of the
message sender. Or, even better, according to the facility value set by
that thread in openlog().
BTW, there is an option in UNIX called LOG_CONS:
> LOG_CONS Write directly to the system console if there is an
error while sending to the system logger.
The more we discuss this topic, the more I'm convinced we cannot
overlook it if we want RIOT to be practical for large-scale deployments.
Regards,
Juan.
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
