On Wed, 06 Jan 2010 22:39:09 +0100
Carsten Emde [off-list ref] wrote:

I know that there are quite a few people out there who get furious, if
someone breaks backward compatibility - especially in things that are
used for automatic testing. Cyclictest is such a thing.

In addition, I would propose to consider not only affinity but also the
number of threads. If, for example, someone specifies -a -t5 on a
four-way machine, then it may not make sense to use the same priority
and the same interval on all threads. If any, the new feature would only
make sense in cases where both the -a and the -t option do not have an
argument so the number of threads matches the number of CPUs and every
thread runs on its own CPU. Another pitfall is hyperthreading in which
case it may be desired to have as many threads at the same priority as
real CPUs rather than as available hyperthreads.

Here is my proposal:
Do not change the meaning of existing options. Introduce a new option
that is mutual exclusive with the -a, the -t and the -d option. This new
option does the same as -a and -t and -d0 and sets the same priority to
all threads. How about that?

Ugh, I truly *hate* adding options. Do you know that cyclictest is
halfway to having as many options as 'ls'? That being said, I had
forgotten that you can provide a list of cpus to -a (as well as -t) so
my quick hack really isn't as safe as I first thought it would be. 

How about if we create the -S/--smp option that takes no arguments and
causes -a, -t and -d to be ignored (with a warning). This option would
create one thread per cpu, each thread pinned to it's corresponding
cpu, all with the same sampling interval (i.e. -d0) and the same
priority?

Clark