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]
Message-ID: <20121009132847.GC4587@mwanda>
Date:	Tue, 9 Oct 2012 16:28:47 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	Sjur BRENDELAND <sjur.brandeland@...ricsson.com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	"Linus Walleij (linus.walleij@...aro.org)" <linus.walleij@...aro.org>,
	"kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [remoteproc:for-next 6/9] remoteproc_virtio.c:(.text+0x238e7e):
 undefined reference to `vring_transport_features'

On Tue, Oct 09, 2012 at 01:52:49PM +0200, Ohad Ben-Cohen wrote:
> Hi Sjur,
> 
> On Tue, Oct 9, 2012 at 12:30 PM, Sjur BRENDELAND
> <sjur.brandeland@...ricsson.com> wrote:
> > Sorry for not responding sooner, but I thought this issue was solved with
> > your patch  "remoteproc: fix (again) the virtio-related build breakage"
> > (https://lkml.org/lkml/2012/10/6/85).
> >
> > I'm not sure I understand why you would want to add a dependency to ARM.
> > But if you're uncomfortable by having STE_MODEM_RPROC directly selectable,
> > perhaps we could let it be selected by arch specific Kconfig files,  e.g. mach-ux500?
> 
> I would just like the Kconfig dependencies to reflect the "real world":
> 
> E.g., if there's no chance the STE modem is going to be used on x86,
> then let's not ask x86 folks about it.
> 
> Does limiting the STE modem to certain platform/architectures make
> sense ? (if not, that's ok)
> 

Unless there is a good reason why then we shouldn't put arbitrary
limits like that.  If we leave it in people at least run static
analyzers on it and try modprobing it.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ