Re: em8300 driver, module packaging, device nodes, firmware, and other questions
Bump? Does nobody have any wisdom, or at least opinions, to give me?
Or have I asked too many things in one email?
Peace,
Brendon
On 12/03/06, Brendon Higgins <blhiggins@gmail.com> wrote:
> 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: