[PATCH] new applet: nmeter
Rob Landley
rob at landley.net
Tue Aug 22 21:17:39 UTC 2006
On Tuesday 22 August 2006 4:49 am, Denis Vlasenko wrote:
> On Monday 21 August 2006 01:04, Rob Landley wrote:
> > On Monday 07 August 2006 11:21 am, Denis Vlasenko wrote:
> > > Hello Rob,
> > >
> > > This is a resend. People raised some concerns/ideas about
> > > the applet which were addressed. For example, I did get rid
> > > of simple_itoa ;)
> >
> > Ok, taking a closer look at this:
> >
> > "Released under GPL", could I turn that into our boilerplate line? (Right
now
> > this doesn't specify version, you may remember that came up recently. :)
>
> "Licensed under the GPL v2, see the file LICENSE in this tarball."
> Hope this is ok.
Um, you may have missed the current exchange between Erik and myself over the
DietHotplug stuff...
http://busybox.net/lists/busybox/2006-August/023729.html
If you want to hold off on merging this patch after GPLv3 ships, we'll
probably have gone GPLv2 only at that point. But right now, we're holding
off on dropping the "or later" until we have something specific to reject.
(Who knows, the third draft might fix everything. I doubt it, but...)
> > S_STAT(): barf. You have a macro that defines the first _half_ of a
> > structure, and then you need a closed curly bracket after the macro. Your
> > macro contains an odd number of curly brackets. That's really, really
ugly.
> > I don't care if the result is more lines of code, please unwrap that.
>
> The problem is not "more lines of code". I need to avoid cut'n'paste errors.
> The structures _must_ have same fields at the beginning.
> How about having a matched _END macro?
>
> S_STAT(cpu_stat)
> ullong old[CPU_FIELDCNT];
> int bar_sz;
> char *bar;
> S_STAT_END(cpu_stat)
Another thing you can do is put a structure in a structure. If it's done
right, it shouldn't cause a problem. (And you've been able to typecast a
structure to the type of the first field of the structure since the 1970's;
if gcc 4.x throws a warning on that I'll have to come up with a workaround
because that would just be _dumb_.)
>
> > typdef ullong: not good. Would you rather this was uint64_t, or expanded
> > into "unsigned long long"? (Query: on 64 bit systems do you want this to
be
> > 128 bits?)
>
> I want it to be big enough to hold any /proc value, and then some
> (for example, collect_cpu multiplies CPU counts by CPU bar length
> at some point in the calculations). "long" is not big enough on i386,
> for example, that's why I use long long.
>
> I do not need specifically uint64_t.
If "long" is not big enough on i386 then you need at least 64 bits. The
problem is that on a 64 bit system, "long long" is 128 bits. (The semantics
of uint64_t are portable and unsurprising.)
> typedef is used in order to get type name length down.
> "unsigned long long" is just too long to type and read.
An argument in favor of uint64_t? (BusyBox is c99. We've been using these
types for a while.)
> > What does vrdval() do? It requires wrappers for variants of strtoull() in
a
> > way that seems like an inline if statement would be simpler...
>
> Comment added, wrappers removed.
Cool.
> > Copying the contents of /proc/meminfo into collect_mem() as a comment
doesn't
> > seem helpful, somehow.
>
> Why? Do you want reader to be forced to do cat /proc/meminfo?
> (Feel free to shorten that comment, tho... I'm not religious about it).
Well, what I was thinking was cherry-picking the fields we're interested in.
I'll take a look this evening, probably merge it tonight.
Thanks,
Rob
--
Never bet against the cheap plastic solution.
More information about the busybox
mailing list