This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wednesday 11 February 2009 14:27:54 Jeff Moyer wrote: > Roland McGrath <roland@redhat.com> writes: > >> Roland McGrath <roland@redhat.com> writes: > >> > Such hair really belongs in the daemon. syslog should stay simple. > >> > >> I'm not sure I agree with your reasoning. If you think the > >> implementation is tough to get right, then it's better to do it one > >> place and share it. If, on the other hand, you feel that this is really > >> a niche need, then I can see how you wouldn't want it in a generic > >> library. Obviously I feel that this is functionality from which others > >> could benefit. > > > > I think I was unclear. By "the daemon", I meant syslogd. > > The hair should not be in the syslog function. > > OK, thanks for the clarification. I would certainly be open to > implementing this in the syslog daemon. It would mean that the > applications using this functionality would get it for free, but they > would have to log all messages by default (no filtering). Presumably, > then, there would be a way to tell the syslog daemon to dump the ring > buffer for one particular application. I can float the idea with the > rsyslogd folks and see what they have to say. i wonder if it could be shared among loggers then ("libsyslog.a") ... metalog does buffering already -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |