[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora too cutting edge?

Hash: SHA1

Fernando Pablo Lopez-Lezcano wrote:
> On Wed, 9 Jan 2008, Hans de Goede wrote:
>> Notice how a preliminary fix is expected for 2.6.25, which probably
>> means that this will still be broken in Fedora 9, notice that the
>> breakage was introduced in Fedora 7, so thats 18 months worth of
>> broken firewire camera support (iow most digital video cameras).

No, we can add said preliminary fix to the F9 (and earlier) kernels. In fact,
I'm inclined to add the OHCI 1.1 iidc fixes from David Moore to rawhide later
today, as well as port them to the 1.0 code (which I'd also include).

> _and_ firewire audio interfaces as well.
> Which forced me and others to return to the original stack in my
> realtime tuned kernels for Planet CCRMA. And unpatch the corresponding
> libraries. And keep track of the whole mess. A royal pain you know
> where. Planet CCRMA is about audio. Non working interfaces that were
> working before is not good.
> If you ask me, 18 months is way too long. It is/was a failed experiment.

Nah, its not failed, its just not complete. It works quite well where it does
work -- sbp2 devices and dv capture. In the sbp2 case, it works far better
than the old stack ever did. We're just a bit lacking in man power to fix up
the broken things. Rather than spend time working on fixing the new stack,
people run back to the old stack.

Of course, I understand some people need things to be working NOW, but there's
a chicken and egg problem there. I don't do any firewire audio stuff, so
offhand, I don't have a clue how to fix the particular problems you're seeing
(I'm not even sure *what* the problems are). The things I do (sbp2 storage and
dv capture) pretty much Just Work -- and dv capture only does so on (most)
OHCI 1.0 controllers, because I sat down and wrote the OCHI 1.0 isochronous
receive support code (with lots of help from krh, mind you, since I knew
nothing about the code going in).

> My opinion is that the new stack was not and still is not ready for
> inclusion in a mainstream distro. It just breaks too many things that
> people actually need to do work on the computer running that kernel.

Another chicken and egg problem. How do we know it doesn't work if we don't
ship it?

>> What IMHO we should have done is build both the new and the oldstack,
>> which is possible on the kernel side, and modify our patches to
>> userspace to support the juju stack, so that the userspace libs can
>> work with either one. On top of this we should then have written a
>> small gui utility for easy switching.
> Yup. Or wait till the stack actually works. But then a big chorus will
> probably say if we don't ship it it will not get fixed or whatever.

Yeah, I'm part of the chorus.

> But
> it has been shipped for a long time and not fixed so I _don't_ buy that
> argument.

Admittedly, we've been rather slow to fix things, so I do understand your not
agreeing with the chorus. :)

But things *are* improving, and we *do* intend on continuing to fix things.
We're just a bit short on man-power to actually sit down, reproduce problems,
debug and fix them. I only recently got familiar with the kernel code myself,
and my day job deals mainly with RHEL kernel stuff, but I'm quite happy to try
to help out with any Fedora firewire bugs still outstanding (several are
already on my plate). If you have any open bugs, or want to file any new ones,
please do. Assign them to me (jwilson redhat com) and cc Kristian
(krh redhat com) and Jay (fenlason redhat com).

> Agreed... At least firewire has been broken for too long (IMHO)


- --
Jarod Wilson
jwilson redhat com

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]