Bug 113038

The module's license is 
 
MODULE_LICENSE("Smart Link Ltd."); 
 
The symbols listed above are exported to GPL modules only. 
So we won't be able to support the driver in 10.0 unless SmartLink changes 
their license. 

Well, but this module is chosen by YaST.  If this can't work, we should disable
the yast functionality.

Greg, can this be worked-around somehow in the module?

You can simply remove class_* stuff from the code.  But this will remove the
entries in sysfs, too, of course, so udev won't work together...

BTW, I'll be possibly able to try snd-intel8x0m instead of slamr.

*** Bug 113165 has been marked as a duplicate of this bug. ***

Takashi, can you elaborate - is the snd-intel8x0m driver a fully functional 
replacement for slamr? 

snd-intel8x0m, snd-via82xx-modem and snd-atiixp-modem drivers provide the ALSA
interface to access to the AC97 modem.  Then user-space slmodemd talks with the
device (when started with a specific option).
Since the binary-only part belongs only to slmodemd, the kernel modules are all
clean GPL.

I'm not sure whether all devices can be covered by ALSA modem drivers.
Need to check PCI table.

Nevertheless, we don't provide a way to configure these modules on YaST yet...

This is a regression from 9.1 and 9.2 at least, and means that Novell
employees (like me) with a corporate Thinkpad notebook won't be able to
upgrade.  Raising severity.

I don't like a pingpong game, but this isn't a bug I should solve.

I guess it's too late to build up the yast configurator for ALSA modem drivers.
Thus we need to fix slarmr somehow.  So I'll pass this to Marian :)

Kay, what do you think about a /etc/udev/static-devices.d/, much like the
/etc/modprobe.d/? That would allow sane management of the entries from packages
and other tools.

How is that related to this bug?

No, I don't want to spread this hack all over the packages. For now I want all
the static crap in the udev package itself. Most cases are just "bugs" or lazy
subsystem maintainers. I will continuously bug the people to fix it instead of
playing old tricks here.

The problem is that this driver can't use kernel sysfs API because of GPL
restriction.  Thus the device wouldn't be created if the driver is patched to
remove the access to class_* functions.

With all the static nodes in udev everybody will get them unconditionaly.

I think simply adding to static_devices.txt is safer at this stage.  Also, I
agree with Kay, that the static devices should be as restricted as possible.

I think there should be as few static devices under /dev as possible. For
virtual devices and now also for devices with non-GPL drivers there is no other
way. I maintain four such modem drivers and I don't feel comfortable poluting
the /dev with the static nodes unless neccessary, ie when the customer installs
the rpm.

If the module is crippled that way, why not add the stuff to the slmodemd init
script then? That sounds like the best option to me.

I still try to avoid providing a generic infrastructure create static nodes. It
should be a uncomfortable and well reasoned exception, otherwise it will end in
the same mess we are currently try to get rid of.

Ok, I will do that for the slmodem. The others are pure kernel driver without
initscripts, the nodes will have to be in udev then.

I'll be able to do basic tests (w/o actual dialing in) at any time, and 
could do functionality tests next Friday and Saturday if you want.

fixed, could you please test, Gerald?

Thanks, Marian.  I installed a the current autobuild kernel and mbuilt
your latest smartlink-softmodem submission, but unfortunately I still get
the following, even after a reboot:
  
  # rpm -qa | egrep 'kernel|smart'
  kernel-default-nongpl-2.6.13-3
  kernel-default-2.6.13-3
  smartlink-softmodem-2.9.10-13
  kernel-default-debuginfo-2.6.13-3
  km_smartlink-softmodem-2.9.10-13

  # /etc/init.d/slmodemd status
  Status of SmartLink Modem driver:                                    unused

  # /etc/init.d/slmodemd start
  Starting SmartLink Modem driver: FATAL: Module slamr not found.
  FATAL: Module slusb not found.

  startproc:  exit status of parent of /usr/sbin/slmodemd: 255
                                                                     failed

The fix has not been checked in yet, you can grab the source from
/work/src/done/STABLE/smartlink-softmodem

That's what I used for last night's testing (cf. the comment on me mbuilding
your latest smartlink-softmodem submission) in comment #22.

I confirmed this today by installing Beta 4 and then replacing the
smartlink-softmodem package by /work/built/mbuild/lifschitz-gp-3/.

has been caused by a typo in the patch and the devices created staring from 1
instead of 0, fixed

there was yet another error in the initscript, the device has to be with full
path, ie /dev/...