[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150814031037.GI31018@brightrain.aerifal.cx>
Date: Thu, 13 Aug 2015 23:10:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: /dev/log: datagram, stream, both?
On Tue, Aug 11, 2015 at 11:53:38PM +0200, Laurent Bercot wrote:
> On 11/08/2015 23:41, Rich Felker wrote:
> >Busybox 1.0 syslogd:
> >
> >http://git.busybox.net/busybox/tree/sysklogd/syslogd.c?id=1_00#n561
> >
> >That's from 2004. We could go back even earlier but I don't know where
> >the syslogd was (or if it even had one) if we go further back.
>
> I'm not denying there were SOCK_DGRAM servers. What I'm saying is that
> I had a SOCK_STREAM server and it worked, which means libcs had support
> for SOCK_STREAM clients.
>
> And the glibc still does:
> http://repo.or.cz/w/glibc.git/blob/HEAD:/misc/syslog.c
>
> If there's no authoritative source asserting that /dev/log is a datagram
> socket and nothing else, I'm submitting a feature request to support
> SOCK_STREAM in musl's syslog(). I know it would horribly complicate the
> code, but I have something that works with glibc and doesn't with musl,
> and nobody wants that. :)
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. 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, 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.
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. I suspect glibc does it
in a way that's less than ideal. I certainly would want to avoid any
robustness regressions for normal SOCK_DGRAM setups.
Rich
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.
