All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.