On Fri, Dec 2, 2011 at 19:07, Rainer Gerhards <rgerha...@gmail.com> wrote: > On Fri, Dec 2, 2011 at 6:59 PM, Kay Sievers <kay.siev...@vrfy.org> wrote: >> On Fri, Dec 2, 2011 at 17:02, Rainer Gerhards <rgerha...@gmail.com> wrote:
>> Well, if syslogd, or any other consumer, is interested in the >> metadata, it should not rely in /dev/log. /dev/log will probably stay >> what it is which is mostly plain old syslog with a header and a >> timestamp and the human readable string. All stuff that wants the >> metadata should use the proper API and get the records from there. The >> '/dev/log proxy' is just to ensure full syslogd compatibility, not to >> provide any new data which do not really fit into the plaintext file >> format. > > Why are you making it deliberately hard to interoperate? Making what hard? Interoperate? What do you mean? Syslog can very easily be a consumer of the journal data, if it's interested in it. > 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? > What you call the "plaintext file > format" issue is being solved anyhow in the meantime. Look at RFC5424 > or CEE. So how to encode the fields is actually not a question at all. > If you provide proper formatting, the syslogd would not even need to > be aware of what's going on... (at least for CEE, rsyslog also has a > parser for structured data in legacy syslog, but that's non-standard). The journal is not meant to replace syslog, if syslog is needed, nor to act as a proxy to enrich /dev/log messages. We need to change as little as possible, and that includes keeping the same format on the output (the fd handed to syslog) as we get at the input side (/dev/log). If one day glibc changes or there is another generally useful new syslog client API, we can do alll that, but as of now, I'm convinced that the journal should just make it easy to get all the information out, but it should not try to add stuff to established interfaces, and it should not natively speak any syslog enhanced format. That stays as the job for syslog. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
