Hi
Yes, I am well aware of the *printf family's complexity.
For me it's about 2 things:
1) Bang for buck
if you can add something really productive
with little programming effort then you are really winning.
2) The overhead of maintaining additional code.
It costs us all time and effort to maintain code, the more complex
the more time. Obviously something like diagnostics (if it becomes
really beneficial) will help reduce the overall maintenance burden.
In spite of this code being less complex than *printf, it is still
complex and will take some time to sort all the bugs out. To me
that is what system libraries are partly for "hiding complexity".
Saying all of that, any work in the diagnostics area is good to me.
I guess we all expected something simpler.
How about some really good tcpdump extensions to understand cpg/ckpt
etc... So we can record messages sent/received and get away with less
data path instrumentation in corosync.
Regards
Angus
On Thu, 2008-10-09 at 10:00 -0700, Steven Dake wrote:
> On Thu, 2008-10-09 at 11:33 -0500, David Teigland wrote:
> > > Wow that is a complicated solution. I though that simple and blackbox
> > > went well together.
> >
> > Completely agree, too complex. The logging code I copy into all the
> > daemons I write is at the opposite end of the spectrum; I doubt it's
> > possible to be much simpler. (I copy it everywhere because it's too short
> > and simple to bother with a lib.)
> >
> > #define DUMP_SIZE (1024 * 1024)
> >
> > extern char dump_buf[DUMP_SIZE];
> > extern int dump_point;
> > extern int dump_wrap;
> >
> > extern char daemon_debug_buf[256];
> >
> > void daemon_dump_save(void)
> > {
> > int len, i;
> >
> > len = strlen(daemon_debug_buf);
> >
> > for (i = 0; i < len; i++) {
> > dump_buf[dump_point++] = daemon_debug_buf[i];
> >
> > if (dump_point == DUMP_SIZE) {
> > dump_point = 0;
> > dump_wrap = 1;
> > }
> > }
> > }
> >
> > #define log_debug(fmt, args...) \
> > do { \
> > snprintf(daemon_debug_buf, 255, "%ld " fmt "\n", time(NULL),
> > ##args); \
> > daemon_dump_save(); \
> > } while (0)
> >
> >
> > That's it, just over 20 lines. I also have a function that will write
> > dump_buf over a unix socket so a command line program can see it while the
> > daemon is running (that's the only way I ever use it, actually). This is
> > non-threaded, of course, and corosync will need something more complex,
> > but the point is you can keep it simple.
> >
> > Dave
>
> ... I guess you don't count snprintf as complicated? Go read the
> implementation in glibc and tell me if that function + dependent
> functions (sprintf) are less complicated then the patch in this thread.
>
> If log_rec were part of glibc and operated on a buffer of predetermined
> size, this conversation would be moot since its complexity would be
> hidden.
>
> Regards
> -steve
>
> >
> > _______________________________________________
> > Openais mailing list
> > [email protected]
> > https://lists.linux-foundation.org/mailman/listinfo/openais
>
> _______________________________________________
> Openais mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/openais
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
