Bug 6290 maintained since 2006

Andy Whitcroft apw at canonical.com
Thu May 20 14:39:52 BST 2010


Added Cc: for the ubuntu kernel team.

On Thu, May 20, 2010 at 03:12:28PM +0300, Mikko Lempola wrote:
> Hi!
> 
> 
> Your decision  to support old ieee1394 stack instead of new firewire
> subsystem was argued "To maintain backwards compatibility
> blacklist the new one.     LP: #276463"
> /usr/share/doc/module-init-tools/changelog.Debian.gz
> 
> but this led to an unfortunate situation; an old problem - firewire capture,
> which is not workin by default - is still hanging around. To put it simply,
> the situation is this:
> 
> 
> –   Most camcorder users can't capture their video to the computer because
> of default settings.  –
> 
> Of course, this has to be repaired immediately.
> 
> 
> 
> It seems that this old bug dating back to year 2006 (!) is here again
> causing even Ubuntu 10.04 suffering from it when trying to capture DV from
> camcorder to computer.
> https://launchpad.net/ubuntu/+source/kino/+bug/6290
> 
> 
> 
> 
> 
> Suggestions to kill this bug:
> 
> 1.  Just use the new firewire subsystem and blacklist the old one
> 2.  If the above is rejected for some reason even for a short period of
> time, please give us official launchpad note that you are aware of the
> situation. Please, let us know as well why any supported Ubuntu program is
> not capable of capturing video from dv-camcorders. They are still mainstream
> technology to most users. Of course, while on the internet there are several
> hints to deal with this bug, some of them are not effective and some raise
> up discussion about the security risks. Therefore your opinion concerning
> this issue should be in launchpad.
> https://launchpad.net/ubuntu/+source/kino/+bug/6290

The reason it is not just simply switched is related to regressions.
Just because switching it may fix your issue does not mean it will not
break even more people who are currently working, a key mantra in all
released versions of Ubuntu.  As I recall we actually have both kernel
stacks enabled for Lucid and indeed for all of the releases since the
new stack was added to the kernel; it is a matter of changing which
is blacklisted in userspace to select the active stack.  However, as I
understand things switching the kernel stack from old to new also means
switching from one userspace stack to another and it is here wherein the
risk lies.  This is a big deal and not likely something we can engineer
for Lucid in an update.

For Maverick we have already taken the action to review which stack is
being used by default and interlocking with other teams to see which stack
will be default.  This is likely something which would be acceptable if
done before the first alpha.

-apw



More information about the kernel-team mailing list