Date: Fri, 14 Aug 2015 12:08:05 +0200 From: Laurent Bercot <ska-dietlibc@...rnet.org> To: musl@...ts.openwall.com Subject: Re: /dev/log: datagram, stream, both? On 14/08/2015 05:10, Rich Felker wrote: > Obviously I'd rather not do this, but if there's a convincing argument > that it's needed for compatibility with real setups we could consider it. Well, the only thing I can say is: I have a SOCK_STREAM server, it's working, people use it. As far as I know, there's a commercial embedded box somewhere out there that uses it, if they finally managed to ship that... thing. Of course, it wouldn't really matter for *that* embedded box, which uses glibc. (Yeah.) But who knows, maybe they could be touched by divine grace and recompile everything with musl. Miracles happen, especially when they result in breaking things. And I very much intend to work on more embedded projects in the future, with enough control to make musl mandatory. > Part of being a convincing argument would be showing that > SOCK_STREAM is a documented feature that's supposed to work rather > than historical baggage Well, there's basically *no* documentation for that part of syslog that I can find, and nothing is clear. So from my point of view, anything is fair game; nothing even says that syslog() has to use /dev/log as a communication point, except convention. That convention is pretty strong, but that's all it is. The convention that syslog() should use datagrams, however, is weak. > but even then, since the current code works > with all widely used log daemons, I think we'd also want a strong > argument why stream is better than datagram for your setup. Stream is better than datagram because it can be handled by a superserver. With stream, I can listen(), accept() a connection per instance of openlog, and fork a private ucspilogd process that logs one stream of data from a unique source: this makes for fewer lines of code, and easier log processing, as if daemons were writing to stderr. The client is authenticated once, at connection time. Datagram, on the other hand, enforces that there is only one instance of the syslogd server, handling messages from all the syslog()s on the machine. It enforces that its configuration will be global. Clients are authenticated on every log message, so if the logger needs to separate logs depending on client identity, its efficiency decreases with the amount of data. Note that the reason why widespread setups don't separate logs depending on client identity is that widespread syslogd implementations make this difficult ! With SOCK_STREAM, I can mitigate a large part of why syslog() is bad and implement a complete syslog server with very little code in an efficient way. With SOCK_DGRAM, I can just hang my hat and go home, admit that there's no doing better than current syslogd implementations, and get drunk when people start using journald on embedded boxes because it's so much better (tm). > If SOCK_STREAM support does end up being deemed a feature that should > be added, some careful consideration should be made to how the > fallback and reconnection logic should work. Design question first: why do you keep the datagram socket connected instead of just using sendto()? -- Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.