sl-modem issues

أحمد المحمودي aelmahmoudy at
Tue Jun 30 20:26:23 BST 2009

Ok, I just realized that in my previous email I explained a situation, 
yet didn't ask any question !

So the questions are:

1) How to solve this issue with static device creation ?

2) Is there really a license issue that prohibits the non-free sl-modem 
(because it contains proprietary binary blobs) from using udev to 
dynamically create devices ?

3) If that answer for question #2 is no, does anyone know how to add 
udev support in sl-modem ?

On Mon, Jun 29, 2009 at 05:56:12PM +0300, أحمد المحمودي wrote:
>   It seems that the 2.9.11~20080817-3ubuntu2 release of sl-modem is 
> one of causes of Launchpad bug 375148 "no more /dev/ttySL0 
> device node". In that release Ubuntu removed a modprobe conf file that 
> creates a static device (mknod /dev/slamr0).
> I understand that creating static devices is not allowed in Ubuntu, but 
> the problem is that sl-modem code doesn't dynamically create devices.
> The following is the output of udevadm when modprobing slamr module, as 
> far as I understand, this output is not enough to get udev to 
> dynamically create a /dev/slamr* device.
> # udevadm monitor --environment --kernel
> you can see all the uevents sent when the module registers itself, the
> driver, the device, and finally the block and/or the class, etc. in
> sysfs. The slamr module only sends these uevents:
> UEVENT[1237419361.101064] add      /module/slamr (module)
> ACTION=add
> DEVPATH=/module/slamr
> SUBSYSTEM=module
> SEQNUM=1395
> UEVENT[1237419361.142691] add      /bus/pci/drivers/slamr (drivers)
> ACTION=add
> DEVPATH=/bus/pci/drivers/slamr
> SUBSYSTEM=drivers
> SEQNUM=1396
> Btw, sl-modem it isn't really maintained upstream (they just accept patches).
> As far as I understand, sl-modem code shouldn't use udev because of 
> license problems. [1] [2]
> Maurizio Avogadro (he co-maintains sl-modem in Debian) suggested to me 
> the following few months ago:
> "I think that the needed information for udev (basically major and
> minor) are usually sent in the block or in the class uevent: if I got
> this right, the class uevent is sent if an instance of the GPL-only
> structs class_create() and device_create() has been created.
> I completely ignore whether there are some other ways to send the needed
> data to udev or not: that was the way slamr sent the needed information
> along with its class uevent until kernel 2.6.13 (when the structs had
> different names).
> I think the patch you added has been introduced in order to
> automatically load the slamr module when an _already_existing_ char
> device node having major 242 is being accessed (thus superceding the
> corresponding alias line)."
> I think that the patch he mentioned in the last paragraph is Ubuntu's
> autoload.diff patch, that I've merged into Debian.
> [1]
> [2]
---end quoted text---

 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7 (@
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7

More information about the Ubuntu-motu mailing list