Please apply this patch for users who are running 2.6.10 or newer. Some in-kernel API has changed.
Created attachment 46885 [details, diff] 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 attachment 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 attachment 47481 [details, diff] 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
