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] |