[systemd-devel] Linux Journal API/client lib

[Rainer Gerhards]

On Sat, Dec 3, 2011 at 12:54 PM, Kay Sievers <kay.sievers at vrfy.org> wrote:
> Well, that's not making it hard to access information, it's trying
> hard not to break established interfaces. If syslog *could* be
> extended in a reasonable way, we wouldn't need a journal interface at
> all. Adding any information might break tools, so we can only offer
> the extended stuff in a new interface.

I think this boils down to the fundamental difference in our view on
syslog, so I guess it does not make much sense to argue here in this
context. But Ifind it interesting to hear that you postulate that
syslog logging is absolutely static and can not be changed at all. If
one follows that claim, it is natural to see there can be no
evolution, as evolution requires change by definition.

Anyhow, as you say, there are interfaces that the syslog world can get
hold of the complete journal data, and that is what I was originally
interested to learn.

>>>> If you
>>>> already supply the event you gather via the log socket, why not
>>>> provide the complete set of information (probably as an opt-in
>>>> feature)? That way the syslogd would not need a specific input
>>>> capability (input module in rsyslog terms) to capture the log data.
>>>> Things could just remain as is.
>>>
>>> You mean the native log messages only or all messages, including the
>>> ones journald retrieves from /dev/log
>>
>> I understood from your posting, that you provide everything that is
>> logged, not matter what API is used, but only the non-structured data
>> part.
>
> We just forward the exact same information syslog information we have
> intercepted, and we will also the syslog compatible part of the native
> journal information we received. But we are absolutely not allowed to
> change the format of the messages we from /dev/log.

Note that I was following your initial answer that the syslogd does
not need to talk to the journal API because it receives all it needs
via the system log socket. Now this seems not to be true, as important
parts are missing. As such my initial assumption that the journal API
must be used was true. I wanted to clarify that point.

Also, I do not understand, even if syslog would be totally static, why
it could break anything if you provide the full information, including
structured data, for a message you received via the *new* API.
Obviously, as it came in via the new API, the message did not exist
before. It is hard to envision that you can break backwards
compatibility for something that formerly did not even exist.

Rainer