[mythtv] loading lirc kernel modules
D. Hugh Redelmeier
hugh at mimosa.com
Sat Oct 7 19:54:30 UTC 2006
| From: D. Hugh Redelmeier <hugh at mimosa.com>
| I wonder what is the best way to load the lirc kernel module.
| I'm using Fedora Core 5 and following Jarod's guide.
Some more thoughts. Partly prompted by Axel pointing out
http://lists.atrpms.net/pipermail/atrpms-users/2006-June/005448.html
Note: I'm don't know all the lore involved in deciding how this should
be done. I hope to provoke others who do to contribute to this
discussion.
What are the pros and cons of the different mechanisms to load the
modules?
- /etc/sysconfig/modules/lirc.modules (as currently recommended in
Jarod's guide; refined in my message)
- looks like a hack
- always forces the module load at boot time, even if it will
not be used
+ simple
- some mechanism to do a mknod in /dev/lirc so that the module will
automatically get loaded when the device is opened
+ module gets loaded upon first use of the device.
+ no users of the device need to know how to load modules
+ works just the way things were before /dev became dynamic
- knowledge of the pathname, permissions, and major and minor
numbers for the inodes must be maintained two places (the
driver and the thing that does this mknod). This will
require extra care to keep both in sync and the failure
mode isn't great.
- /etc/sysconfig/modules/lirc.modules (I don't know how this mechanism
works and don't even know if it is documented (haven't yet looked))
- a modprobe added to /etc/rc.d/init.d/lircd
+ simple
+ obvious to understand: if the /dev entry isn't there, try to
provoke its creation
+ delays module loading until the daemons are about to be
loaded.
- The module loading is a bit earlier than the original
method (with static /dev). Under that scheme, the
module only got loaded when the device was opened, and
the lircd only opens the device when it has an actual
client, possibly long after startup.
- does not help any other possible users of the dev entries.
But the only users I know of are started in that script.
- others I haven't even thought of
Stepping back, I think that a design goal should be to keep the
interfaces between the components simple, clean, and documented.
One of my assumptions that I now wonder about is the crud that I've
put in /etc/modprobe.conf (as per Jarod's guide).
(1) alias char-major-61 lirc_i2c
This was necessary in the old days, when /dev was static. This is how
the system knew to modprobe lirc_i2c when someone opened an inode with
a character device with major number 61. In the new world of dynamic
/dev, this should not be needed.
Jarod exploits this alias with his modprobe in
/etc/sysconfig/modules/lirc.modules, but I think that this is a bit of
a kludge and doesn't justify the alias.
#!/bin/sh
for module in `/sbin/modprobe -c | awk '/^alias[[:space:]]+char-major-61+[[:space:]]/ { print $3 }'`; do
/sbin/modprobe $module
done
I too exploit this with my patch to /etc/rc.d/init.d/lircd. Also a
kludge, I'd say.
Here are some things wrong with it:
- it isn't installed by lirc (from which lirc_i2c originates)
- it has a wired-in major number. That knowledge should be isolated
as much as possible. It should not be needed by a freelance entry
in /etc/modprobe.conf
- its original justification has gone away when /dev became dynamic
(2) install lirc_i2c /sbin/modprobe ivtv; /sbin/modprobe --ignore-install lirc_i2c
Is this really the best way to get ivtv installed before lirc_i2c?
I don't know enough to answer this. But it does look ugly to me. And
the fact that I had to manually add this rather than have it installed
by the relevant package (ivtv? lirc?) makes this distasteful.
(3) alias char-major-81 videodev
alias char-major-81-0 ivtv
I think that I added these manually (I don't even remember). If so,
why did I have to?
------------------------
So what packages need to be introduced to each other, and how should
this be done? The current system, as I understand it, seems awkward
and fragile.
The alias for lirc_i2c seems to be, at the foundation, to be part of
telling the user-space daemon of lirc what part of the kernel-space
lirc to use. Surely that could be simply a matter for the lirc config
file. Module loading should be a matter internal to lirc.
More information about the mythtv-dev
mailing list