lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 08 Nov 2016 10:49:35 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Alex Williamson <alex.williamson@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
        aik@...abs.ru, gwshan@...ux.vnet.ibm.com
Subject: Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n

Alex Williamson <alex.williamson@...hat.com> writes:
> On Mon, 07 Nov 2016 19:34:42 +1100
> Michael Ellerman <mpe@...erman.id.au> wrote:
>> Paolo Bonzini <pbonzini@...hat.com> writes:
>> > On 04/11/2016 06:48, Michael Ellerman wrote:  
>> >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
>> >> index da6e2ce77495..6b51a4ebed8a 100644
>> >> --- a/drivers/vfio/Kconfig
>> >> +++ b/drivers/vfio/Kconfig
>> >> @@ -6,12 +6,12 @@ config VFIO_IOMMU_TYPE1
>> >>  config VFIO_IOMMU_SPAPR_TCE
>> >>  	tristate
>> >>  	depends on VFIO && SPAPR_TCE_IOMMU
>> >> -	default n
>> >> +	default VFIO  
>> >
>> > No need to depend on VFIO since you already have it in "default".  
>
> depends and defaults are different beasts though, if VFIO is not
> enabled and we're not on a powerpc system with SPAPR,
> VFIO_IOMMU_SPAPR_TCE should not be selectable, not just default to 'n'.

Right. But dropping VFIO from the depends won't change that. In fact it
has no effect because the entire directory is not built if VFIO=n.

See drivers/Makefile:

obj-$(CONFIG_VFIO)		+= vfio/


So we don't need the depends on VFIO there.

>> > A shorthand is
>> >
>> > 	def_tristate VFIO && SPAPR_TCE_IOMMU  
>> 
>> Yep. My experience though is that a lot of folks don't really know what
>> that means. So I prefer to spell it out with an explicit type, depends
>> and default.
>> 
>> But I'll respin it that way if Alex prefers the shorter style.
>
> Perhaps I'm one of those people.  Non-powerpc archs should not have an
> option to select this, which is why the depends is there, AIUI.  So
> long as we don't start exposing options that aren't relevant to a
> platform, I'm flexible on what shorthands we use, but you may need to
> teach me about them first.  Thanks,

Using the def_tristate trick won't expose the option to users, because
it has no description it's not user selectable. But it does make the
symbol exist on an x86 build, and it appears in the .config.

eg, using def_tristate you get:

# CONFIG_VFIO_IOMMU_SPAPR_TCE is not set
# CONFIG_VFIO is not set

Whereas using depends all you get is:

# CONFIG_VFIO is not set


So using def_tristate in this case is not entirely equivalent.

cheers

Powered by blists - more mailing lists