em8300 driver, module packaging, device nodes, firmware, and other questions
Hi, Mentors!
I'm helping out Nicolas Boullis with the em8300 packages. This is an
out-of-tree kernel module and utilities to make use of Creative DXR3
and Sigma Designs Hollywood+ DVD decoders cards. I've been discussing
with Nicolas various things about the packages while trying to make a
package for the latest version of upstream, and he recommended I ask
for opinions.
The package sources for what I have done so far, based on Nicolas'
previous work, can be found at:
http://tachyon.no-ip.org/em8300/em8300_0.15.2.dfsg-1.diff.gz
http://tachyon.no-ip.org/em8300/em8300_0.15.2.dfsg-1.dsc
http://tachyon.no-ip.org/em8300/em8300_0.15.2.dfsg.orig.tar.gz
There are a couple of things that concern us. The first involves
device files. em8300 has no entry in MAKEDEV, and Nicolas has found
requests go unanswered, so in the meantime using mknod in a postinst
is our only option. I realise it's against policy, but what else can
we do?
Of course, using mknod is unnecessary when udev or devfs is running.
Currently the postinst checks to make sure update-devfsd and udevd
don't exist before making nodes, but this probably isn't a very good
solution. Any ideas for improvements?
Also, how should the module image, when eventually built, depend on
the kernel image? Should it be a depends, recommends, or suggests?
Should it be there at all? If it should have some kind of dependency,
should it be to a strict version? And what about the KSTEM,
kernel/linux? make-kpkg exports the stem variable but module-assistant
doesn't. My current solution is to use the same logic as m-a uses to
work it out, ie duplicating code. Alternatively, should it always be
"linux" from now on?
Then there is the problem of the firmware. em8300 uses a non-free
firmware which is downloaded from the upstream site (hence contrib).
Previously this firmware was installed into /usr/share/em8300 and
loaded into the chip by a modprobe.d command running the em8300setup
program. Now that the kernel, sometimes, has automatic firmware
loading support from /lib/firmware, which upstream now supports, this
leaves us in a bit of a puzzle. Installing the firmware to
/lib/firmware is easy enough. The hard part is determining if the
modprobe.d stuff is necessary.
Related, bug #341313 seems to be caused by /usr not being available on
boot when the firmware is being loaded by the modprobe.d line. This
would only be half-solved by moving the firmware from /usr to /lib
since /usr/bin/em8300setup is still required. This problem would go
away if that trickery in modprobe.d was unnecessary, but I'm not
convinced that's the case.
A problem with using /lib is that changing firmwares would be a little
more effort, but I don't believe this will be a problem.
Opinions? Ideas?
Peace,
Brendon
Reply to: