[LTP] [PATCH 2/2] Use SAFE_RUNCMD()

[Cyril Hrubis]

Hi!
> > > And this makes me think more of the '.request_hugepages' story. The
> > > needs_foo flags require the foo to be present on the system as hard
> > > requirements. In some situations(i.e copy_file_range02.c), we probably need
> > > to handle the soft situation, which means, the commands are only part of
> > > the test requirement. So if it writing with .needs_cmds="xxx", it might
> > > skip the whole test in setup() phase.
> +1. This is similar to a general problem how to structure tests when you want to
> use tst_brk() and cleanup function (having more unrelated tests in single C file
> means one should try to avoid using tst_brk() when not needed).
> 
> > Indeed, there are couple of solutions for that, one of them would have
> > all the arrays doubled and one of them would list hard requirement while
> > the other soft requirements. Then we will end up with something as
> > "need_cmds" and "wants_cmds". The second one would be more or less
> > informative, the test may print a message "Missing foo command test
> > coverage will be limited".
> I was thinking about it and thought that would be too rich API (given there is
> not that much external dependencies for C tests). But ok, sounds reasonable.

Well yes, the matrix of options would explode exponentially if we do not
keep it reasonable, hence we should keep it as simple as possible. So
unless there is a real need for the wants_cmds I wouldn't add it now.

> Also similar use case from shell tests: mostly $TST_NEEDS_CMDS is used,
> which stop whole testing. But rarely (only in 3 tests and tst_net.sh) is used
> tst_require_cmds() directly - it's a hard requirement, but it tries to run some
> test before (or require it only when it's needed - tst_net.sh).
> But that's bad from metadata point of view (you concentrate on metadata in C,
> but sooner or later we'll need to handle shell as well).

Unfortunatelly the whole problem is more complex than set of flags. The
dependencies are often modified by the system properties, test command
lline options, etc. Complete solution would need to be a set of
conditionals or a domain language that would be able to express all
dependencies. The main problem is that this would soon get too complex
to a point where people would struggle to write the dependency rules.

-- 
Cyril Hrubis
chrubis@suse.cz