I see what you mean about there being several implementations... The main thing that I was trying to get at was whether we should add some kind of dependency (through select/depends) or make the OVS SCTP functionality dependent on a config option. We have the latter for VXLAN and GRE support since they depend on relatively large external blocks of code but we haven't had to do anything special in the past for protocols just passing through the switch since the code tends to be very small and contained in headers.
SCTP is still pretty small and CRC32 is well contained and common, so I went ahead and just added a select on that module, as you suggested. On Sun, Aug 25, 2013 at 2:28 AM, Joe Stringer <j...@wand.net.nz> wrote: > I must admit I'm not too familiar with the options here. Although I'm not > sure if it's directly related, it might not help that CRC32c has multiple > implementations. > > There seems to be a discussion on this kind of issue below, where they state > the limitations of select and depend. In particular, they state that depend > doesn't work in this situation, and that select can have issues if the > subsystem has its own dependencies:- > http://lkml.indiana.edu/hypermail/linux/kernel/0804.3/1596.html > > It seems like in this case though, subsystem dependencies shouldn't be an > issue. ext4 seems to set the precedent by selecting CRYPTO and > CRYPTO_CRC32C: > http://patchwork.ozlabs.org/patch/134815/ > > So it seems like we should make it select CRC32C if this module is > statically compiled. How does that sound? > > > On Sun, Aug 25, 2013 at 2:36 PM, Jesse Gross <je...@nicira.com> wrote: >> >> On Fri, Aug 23, 2013 at 6:16 PM, kbuild test robot >> <fengguang...@intel.com> wrote: >> > tree: >> > git://git.kernel.org/pub/scm/linux/kernel/git/jesse/openvswitch.git master >> > head: 810ddb4f57166b11e68291c33162007c394dbb7b >> > commit: e1fa7d46ca3e698691cb1514bb4610d46e78bbd9 [9/10] openvswitch: Add >> > SCTP support >> > config: i386-randconfig-c08-0820-0823 (attached as .config) >> > >> > All error/warnings: >> > >> > net/built-in.o: In function `execute_set_action': >> >>> actions.c:(.text+0xa5cb5): undefined reference to `crc32c' >> >>> actions.c:(.text+0xa5cd0): undefined reference to `crc32c' >> >>> actions.c:(.text+0xa5cf2): undefined reference to `crc32c' >> >>> actions.c:(.text+0xa5d21): undefined reference to `crc32c' >> >>> actions.c:(.text+0xa5d7d): undefined reference to `crc32c' >> > net/built-in.o:actions.c:(.text+0xa5d98): more undefined references >> > to `crc32c' follow >> >> Joe, this is from a direct cross port that I did from your out-of-tree >> module patches to my upstream tree. It's occurring when the OVS module >> is statically compiled in and the CRC32 code is a module, which >> results in a dependency problem. >> >> This issue obviously doesn't exist for the out of tree module since it >> can never be compiled in. How would you like to handle it upstream? > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
