From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/1] device-drivers/zram: Fix false-judgement on zram's presence
Date: Thu, 14 Jan 2021 16:15:25 +0100 [thread overview]
Message-ID: <YABgDXi2WHSWmwHF@pevik> (raw)
In-Reply-To: <20210114074603.GB32318@andestech.com>
Hi Leo,
> Date: Thu, 14 Jan 2021 15:27:34 +0800
> From: Leo Yu-Chi Liang <ycliang@andestech.com>
> Subject: [LTP][PATCH 1/1] device-drivers/zram: Fix false-judgement on zram's presence
> zram_lib.sh uses the return value of modinfo to check if zram module exists,
> but the behavior of modinfo implemented by busybox is different.
> The busybox-implemented modinfo would also return true (code: 0)
> even if zram module is not present,
> so grep the info that only shows when the module exists.
> -modinfo zram > /dev/null 2>&1 ||
> +modinfo zram | grep "filename" > /dev/null 2>&1 ||
nit:
modinfo zram | grep -q "filename" ||
> tst_brk TCONF "zram not configured in kernel"
Thank you for a report. Actually, we have a helper for it:
TST_NEEDS_DRIVERS="zram"
But this helper is broken for BusyBox, which means it's broken for many tests.
The helper calls tst_check_driver() C function (lib/tst_kernel.c):
int tst_check_driver(const char *name)
{
#ifndef __ANDROID__
const char * const argv[] = { "modprobe", "-n", name, NULL };
int res = tst_cmd_(NULL, argv, "/dev/null", "/dev/null",
TST_CMD_PASS_RETVAL);
/* 255 - it looks like modprobe not available */
return (res == 255) ? 0 : res;
#else
/* Android modprobe may not have '-n', or properly installed
* module.*.bin files to determine built-in drivers. Assume
* all drivers are available.
*/
return 0;
#endif
}
and the problem is that modprobe from busybox does not support -n.
It does support -D, which could be used, *but* unless is busybox binary
configured with CONFIG_MODPROBE_SMALL=y (IMHO the default) => not suitable
for us.
IMHO we have only 2 options:
* write something on our own which would look into /lib/modules and
/system/lib/modules (Android). That's what BusyBox implementation does
(also kmod implementation looks into /lib/modules). BusyBox has this path in
defined in build time configuration (CONFIG_DEFAULT_MODULES_DIR), but I'd be
surprised if any system had both directories.
pros: no external dependency
cons: more code
* use modinfo, but grep for output: for 'filename:' (turn Leo's suggestion into
C code in the API):
cons: module not checked, when modprobe missing (we check for 255 exit code).
BTW not sure whether bother about android support anyway. On Android phone I
have available (Android 8), there is empty /system/lib/modules directory and no
/proc/modules:, thus nor BusyBox neither even toybox modprobe/modinfo
implementations work.
Kind regards,
Petr
next prev parent reply other threads:[~2021-01-14 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 7:46 [LTP] [PATCH 1/1] device-drivers/zram: Fix false-judgement on zram's presence Leo Liang
2021-01-14 15:15 ` Petr Vorel [this message]
2021-01-15 8:54 ` Leo Liang
2021-01-15 9:38 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YABgDXi2WHSWmwHF@pevik \
--to=pvorel@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox