This looks like the path of least resistance. We can always change it in the future if it's an issue. Cheers for handling this.
On Tue, Aug 27, 2013 at 9:18 AM, Jesse Gross <je...@nicira.com> wrote: > 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.gitmaster > >> > 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
