Re: unwise IEEE 1394 udev rules from Ubuntu merged into mainline

[Pieter Palmers <pieterp@joow.be>]

Kay Sievers wrote:
> On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> 
>> But wait, why actually fix the issue if you can instead provide a workaround
>> which (a) demonstrates that you don't actually know what you are doing, (b)
>> doesn't actually fix the problem, (c) entirely destroys the ability to run
>> FireWire enabled software --- desktop/ consumer oriented software as well as
>> professional software.
> 
> It's common practice and nothing wrong in general when people try to
> disable/restrict stuff they "don't understand".
> If I remember correctly, you have been in the discussion, that finally
> lead to this decision. I think, it's _your_ part to lead them to the
> proper solution then, instead of finger-pointing distros and tell them
> later, they don't know what they do. :)
> 
>> PS:
>> Perhaps I should finally copy the physical DMA filtering from the new
>> drivers to the old drivers
> 
> I don't think so.
> 
>> but then I have endless other things to do,
>> things with actual practical importance.  Like getting the new drivers fully
>> featured.  However, I'm seeing an increase of trivial end user support
>> questions coming onto myself and all the Linux 1394 libraries & applications
>> developers in the near future. --- One way or another, we need to get back
>> usable FireWire access defaults.
> 
> I guess you should finally deprecate the old drivers, and comment-out
> the Kconfig entries in the kernel sources, so people/distros who want
> to use the old drivers would need to patch that in, to compile it.
> Otherwise nothing will ever change. Many people/distros don't know
> much about firewire, and will never switch-over, unless _you_ create
> an incentive for them.
> 
> Firewire is not very commonly used, and having two completely
> different implementations in the same kernel sounds really
> inefficient, and it splits the pretty limited resources into two
> camps.
> 
> Having a "stable" and a "new" stack, like they are called in the
> kernel config, and having a warning there, that only one of them
> should be used, does not really send a clear message either - and
> that's what people need. :)
> 
> You are doing a really great job caring about both of the stacks and
> keep them running, which is very nice from a subsystem maintainer
> standpoint. But I think at a larger scale, i think, it just makes
> things worse than going through the one-time pain of finally
> switching-over, and fixing the remaining issues.

The reports I got up till now are that FFADO doesn't work with the new 
stack, notwithstanding the fact that its a 100% userspace library that 
only accesses the firewire bus through libraw1394. In theory this would 
mean that the underlying kernel stack doesn't matter as libraw1394 
abstracts that. In reality that isn't the case.

I would like it if the current ('old') stack would not be deprecated 
before the new one actually works.

Greets,

Pieter