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. :)
Well, I do have accounts in some distro bugtrackers because I sometimes
look there for potential upstream bugs. Other than that, I admit a
serious lack of interest in what distros do. My comments in this
particular Ubuntu bug were also not driven by actual interest in what
the Ubuntu maintainers decide --- especially since Ubuntu has so far
been the only distribution which chose to block user access to /dev/raw1394.
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.
I would love to do that, but we need to accomplish two major things
before we can finally pull the plug on drivers/ieee1394:
1. Implement IP over 1394 for the new stack. Somebody is working on
it; code has been seen on linux1394-devel now.
2. Get professional/ semiprofessional audio streaming via FFADO
going. Right now there are show-stopping problems but we don't
even have a proper anamnesis yet.
To solve problem two, there are two fronts which can be attacked
independently:
- Make control and streaming through libraw1394 + firewire-cdev
(at least as well) work like libraw1394 + raw1394 work now,
- implement an ALSA interface which us used for streaming IO
instead of the generic firewire-cdev interface.
Somebody plans to work at the second front during summer.
Oh, perhaps there is also a 3rd item:
3. Provide an attractive alternative to those who find dv1394
still to fit their bill. (That's a special purpose driver
with an oddball configuration interface, but it seems to be
still OK for NTSC at least.)
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.
Correct.
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. :)
Well, it's really hard to give a simple message which is understood
easily and true to everyone's need.
I deliberately did not remove the "experimental" label from the new
drivers yet --- not because they crash all the time (they don't anymore)
or because they had lesser device compatibility (as far as I can tell,
they offer more stable device discovery than the old drivers, except
that two or three rare and old controllers don't work yet but do
partially work with the old drivers) --- but because there are some
features which are not yet available in the new stack, see above.
Some crucial features for professional video acquisition have been added
in kernel 2.6.30 but userspace (libdc1394) is not yet up to date with
these .30 additions.
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. And yes, in retrospect I wish I had ramped down my work with
ieee1394 quicker so that more time had been spent on firewire.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
--
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
