Bugzilla Bug 75656

Please apply this patch for users who are running 2.6.10 or newer. Some
in-kernel API has changed.

Created an attachment (id=46885) [details]
slmodem-2.9.10-fix-for-2.6.10.patch

The driver does not work for me:

slamr: module license 'Smart Link Ltd.' taints kernel.
slamr: Unknown symbol get_device
slamr: Unknown symbol put_device
slamr: Unknown symbol device_release_driver

so your fix is not really sufficient, any clue on this problem?

other thing is: should we not put your code change in ifdefs and apply it only when we detect a 2.6.10 kernel?

Those functions are now only available to GPL modules :(
Greg, whats the way to approach this?

For the time being, I've blocked the installation for kernels >= 2.6.10.
Usage of kernel exported symbols have been restricted to GPL modules: http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.2/0369.html

I think this bug should be closed with UPSTREAM resolution. Opinions?

Only slamr is affected, so we could simply remove that module for kernels >=
2.6.10

Slamr is fully replaced by snd-intel8x0m I think.

However slusb in the ebuild has no replacement, so please compile it for all
kernels and do not bail out on >=2.6.10
Also the slmodemd is always needed .. so we really need that ebuild ..

Ok, I've rolled back r[12] revisions and changed r3 as follows:
  - allow installation for kernels >= 2.6.10 but don't install slamr module
  - apply Daniel's patch if and only if kernel ver >= 2.6.10 

Are these changes ok?

You can make one simplification in src_unpack

-	# http://marc.theaimsgroup.com/?l=gentoo-dev&m=109672618708314&w=2
-	if kernel_is ge 2 6 6; then
-		sed -i 's:SUBDIRS=:M=:g' drivers/Makefile
-	fi
+	convert_to_m drivers/Makefile

patch applied. 

It is not a bug, but what Alin Nastac pointed out. There are 2 controversial
workarounds that will probably have to be applied by the user manually; 1)
Change all entries to MODULE_LICENSE("GPL") in slmodem's source code, 2) Patch
the kernel to export the required symbols to non-GPL drivers.

Neither of those are suitable here. I also dont think slmodem using
device_release_driver is correct (have not looked at the other 2). I think the
slmodem source code can be worked in a better way.

The main problem lies on "Unknown symbol" due to the required symbols are not
exported (EXPORT_SYMBOL_GPL is used and not EXPORT_SYMBOL) because the slmodem
driver is not licensed with GPL. A suitable fix, in terms of licensing and
kernel developers' ideology, is to make a GPL licensed wrapper driver for the
slmodem binary driver.

That is not up to us to decide. Plus my last point still stands. I read
something like device_release_driver should only be used if it was previously
registered with device_register_driver, which it is not.

I just read Smart Link's license
(http://www.smlink.com/main/item.php?ln=en&item_id=24&main_id=20) and they
prohibit any kind of modifications of their driver. So there is actually no
point of fixing this driver if they will call you a criminal bt doing so.
I've also checked Nvidia's driver and they reimplemented the GPL only symbols.

That does not apply to smartlinks glue code, which is released under a
different (BSD-like) license. I have sent code fixes to smartlink in the past
which are incorporated in these releases.

nvidia does not have wrappers around the gpl licensed functions, they merely
call different functions.

If such wrappers were created for this driver, it would be time to call
my employer's lawyers, as that is my code they are violating by doing so.

So please, either get upstream to use the proper kernel interfaces (that are not marked GPL only), or get them to change their license of the code, not much we can
do here about this (nor do I want to have gentoo make such changes, as it is not
legal for us to do so, as has been pointed out.)

Created an attachment (id=47478) [details]
slmodem license

This is the slmodem license as included in the source code. It's not GPL
compatible but is fairly "open" at the same time. And they didn't seem to have
a problem with me hacking the source the last time around.

Created an attachment (id=47481) [details]
slmodem-2.9.10-pci-workaround.patch

The init function currently scans the hardware, and if any supported hardware
has been claimed by another driver, it tries to unregister it frmo that driver
before claiming it itself. This seems rather messy, dropping that code
altogether is a good workaround for this problem.

patch applied in r4

In response to comment #5, slamr is not fully replaced by snd-intel8x0.  I have
a modem that works 99% with slamr but is completely unrecognized by
snd-intel8x0.  Any suggestions?

Stupid user error...

1. Insert snd-intel8x0m
2. Use slmodem and hw:1, not modem:0 or modem:1.

Continue life in a happy and joyous way...
Many apologies.

Can someone point out, which way to go now?

Is it fully working by using just snd-intel8x0m, without the use of the slamr module?

If the problem with the slmodem-archive, so building the slamr module on a 2.6.10 kernel got fixed, what is it about "-r4" since slmodem-2.9.10-r1.ebuild is still the last one showing up in portage?

You need snd-intel8x0m, not slamr. But I think you also need the slmodemd
program from this package (maybe you could confirm or deny this? I don't think
any of us own this hardware...)

The newest version is 2.9.9a (yes, even newer than 2.9.10)

Version 2.9.9a may be newer than 2.9.10, but this is not how portage
sees it:

# emerge -pv slmodem

These are the packages that I would merge, in order:

Calculating dependencies  ...done!
[ebuild     U ] net-dialup/slmodem-2.9.10-r1 [2.9.9a] -alsa -usb 0 kB

This is solved only if I add:
">=net-dialup/slmodem-2.9.10" to /etc/portage/package.mask, and "net-dialup/slmodem ~x86" to /etc/portage/package.keywords.

2.9.10 will be removed soon due to licensing issues