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 <[EMAIL PROTECTED]> 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 >
