----- Original message -----
> On Thu, 29 Mar 2012, Balazs Scheidler wrote:
>
> > ----- Original message -----
> > > On Wed, 28 Mar 2012, Rainer Gerhards wrote:
> > >
> > > > > You don't know what you are going to break and you restrict
> > > > > yourself to the limitations of the current interface.
> > > > > It is not that I am against it, just if we want to improve it it
> > > > > might be best to redo it entirely.
> > > >
> > > > I am strongly against changing the existing interface. This will
> > > > break so many things that nobody will use it...
> > >
> > > I agree that we need to not break any existing applications. What I
> > > am hoping for is that we can extend the interface in a way that's
> > > fully backwards compatible.
> > >
> > > In this case, /dev/log is write-only for existing applications. They
> > > will   never try to read anything from it.
> > >
> > > So I was thinking that if the syslog daemon writes one string to each
> > > thing that connects to it, existing software will never read this
> > > string and everything will work as-is, new software could read the
> > > string and adjust it's behavior accordingly.
> >
> > /dev/log is currently a SOCK_DGRAM socket, no need to connect, and no
> > need to accept, only sendto and recvfrom.
> >
> > Earlier, it used to be SOCK_STREAM, but that was 10 years ago.
>
> so I think that this means that there can only be one reader, all data
> written is seen by that one reader.
>
> Is this correct? (if so, it kills my capabilities idea)
>

yeah, pretty much. senders have an anonymous address automatically created by the kernel. syslogd could respond to that address, but not before the first datagram.

it's about the same as udp. there's only one process that can bind to a given port, and although it is possible to create a more specific 'connection' by using SO_REUSEADDR, then bind() and then connect() to the client address, you have to know the client port in advance, which is automatically allocated.