[mythtv] loading lirc kernel modules

[D. Hugh Redelmeier]

| 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.