SRU LP #269123 stkwebcam kernel-module doesn't support all the webcams supported previously with stk11

[Stefan Bader]

Jim Lieb wrote:
> On Thursday 15 January 2009 08:51:30 Stefan Bader wrote:
>> Jim Lieb wrote:
>>> On Thursday 15 January 2009 08:30:02 Stefan Bader wrote:
>>>> Jim Lieb wrote:
>>>>> This is a backport of the stk11xx driver from SourceForge.  It was in
>>>>> Hardy but did not make it to Intrepid.  The patch is quite large due to
>>>>> its inclusion of the (new) driver files.  Both reporters have confirmed
>>>>> it works with both amd64 and i386.
>>>>>
>>>>> git://kernel.ubuntu.com/lieb/ubuntu-intrepid.git lp269123
>>>>>
>>>>> Proposing for SRU for Intrepid.
>>>>>
>>>>> The upgraded stkwebcam driver in Jaunty (2.6.28) should be tested
>>>>> prior to proposing for Jaunty.  Those changes were not attempted due
>>>>> to the rework between .27 and .28.
>>>>>
>>>>> Jim
>>>> Alright, I had some time to look at the driver. The problem here is that
>>>> this new driver takes the same IDs as the stk-webcam driver which is in
>>>> Intrepid and also build and shipped. So for this reason the backported
>>>> driver has to go into lbm.
>>>>
>>>> Stefan
>>> Sure if that is the consensus.  All I need is a pointer on how to do it. 
>>> We already know that the driver works for the reporters.  Pointer please?
>> Not sure we have a good doc there. Basically the mechanics are similar to
>> the ubuntu dir. There is a separate git intrepid-lbm.git. You place the new
>> driver into the updates dir there update Makefile to descend into that dir
>> (configurable) and then turn on the configs in the debian/config dir. In
>> the past it was usually done in two steps: first add the driver and Maefile
>> change and in a second checkin turn on the configs.
>>
>> Stefan
> I've had look at the lbm git and the one paragraph in KernelMaintenance and
> I'm not sure I am more or less confused.  All I see in the git at this point
> is the wireless-compat stuff with its firmware.  I'd like to get some guidance
> because, although I can make either work, unwinding this thing can be a
> big PITA for all concerned if is it's not "the plan".  I plead newbie
> ignorance of process here.
> 
> * What is the criteria?  There are lots of competing drivers and modules
>   all over the kernel.  What would make this special and a candidate for lum?
>   As for conflicting usb ids, that's a job for udev and friends.  The driver
>   already lives side by side with stkwebcam in /lilb/modules.
> 
The most important criteria being: can it cause side effects. This can be true 
for modules which already are in the kernel and are replaced by an upstream or 
more recent version. But also, as there are real life cases, when a newer 
driver takes ownership of HW that was/is handled by a different driver (or at 
least supposed to be).
The problem here is that there are known issues with the automatic loading of 
modules. The given search path does not guarantee the precedence of one driver 
over the other. Also as this driver does take responsibility for more that one 
ID. Have all been non-working with the old driver or will some users experience 
regressions?

> * If the consensus of the folks who have been around here longer than me
>   is that it does go into lum, I have no problem and will re-target this into
>   the lum git asap.  If so, do I add a ./updates/webcams dir for it to live

You mean lbm. But yes, a subdir for a class of drivers with an additional dir 
for the individual driver makes sense. Especially when we split up the one big 
package into more manageable chunks.

>   under or do I plop it in as a driver at the same level?  The
>   linkage in ./ubuntu seems pretty clear since it all falls under the kbuild
>   and main kernel makefile environment.  There seems to be some magic
>   here that I'd have do dup, i.e. where does $(src) in the top makefile
>   come from/get set from?  Is there a doc/wiki/README for this? Things
>   like the config files for the wireless are empty (of usable content other
>   that comments...) and the Makefile is a one liner so there is not much
>   to plagiarize.
> 

Not that I know of. In general it is the mechanism of the kernel to build 
external modules tied into debian packaging. So most magic comes from changing 
into the headers dir (the one that also contains .config and module versions) 
and then do a make M=<extmod dir>

> BTW, I'm a bit uncomfortable with separate but "co-mingled" git trees
> and the buried magic in multiple directory trees and the shell/makefile 
> scripts to tie them together.  I've had some version skew nightmares
> that still make me twitch so pardon my paranoia.  Is the ./ubuntu dir
> such a candidate for keeping such entropy under control?
> 

The alternative sounds more frightening to me. Putting things into this 
separate places at least shows there are changes to a released codebase that 
are modified. Less critical stuff gets into ubuntu (formerly lum) and the more 
risky into lbm which requires the user at least to make a known decision to 
install. Otherwise updates can break a system for no apparent reason.

> On another note that *should* be orthogonal to where the bits end up; is
> there any module load time glue that we supply?  That is one of the
> missing pieces between driver writers and udev rule writers at the moment.
> Do we have policy/criteria for this and if so, where do I find it?
> 
The glue at load time mostly is the search path of modules. And for completely 
separate new stuff this is just another module in anoter known location. The 
policy if you want to say so is the search paths/order defined in 
/etc/depmod.d/ubuntu.conf (installed by module-init-tools). Nothing scary. It 
gets hairy for drivers that share PCI or USB or whatever ID.

Stefan
-- 

When all other means of communication fail, try words!