Kay Sievers wrote:
On Thu, May 21, 2009 at 17:26, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
