[lttng-dev] userspace-rcu test scripts patches (was: ports/168339: [patch] sysutils/userspace-rcu update to 0.7.2

[Mathieu Desnoyers]

Hi Hirohisa,

* Hirohisa Yamaguchi (umq at ueo.co.jp) wrote:
> Hi,
> 
> I'm Hirohisa Yamaguchi, I've sent a set of patches against
> userspace-rcu to Leo the FreeBSD port maintainer.

Thanks for submitting these. Here are some comments, in the spirit of
trying to keep the userspace-rcu upstream as close as possible to the
distro packages.

> 
> I'll try to describe about patches, that might be relevant to upstream.
>  #  I attach a copy of patches.

The patches are cut from my reply, as they were attached (and not
inlined) to the email. But let's first discuss the points you present
below.

> 
> A patch against rculfhash-mm-mmap.c is an optional patch for legacy
> FreeBSD releases(i.e. releases prior to 8.2). The newer releases do
> not need this patch.
> Actually, the same definition is in urcu-bp.c, the definition might
> need to be moved to a header file.

Yesterday, I pushed a change similar to this one. It was needed to get
urcu to build on freebsd 8.2 (inclusive).

> 
> The changes for FreeBSD in test scripts are mainly consists of
> following:

This brings an interesting point: all the tests scripts start with
"#!/bin/sh", but use bash-isms. I guess the first question would be:
should be simply choose make test execution depend on bash (and push
#!/bin/bash prefix), since this is only needed for tests provided with
the package sources, and not needed for deployment of the library on
systems ? Of course, dependency on bash for in-source-tree tests would
have to be documented in the README.

>  1. time(1) in FreeBSD does not have long argument name:
>     change --append to -a and --output to -o

I will pull this change. See commit
383dac33797fd0858d6858527324a6a15aa06c09

>  2. ash (i.e. /bin/sh in FreeBSD) does not have += operator:
>     replace a+="b" to a="${a}b"

The question on whether we specifically go for bash for in-source-tree
test scripts needs to be cleared before I proceed to this change.

>  3. BSD flavoured system have jot(1) instead of seq(1).
>     manual of jot(1) can be read at http://man.freebsd.org/jot/1

For some reason, "seq" is installed on my FreeBSD 9.0 system, but not on
my 8.2. We could implement a seq-wrapper.sh in tests/ that can be
sourced by test shell scripts which would use the right seq
implementation underneath (and change the parameters accordingly).

>  4. ash does not have PIPESTATUS:
>     complicated redirects using file descriptors 3 and 4 are used to
>     get a status of specific command (e.g. runtests.sh), because I've
>     wanted to know which test was failed
> 	exec 3>&1
> 	STATUS=$({ { CMD1 3>&- 4>&-; echo $? 1>&4 3>&- 4>&-;} | CMD2 1>&3 3>&- 4>&-;} 4>&1)
> 	if [ $STATUS != 0 ]; then exit 1; fi
>     ``autotest'' feature in autotools might be more appropriate, but
>     I'm not familiar with autotools.
>     http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Using-Autotest.html

Should decide for bash or sh first.

>  5. NUM_CPUS might be determined at runtime:
>     `cat /proc/cpuinfo | grep -c processor` in Linux systems
>     `sysctl -n hw.ncpu` in BSD flavoured systems
>   # ``kern.smp.cpus'' is a FreeBSD specific alias for ``hw.ncpu''
>     I think this varies in platforms; I'll appreciate if any guide to
>     testing for users.

One might want to put in a number that is larger than the available
number of CPUs to test overcommit, or lower than the number of CPUs if
e.g. the system has hyperthreading. So I would recommend making this a
parameter, and autodetect only if no parameter is provided. The
autodetect would indeed have to be OS-specific. We could implement a
get_nr_cpu.sh script within tests/ that detects the number of CPUs on
the current OS.

> 
> 
>  #  btw, test_perthreadlock under FreeBSD 10-CURRENT always fails
>  #  (releases prior to 9.0 are okay).
>  #  The change in FreeBSD libthr might cause the error.
>  #  I haven't looked into it yet.

What are the details of your test invokation ? (how many reader/writer
threads, how many cores do you have ? Is this on hardware or virtualized ?)

Thanks!

Mathieu

> 
> 
> Regards,
> -- 
> 
> 	Hirohisa Yamaguchi
> 	  umq at ueo.co.jp







-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com