public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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: Fri, 15 Jan 2021 10:38:34 +0100	[thread overview]
Message-ID: <YAFimsGMMIkf+xU3@pevik> (raw)
In-Reply-To: <20210115085406.GA23267@andestech.com>

Hi Leo,

...
> > 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).


> Thanks for breaking things down in such detail!

> I personally prefer the first option that looking into those directories ourselves.
> So let's drop this patch and stay as is for now!

FYI: I'm going to implement 1) (own search, written in C API).
Hope to have it on Monday (before the release). If not, we should revert
305a78e4c ("tst_net.sh: Require veth for netns") which breaks *all* network
tests for BusyBox.

> > 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.

> BTW, I found that there's a ver_linux script that detects the version of util-linux.
Yes, but ver_linux it's just legacy info script (we don't have anything better
than this).

> But as I searched through commit log of LTP, there are a lot of workarounds
> regarding the compatibility issue with Busybox (around 10 commits or so).
Yes, these fixes are specific to particular tests. But detecting module in LTP
API affect many tests.

> Is there a certain version of util-linux is expected to conduct a full run of LTP ?
No. We just fix problems when reported (usually reported send a patch).

FYI: We haven't even set minimal supported kernel and (g)libc version.
https://github.com/linux-test-project/ltp/issues/657

> Thanks again,
> Leo


Kind regards,
Petr

      reply	other threads:[~2021-01-15  9:38 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
2021-01-15  8:54   ` Leo Liang
2021-01-15  9:38     ` Petr Vorel [this message]

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=YAFimsGMMIkf+xU3@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