[PATCH] new applet: nmeter

Denis Vlasenko vda.linux at googlemail.com
Thu Jul 6 15:37:28 UTC 2006


On Wednesday 05 July 2006 23:31, Bernhard Fischer wrote:
> >> looks rather large relative to what it does.
> >
> >Biggest functions are:
> >
> >+00000040 t simple_itoa
> 
> erm, we already have *several* itoa in there:
> msh, hush, ash?, lash, netstat

> Adding yet another impl stikes me as not really optimal. I can see that
> they have different maximum supported lengths, but they should be
> unified nevertheless. Please do not add yet another one..

It's a bit special. It puts string
at the _end_ of provided buffer,
and pads it with zeroes to specified width:

simple_itoa(char *s, int sz, unsigned long v, int pad) {
        s += sz;
        *--s = '\0';
        while (--sz > 0) {
                *--s = "0123456789"[v%10];
                pad--;
                v /= 10;
                if (!v && pad <= 0) break;
        }
        return s;
}

Prototype is rather different from standard itoa.

If I will switch to standard itoa, bloat will simply migrate
to callsites instead (strlen, strncpy etc...). I prefer
to have my own which does exactly what I need.

> Also, is there a possibility that you could use bb_common_bufsiz1
> instead one of your big buffers?

Done

> What about expanding S_STAT() and MALLOC_STAT()? The latter looks like
> it wants xmalloc() instead of malloc.

xmalloc - done. Do you mean - get rid of macros nd expand them by hand?

> >+00000042 t readfile_z
> >+00000046 t init_delay
> >+00000055 t init_cpu
> >+00000057 t init_time
> >+0000005a t init_if
> >+0000005f t collect_fd
> >+00000066 t collect_ctx
> >+00000066 t collect_fork
> >+00000067 t collect_int
> >+00000074 t collect_swp
> >+0000007d t vrdval
> >+000000ba t collect_time - see below why not strftime
> >+000000c5 t collect_if
> >+00000158 t scale - used to cleverly display positive numbers,
> >                    even huge ones, in 4 characters
> >+00000182 t collect_mem
> >+0000021c t collect_blk - large because has both 2.4 and 2.6 functions
> 
> Perhaps it's worthwile to be able to toggle support for 2.4 and 2.6
> separately in the config-machinery like we already have for modutils?

I mostly merged 2.4 and 2.6 code instead. The code which is different
for 2.4/2.6 is just:

        if (is26) {
                i = rdval_diskstats(prepare(&proc_diskstats), data);
        } else {
                i = rdval(prepare(&proc_stat), s->lookfor, data, 1, 2);
                // Linux 2.4 reports bio in Kbytes, convert to sectors:
                data[0] *= 2;
                data[1] *= 2;
        }

> I'd certainly perfer the possibility to turn off support for a series i
> will never run on.
> 
> >+00000292 T nmeter_main
> >+000002b7 t collect_cpu
> 
> Didn't look, but is this memset stanza really needed/benefical in collect_cpu?

It is used fot filling the cpu bar:

[SSSSSSSSSSSSSUUUUUUUUUUUUUUUUDDDDDDDDDDDDDDDDD.............]

How do you propose to do it?

Newer version is attached. Some of the concerns are addressed.
One buglet fixed.
Small change: CPU bar lost []s (use "[%c]" if you liked those).

Routines by size:
+00000040 t simple_itoa
+00000042 t readfile_z
+00000046 t init_delay
+00000055 t init_cpu
+00000057 t init_time
+0000005a t init_if
+0000005f t collect_fd
+00000066 t collect_ctx
+00000066 t collect_fork
+00000067 t collect_int
+0000006f t collect_swp
+0000007d t vrdval
+000000ba t collect_time
+000000c5 t collect_if
+00000158 t scale
+0000016e t collect_mem
+000001bb t collect_blk
+00000281 t collect_cpu
+000002a9 T nmeter_main
+00000984 R applets
+0000cce8 r usage_messages

text+data text+rodata    rwdata       bss filename
     4937        4801       136         8 miscutils/nmeter.o
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nmeter4.patch
Type: text/x-diff
Size: 23111 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20060706/6bdfa473/attachment.bin 


More information about the busybox mailing list