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. Thanks, Kay -- 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
