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  linux-hardening  linux-cve-announce  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:	Thu, 10 Mar 2016 14:24:31 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Vaibhav Jain <vaibhav@...ux.vnet.ibm.com>,
	Ian Munsie <imunsie@....ibm.com>,
	Michael Ellerman <michaele@....ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Matt Ochs <mrochs@...ibm.com>, Manoj Kumar <kumarmn@...ibm.com>
Cc:	linuxppc-dev <linuxppc-dev@...abs.org>
Subject: Re: [PATCH v3 1/2] cxl: Add mechanism for delivering AFU driver
 specific events

On Wed, 2016-03-09 at 20:07 +0530, Vaibhav Jain wrote:
> Hi Ian,
> 
> Sorry for getting into this discussion late. I have few suggestions.
> 
> Ian Munsie <imunsie@....ibm.com> writes:
> > 
> > diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
> > index 8756d06..560412c 100644
> > --- a/drivers/misc/cxl/Kconfig
> > +++ b/drivers/misc/cxl/Kconfig
> > @@ -15,12 +15,17 @@ config CXL_EEH
> >  	bool
> >  	default n
> >  
> > +config CXL_AFU_DRIVER_OPS
> > +	bool
> > +	default n
> > +
> >  config CXL
> >  	tristate "Support for IBM Coherent Accelerators (CXL)"
> >  	depends on PPC_POWERNV && PCI_MSI && EEH
> >  	select CXL_BASE
> >  	select CXL_KERNEL_API
> >  	select CXL_EEH
> > +	select CXL_AFU_DRIVER_OPS
> I suggest wrapping the driver_ops struct definition and other related
> functions inside a #ifdef CONFIG_CXL_AFU_DRIVER_OPS.

These are here to enable the feature in other drivers.  So the cxlflash
(or whoever) can put their code in via the linux-scsi tree but that new
piece is only enabled when CXL_AFU_DRIVER_OPS is present (ie. when
merged upstream).  But if it's not, their code can still compile.  

Hence their code compiles in linux-scsi and our code compiles in linux
-ppc, but only once they're together do they actually enable the full
feature.  We don't have a nasty dependency of linux-scsi having to pull
in linux-ppc or visa versa before the merge window.  Everyone works
independently and it all gets fixed in linus tree.

Eventually, when everyone has the all the code in merged upstream, we
can remove these config options.  We should be able to remove
 CXL_KERNEL_API and CXL_EEH now actually!

So no, we shouldn't wrap the actual code.

Mikey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ