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
| ||
|
Date: Sun, 07 Oct 2012 01:21:09 +0800 From: Haicheng Li <haicheng.li@...ux.intel.com> To: David Miller <davem@...emloft.net> CC: fengguang.wu@...el.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [net:master 1/9] pch_gbe_main.c:(.text+0x510370): undefined reference to `pch_ch_control_write' On 10/06/2012 10:21 PM, David Miller wrote: > From: Haicheng Li<haicheng.li@...ux.intel.com> > Date: Sat, 06 Oct 2012 22:07:23 +0800 > >> On 10/06/2012 09:22 PM, David Miller wrote: >>> From: Haicheng Li<haicheng.li@...ux.intel.com> >>> Date: Sat, 06 Oct 2012 20:07:08 +0800 >>> >>>> The failure is due to the CONFIG_PPS is not set there, consequently >>>> CONFIG_PTP_1588_CLOCK can not be set as =y anyway. >>>> >>>> So David's patch of "da1586461e53a4dd045738cce309ab488970f0ef [1/9] >>>> pch_gbe: Fix PTP dependencies" is buggy. Furthermore, I think using >>>> "selects" to resolve such dependency issue is not good idea as it >>>> won't visit the dependencies. >>>> >>>> David, I would still suggest to take my original patch: >>>> https://lkml.org/lkml/2012/9/28/70 >>>> >>>> + depends on PTP_1588_CLOCK_PCH&& (PCH_GBE=m || PTP_1588_CLOCK_PCH=y) >>>> >>>> or simply like: >>> >>> This is all very rediculous if you ask me. >>> >>> Why should the user have to know a detail like the underlying >>> PTP chip type just to enable PTP on his networking card? >>> >>> Because that is what you are making him do with your change. >>> >>> Select removed the necessity of the user having to know these >>> things. >> However it possibly breaks the build... >> >> IMHO, the reason why the dependency of PCH_PTP becomes so tricky is >> that the code of these two modules call the functions of each other >> (bad code structure?). To fix it neatly, either we restructure the >> code or just simply make it: >> + depends on PTP_1588_CLOCK_PCH=y >> >> For PCH_GBE=m case, it does be able to pass the build test, but I'm >> afraid it won't be smoothly workable via "insmod" due to the >> codependency of these two when PCH_PTP is enabled. > > Then why does it work for IXGBE and others who use select? They explicitly select all the possible dependencies if they are bug-free (I didn't strictly check them). Take IXGBE_PTP as example, it explicitly selects PPS, and also depends on EXPERIMENTAL: config IXGBE_PTP bool "PTP Clock Support" default n depends on IXGBE && EXPERIMENTAL select PPS select PTP_1588_CLOCK So if you stick to use "select" as the convention of such build issue fixing, fengguang's build failure would be fixed by: + depends on EXPERIMENTAL + select PPS + select PTP_1588_CLOCK would you prefer this way? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists