lz4_decompress symbol conflict

[behlendorf]

According to @ryao when CONFIG_LZ4_DECOMPRESS=y or CONFIG_LZ4_COMPRESS=y is set the build will fail as follows. The simplest fix for this is to just change the symbol names used by zfs. However, it would be better if we could get the kernel developers to not export these functions GPL-only so we could use them.

|lib/built-in.o: In function `lz4_decompress':
(.text+0xeea0): multiple definition of `lz4_decompress'
fs/built-in.o:(.text+0x941d0): first defined here
make: *** [vmlinux] Error 1| 

[ryao]

It looks like the upstream Linux kernels will fix the exports:

http://www.gossamer-threads.com/lists/linux/kernel/1767337

The current ZFS lz4_compress() is a shim for ZFS' generic compression routine that invokes real_LZ4_compress() while the Linux lz4_compress() is roughly analogous to real_LZ4_compress(). Adopting it will require a new symbol name.

Similarly, we would need a new symbol for lz4_decompress() because while the two are roughly analogous, ZFS' internal API requires an additional argument that is unused by LZ4.

[behlendorf]

I'm glad Richard jumped on this, getting the correct license on these symbols early will be helpful. Assuming that patch gets merged we could pursue using the kernel versions if we have reason to believe they have been further optimized over the ZFS versions.

[ryao]

@behlendorf b3c49d3 should have closed this.