|Summary:||ASTERISK-01969: udev does'nt create appropriate device files into /dev/|
|Date Opened:||2004-07-08 09:05:37||Date Closed:||2004-09-25 02:37:48|
|Environment:||Attachments:||( 0) README.udev|
( 1) zaptel_udev.diff
( 2) zaptel_udev2.diff
( 3) zaptel_udev3.diff
( 4) zaptel_udev4.diff
( 5) zaptel.rules
|Description:||The combination of hotplug and udev alows kernel modules to be automaticaly loaded. In my case wcfxs for TDM400 cards.|
Unfortunately device nodes are not created by udev and ztcfg failes because it cannot find /dev/zap/ctl.
Everything worked well by previously using devfs (linux 2.4).
|Comments:||By: Malcolm Davenport (mdavenport) 2004-07-08 09:21:01|
Is udev in a finished state yet?
By: vmeyer (vmeyer) 2004-07-08 09:37:53
> Is udev in a finished state yet?
Not yet I think. But it works as expected for me in production everywhere but with zaptel/wcfxs module.
By: Matthew Fredrickson (mattf) 2004-07-08 10:58:51
Is udev only in 2.6 or is has it been backported to any stock 2.4 release?
By: vmeyer (vmeyer) 2004-07-08 11:11:40
udev relies on the linux 2.6 specific /sys filesystem. Because of this it can't be backported to any 2.4 release.
By: Matthew Fredrickson (mattf) 2004-07-08 11:18:31
I don't have udev running on my system, so I'll have to get it working before I can look into this. Unless someone has a system that can crash (just in case) and can be rebooted as needed :-)
By: vmeyer (vmeyer) 2004-07-08 11:27:27
On a debian distribution you need a 2.6 kernel with 'TMPFS' compiled in and the package 'udev' :
apt-get install udev.
By: Matthew Fredrickson (mattf) 2004-07-11 21:13:10
I'm working on getting it working on my gentoo system. Whenever I can get it working all right, I'll probably have it done pretty quick.
By: Matthew Fredrickson (mattf) 2004-07-14 12:41:24
Got sysfs stuff working... udevd dumps the device nodes into /dev (as opposed to /dev/zap) so it's a bit unorganized. If someone could "stress test" this patch that would be good. Also, if anybody that knows more about udev could look at the userland config stuff, that would be good. I think it'll take an additional line in the udevd config file based on the class "zap". (I may change that to class zaptel later if that won't hurt the userland config stuff).
By: Matthew Fredrickson (mattf) 2004-07-14 14:21:43
Oh, btw, you need to uncomment the CONFIG_ZAP_UDEV in zconfig.h for it to work. ;-)
By: vmeyer (vmeyer) 2004-07-15 05:57:46
I tried your patch. It works well and awaited files are created into the /sys/class/zap/ directory.
udev create then the following entries : /dev/1 ..., /dev/channel, /dev/ctl ...
To put them in the right place I introduced the following rule (i.e. by creating a file /etc/udev/rules.d/zaptel.rule containing what follows) :
Where %k is the kernel device name (that is also the name of the file in the /sys/class/zap directory).
Unfortunatly, I didn't find how to trig devices according to their classes !
I don't find that doing this according device major number is a good idea.
One other problem is that "timer" conflicts with a sound device and i got :
Jul 15 12:20:20 asterisk udev: configured rule in '/etc/udev/rules.d/udev.rules' at line 39 applied, 'timer' becomes 'snd/%k'
Jul 15 12:20:20 asterisk udev: creating device node '/dev/snd/timer'
Jul 15 12:20:26 asterisk udev: configured rule in '/etc/udev/rules.d/zaptel.rules' at line 2 applied, 'channel' becomes 'zap/%k'
Jul 15 12:20:26 asterisk udev: creating device node '/dev/zap/channel'
As you can see channel is correctly created while timer isn't.
I tried some tweaking but it seems that udev uses the first encountered rule that match a device, and it's the bad one.
To make it work I renamed zaptel.rules to 0zaptel.rules in order it to apears first :
[pts/16] # l /dev/zap/
drwxr-xr-x 2 root root 360 2004-07-15 12:37 ./
drwxr-xr-x 7 root root 2760 2004-07-15 12:37 ../
crw-rw---- 1 root root 196, 1 2004-07-15 12:37 1
crw-rw---- 1 root root 196, 10 2004-07-15 12:37 10
crw-rw---- 1 root root 196, 11 2004-07-15 12:37 11
crw-rw---- 1 root root 196, 12 2004-07-15 12:37 12
crw-rw---- 1 root root 196, 2 2004-07-15 12:37 2
crw-rw---- 1 root root 196, 3 2004-07-15 12:37 3
crw-rw---- 1 root root 196, 4 2004-07-15 12:37 4
crw-rw---- 1 root root 196, 5 2004-07-15 12:37 5
crw-rw---- 1 root root 196, 6 2004-07-15 12:37 6
crw-rw---- 1 root root 196, 7 2004-07-15 12:37 7
crw-rw---- 1 root root 196, 8 2004-07-15 12:37 8
crw-rw---- 1 root root 196, 9 2004-07-15 12:37 9
crw-rw---- 1 root root 196, 254 2004-07-15 12:37 channel
crw-rw---- 1 root root 196, 0 2004-07-15 12:37 ctl
crw-rw---- 1 root root 196, 255 2004-07-15 12:37 pseudo
crw-rw---- 1 root root 196, 253 2004-07-15 12:37 timer
I think that, considering historical usage 'timer' has to be renamed.
I also think that device name of '1', '2', ... are really subject to conflicts !
I suggests renaming kernel device names by prefixing the string zap :
1, 2, 3, ... -> zap1, zap2, zap3, ...
timer -> zaptimer
channel -> zapchannel
ctl -> zapctl
pseudo -> zappseudo
udev rules would become :
I hope it will be helpful
By: Matthew Fredrickson (mattf) 2004-07-15 10:06:31
I was having thoughts along those same lines as well. It would make it a lot easier if we could generate files using a defined naming scheme (such as zap%d, as opposed to %d). I'm not sure what Mark will think of that idea. I'll try to play around w/ userland rules and see what kind of options that are available. I need to read your post a little more to think about what might be involved in all of this though.
By: Matthew Fredrickson (mattf) 2004-07-15 10:10:30
Do you still have conflicts if you match in the udevd config files based on major numbers?
IMHO, that would be the best solution in this case. I'm pretty sure that there are not any other "real" devices that use zaptel's major; it is an assigned major by the body that assigns them out (some long acronym of a name).
By: Matthew Fredrickson (mattf) 2004-07-15 10:30:42
Ok, new version creates the kernel name of the device prefixed with a zap to make it easier on all the udevd rules out there.
By: vmeyer (vmeyer) 2004-07-15 17:50:57
> Do you still have conflicts if you match in the udevd config files based on major numbers?
Yes. There is no conflict with zaptel devices major numbers but the following udev rule (defined by default on my debian installation) :
could be matched *first*, according to configuration order.
To avoid any conflict this rule has to be rewritten.
I tried (and put in production) your last patch which perfectly works.
I uploaded udev configuration rules for anybody interested or redistribution.
Just a few points :
- Many pieces of software could use the /sys filesystem. That's why I think that, also it has been written for udev, it should be, in fact, compiled in by default for a 2.6 kernel.
- With udev, device nodes shouldn't be created during make install. But without specifying it (i.e. into zconfig.h) I think there is no way to know what to do at this stage.
Soon in the CVS tree ? :-)
By: Matthew Fredrickson (mattf) 2004-07-16 10:01:35
>Just a few points :
> - Many pieces of software could use the /sys filesystem. That's why I think that, also it has been written for udev, it should be, in fact, compiled in by default for a 2.6 kernel.
That's what I'm doing right now. Trying to figure out some sort of test for udev'ness of a current kernel. I think I'm just going to do a test for a linux-2.6 kernel and if it is, to test to see if udevd is running.
>- With udev, device nodes shouldn't be created during make install. But without specifying it (i.e. into zconfig.h) I think there is no way to know what to do at this stage.
Yeah, if all conditions above return true, it will not make device nodes.
>Soon in the CVS tree ? :-)
As soon as I get this done and documented. I guess I can just do a test in zconfig.h for kernel version >= 2.6.0 and include it based on that.
By: Matthew Fredrickson (mattf) 2004-07-16 10:28:19
Ok, I think I got all the detection routines done. Last patch (hopefully :-)).
By: vmeyer (vmeyer) 2004-07-16 12:15:58
Last patch works for me.
I noticed that device node permissions created by udev are by default 660 while they are 644 with the makefile. It has no consequence for me but is perhaps important for some application. Permissions can be forced through udev configuration if necessary : just add MODE="0644" to each line.
By: Matthew Fredrickson (mattf) 2004-07-16 17:04:06
That's kind of weird that they're set as 644 by default. I can't see any good reason why they would be set as readable to everybody and their grandma. Maybe so you could run zttool as a regular user or something. Hrm... Well.. another day, another bug. :-)
By: Mark Spencer (markster) 2004-07-16 18:23:10
Added to CVS, thanks Matt!