[LTP] [PATCH 2/2] Use SAFE_RUNCMD()
Li Wang
liwang@redhat.com
Thu Mar 26 06:27:32 CET 2020
On Wed, Mar 25, 2020 at 11:57 PM Petr Vorel <pvorel@suse.cz> wrote:
> Hi Xu,
>
> > I have seen the history about this problem. We have few C cases to use
> many
> > commands(copy_file_range02.c is a specify case, I ported it from xfstest
> to
> > increase coverage), do we really want to implement need_cmd or
> > want_cmds(Usually, we seldom use command in c case and we should avoid
> this
> > for reduce unnecessary dependencies, except user level command such as
> mkfs
> > or makeswap or useradd)? It will give user a mislead.
>
> > ps:copy_file_range02.c should use swapon and swapoff syscall instead of
> > command.
> Yes, rewriting to C would be an improvement for non-standard linux
> platforms
> (but then you need to deal with other exceptions: e.g. whether
> swapon()/swapoff() is even supported on platforms like Android and you
> might
> endup with 1) much more code 2) TCONF anyway for these platforms.
> And there is also chattr and mkswap.
>
That's right. Rewrite into C can't solve the problem by the roots.
>
> Besides this IMHO there will always be a need for running some command via
> tst_run_cmd() in the test instead of reimplementing a wheel. Some of other
> dependencies:
>
Agree. We at least need achieve the tst_cmd_available() for tst_run_cmd()
or .needs_cmds, let's try it together in code first then help to find best
solution in patch polishing.
>
> cat (testcases/cve/stack_clash.c this one could be using C code),
> mpdprobe, make, mkswap, quotacheck,
> useradd/userdel (I plan to put these into the library, but still it's much
> easier to use them than reimplement code in C).
>
> Also library itself (these will not use the flag): insmod, modprobe,
> rmmod, mkfs.*,
> systemd-detect-virt (this one is not a hard dependency).
>
> Kind regards,
> Petr
>
>
--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20200326/be4ce710/attachment.htm>
More information about the ltp
mailing list