This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap 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]

Re: Test suite results for ARM with uprobes


On Wed, Dec 14, 2011 at 04:32:03PM +0100, Mark Wielaard wrote:
> On Thu, 2011-12-08 at 08:20 -0700, Wade Farnsworth wrote:
> > >> FAIL: semok/config_number.stp [semantic error: probe point mismatch
> > at
> > >> position 0]
> > >
> > > This one PASSes for me.
> > > What is CONFIG_NR_CPU set to for your kernel?
> > > It is set to 2 for me.
> > >
> > 
> > CONFIG_SMP is not set, so CONFIG_NR_CPU doesn't exist in my config
> > file. 
> >   Maybe stap treats that as being equal to zero?
> 
> Yep it does. Although I am not sure it is meant to. It uses strtoll to
> convert the empty string "", which returns zero, then it checks if errno
> is set and it isn't, even though the man page says "The  implementation
> may also set errno to EINVAL in case no conversion was performed (no
> digits seen, and 0 returned)."
> 
> I don't know what is preferred. I could change the code to barf on an
> empty string in a CONFIG_ numerical comparison, then we would need to
> change the testcase to pick some other CONFIG_ option which is always
> set. I think this is the most sane, but it is a slight change in how
> things worked before (I think by accident).
> 
> Or we could accept that numerical comparisons of CONFIG_ options which
> aren't set compare to zero and then we change the testcase to also
> accept that CONFIG_NR_CPU == 0.
> 
> Opinions?

Even though nobody gave their opinion, I did change mine.
I have added an explicit test for the current behaviour.
Non set CONFIG_options should compare equal to the empty string
and/or zero. That also should make the test work on your setup.

Even though I still think that is kind of ugly, it seems better
to keep current behaviour that people/scripts might already depend
on. And now if we do change it, we at least have a test that points
out the change in behaviour.

Cheers,

Mark

Attachment: config_nr_test.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]