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
| ||
|
Message-ID: <alpine.LFD.2.20.1703131629570.14436@knanqh.ubzr> Date: Mon, 13 Mar 2017 16:41:39 -0400 (EDT) From: Nicolas Pitre <nicolas.pitre@...aro.org> To: Arnd Bergmann <arnd@...db.de> cc: "David S. Miller" <davem@...emloft.net>, stable@...r.kernel.org, Grygorii Strashko <grygorii.strashko@...com>, Thomas Gleixner <tglx@...utronix.de>, John Stultz <john.stultz@...aro.org>, Networking <netdev@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [RESEND PATCH -net] cpsw/netcp: cpts depends on posix_timers On Mon, 13 Mar 2017, Arnd Bergmann wrote: > On Mon, Mar 13, 2017 at 9:09 PM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote: > > On Mon, 13 Mar 2017, Arnd Bergmann wrote: > > > >> With posix timers having become optional, we get a build error with > >> the cpts time sync option of the CPSW driver: > >> > >> drivers/net/ethernet/ti/cpts.c: In function 'cpts_find_ts': > >> drivers/net/ethernet/ti/cpts.c:291:23: error: implicit declaration of function 'ptp_classify_raw';did you mean 'ptp_classifier_init'? [-Werror=implicit-function-declaration] > >> > >> It really makes no sense to build this driver if we can't use PTP, > >> so it's better to go back to 'select PTP_1588_CLOCK' but instead > >> add a dependency on POSIX_TIMERS. Adding 'depends on PTP_1588_CLOCK' > >> might also work, but has the risk of circular dependencies when > >> mixed with other drivers using 'imply'. > > > > Could you elaborate on that risk please? > > I have seen many circular dependencies in the past that tend to be of type > > config FOO > depends on A > select B > > config BAR > select A > depends on B This is really a problem? I mean in this example there is nothing that prevents A or B to be enabled independently. Of course if you had: config A depends on B config B depends on A then the circular dependency is obvious. > The best way to avoid this problem is to only ever use either 'select' or > 'depends on' for any given dependency, but not both. In this case, almost > all references to PTP_1588_CLOCK use 'select' or 'implies', so I don't > want to introduce any more 'depends on'. I can't find any "select PTP_1588_CLOCK" in the tree. The "imply" keyword in itself doesn't create nor inforce any dependencies -- that's why it was created in the first place. So unless I'm mistaken I don't see any problem using "depends on PTP_1588_CLOCK" here. Nicolas
Powered by blists - more mailing lists