Hi Juan,
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))
Should not be needed if we do what unix syslog does, initialize it on
the first call to syslog() if necessary.
Looks like i missed this line. Thanks a lot for pointing out. I just
pushed an update to my PR yesterday, which simply invokes openlog on
demand if it wasn't done yet. I would not implement it using a noop, but
rather stay with an implicit call, since we may want to let the user to
have the choice to use a identity string which is not equal to the
threads name. So yea, basically the unix way. I will have another look
in the standard, maybe i missed some more information.
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.
I am not sure if i understand you approach correctly. I just try to
describe it in my own words and you may correct me.
We got two cases:
1. Normal case as it is now: Any invocation of LOG() uses the default
implementation which defaults to printf/UART
2. More sophisticated approach: Additional LOG_MQUEUE module which
overwrite the LOG() function (as in log_printfnoformat) with a threaded
backend implementing a message queue. If a message gets send via LOG()
the message is transferred to the backend's queue and the backend writes
the log request to the appropriate logger (UART or syslog for example).
The only problem i see is how the backend would distinguish between a
message for serial logging and a message for something else like syslog,
since both logging request would be done by invoking LOG(level,"message").
I could either extend the LOG interface, which would probably break a
lot of things and would introduce additional complexity in most cases or
I could treat calls to LOG as UART log request and calls to (for
example) syslog() as syslog log requests. Both calls would send a
message to the backend, but set a different flag depending on the
target. Then a hook functionality in the backend could decide how
message are dispensed.
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.
I already implemented this functionality, but I think it would not help
us here, since it only is aimed to allow console logging if no syslogd
implementation is available.
Robin
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
