qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH trivial] configure: explicitly disable virtfs if


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH trivial] configure: explicitly disable virtfs if softmmu=no
Date: Tue, 11 Jun 2013 16:01:34 +0100

On 11 June 2013 13:29, Michael Tokarev <address@hidden> wrote:
> 11.06.2013 01:45, Peter Maydell wrote:
>> This doesn't feel to me like it's quite the right way
>> to fix this bug. The current code in configure seems
>> to tangle up (a) was virtfs requested and can we do it?
>> with (b) what do we need to do if it was? (build some
>> extra tools) and (c) when does it make sense? not for
>> linux-user targets. So you end up with an 'else virtfs=no'
>> clause added in an odd place. If the mess was untangled
>> then this probably wouldn't be necessary.
>
> Um. I don't think that tangling is a bad thing really.
> Having different variables or options for it will be
> too bloated, in my opinion.  I don't think there should
> be anything done with it.

I don't want more variables. I just don't think we
should have "if not softmmu then do some other thing";
just check for whether the user asked for virtfs and
we can do it, and if so set virtfs=yes.

> How about something like this:
>
> --- a/configure
> +++ b/configure
> @@ -3810,7 +3810,7 @@ fi
>  if test "$libattr" = "yes" ; then
>    echo "CONFIG_LIBATTR=y" >> $config_host_mak
>  fi
> -if test "$virtfs" = "yes" ; then
> +if test "$virtfs" = "yes" && test "$target_softmmu" = "yes" ; then
>    echo "CONFIG_VIRTFS=y" >> $config_host_mak
>  fi

This seems like a step backwards to me. virtfs=yes should
just translate straight to CONFIG_VIRTFS and the makefile
should just not care if it's set if we happen not to be
building anything virtfs related.

>> Also, disabling building tools and docs in general seems
>> broken: --disable-tools disables building qemu-img, for
>> instance, but not its documentation. So maybe we should
>> fix this by generally making sure we don't build the docs
>> unless we build the tool as well.
>
> This has been addressed by a separate patch sent by afaerber.

That patch didn't touch anything virtfs proxy related.

thanks
-- PMM



reply via email to

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