qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded


From: John Snow
Subject: Re: [PATCH 2/5] tests/qemu-iotests: skip 108 when FUSE is not loaded
Date: Tue, 14 Jun 2022 10:30:36 -0400

On Tue, Jun 14, 2022 at 4:59 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Jun 14, 2022 at 06:46:35AM +0200, Thomas Huth wrote:
> > On 14/06/2022 03.50, John Snow wrote:
> > > In certain container environments we may not have FUSE at all, so skip
> > > the test in this circumstance too.
> > >
> > > Signed-off-by: John Snow <jsnow@redhat.com>
> > > ---
> > >   tests/qemu-iotests/108 | 6 ++++++
> > >   1 file changed, 6 insertions(+)
> > >
> > > diff --git a/tests/qemu-iotests/108 b/tests/qemu-iotests/108
> > > index 9e923d6a59f..e401c5e9933 100755
> > > --- a/tests/qemu-iotests/108
> > > +++ b/tests/qemu-iotests/108
> > > @@ -60,6 +60,12 @@ if sudo -n losetup &>/dev/null; then
> > >   else
> > >       loopdev=false
> > > +    # Check for fuse support in the host environment:
> > > +    lsmod | grep fuse &>/dev/null;
> >
> > That doesn't work if fuse has been linked statically into the kernel. Would
> > it make sense to test for /sys/fs/fuse instead?
> >
> > (OTOH, we likely hardly won't run this on statically linked kernels anyway,
> > so it might not matter too much)
>
> But more importantly 'lsmod' may not be installed in our container
> images. So checking /sys/fs/fuse avoids introducing a dep on the
> 'kmod' package.
>
> >
> > > +    if [[ $? -ne 0 ]]; then
> >
> > I'd prefer single "[" instead of "[[" ... but since we're requiring bash
> > anyway, it likely doesn't matter.
>
> Or
>
>     if  test $? != 0 ; then
>
> >
> > > +        _notrun 'No Passwordless sudo nor FUSE kernel module'
> > > +    fi
> > > +
> > >       # QSD --export fuse will either yield "Parameter 'id' is missing"
> > >       # or "Invalid parameter 'fuse'", depending on whether there is
> > >       # FUSE support or not.
> >

Good suggestions, thanks!

--js




reply via email to

[Prev in Thread] Current Thread [Next in Thread]