Kristian Høgsberg posted an update on the effort to rewrite the Linux kernel FireWire stack [story] explaining, "as you may know, we've been working on a new FireWire stack over on linux1394-devel. The main driver behind this work is to get a small, maintainable and supportable FireWire stack, with an acceptable backwards compatibility story." He went on to request the stack's inclusion in the mainline kernel, listing the following highlights: the new FireWire stack "has been in Fedora rawhide (development branch) and -mm for 3 months, will be shipping in Fedora 7; backwards compatible at the library level, existing user space libraries have been ported to use the new user space interface; less than 8k lines of code compared to 30k lines of code in the old stack, and a similar size reduction in the sizes of the .ko's; no kernel threads, compared to one subsystem thread and one thread per FireWire controller in the old stack; one user space interface to support zero-copy scatter-gather streaming, as opposed to the old stacks 4 (was 5) different streaming interfaces; per-device device files, letting userspace set up more finegrained access control, such as preventing direct access to FireWire storage devices."
Kristian went on to note the following regressions when comparing the new stack to the old: "eth1394 not ported over, there is nothing preventing this from being done, though, but there's a couple of infrastructure bits that aren't done yet; no support for the PCILynx chipset, nobody has this chipset anymore, and the pcilynx driver in the old stack is bit-rotting anyway; some SBP-2 (storage) devices fail after significant amounts of IO, not clear what the problem is, but I can reproduce it here and am working on fixing it." Regarding his plans going forward, "what I'd like to propose is that we carry both the new and the old stack in mainline for a few releases. Once we've reached a satisfactory level of stability and worked through what regressions there may be, we can consider deprecating the old stack."
From: Kristian Høgsberg [email blocked]
Subject: [git pull] New firewire stack
Date: Tue, 01 May 2007 16:27:11 -0400
Hi Linus,
As you may know, we've been working on a new FireWire stack over on
linux1394-devel. The main driver behind this work is to get a small,
maintainable and supportable FireWire stack, with an acceptable
backwards compatibility story.
I've been talking to Stefan Richter about it and we feel that the new
stack is ready for inclusion into mainline. What I'd like to propose
is that we carry both the new and the old stack in mainline for a few
releases. Once we've reached a satisfactory level of stability and
worked through what regressions there may be, we can consider
deprecating the old stack. Carrying two FireWire stacks in the kernel
at the same time is not ideal, but it allows for wider testing of the
new stack, while keeping the old stack as a fallback for cases where
regressions make the new stack not usable.
There's a lot of good reasons to switch to the new stack and a lot of
reasons to switch away from the old one. Highlights:
- Has been in Fedora rawhide (development branch) and -mm for 3
months, will be shipping in Fedora 7.
- Backwards compatible at the library level; existing user space
libraries have been ported to use the new user space interface.
- Less than 8k lines of code compared to 30k lines of code in the old
stack, and a similar size reduction in the sizes of the .ko's.
- No kernel threads, compared to one subsystem thread and one thread
per FireWire controller in the old stack.
- One user space interface to support zero-copy scatter-gather
streaming, as opposed to the old stacks 4 (was 5) different
streaming interfaces.
- Per-device device files, letting userspace set up more finegrained
access control, such as preventing direct access to FireWire
storage devices.
Regressions:
- eth1394 not ported over. There is nothing preventing this from
being done, though, but there's a couple of infrastructure bits
that aren't done yet.
- No support for the PCILynx chipset. Nobody has this chipset
anymore, and the pcilynx driver in the old stack is bit-rotting anyway.
- Some SBP-2 (storage) devices fail after significant amounts of IO.
Not clear what the problem is, but I can reproduce it here and am
working on fixing it.
Please pull from the juju branch in Stefans repo:
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git juju
thanks,
Kristian
drivers/Makefile | 1 +
drivers/firewire/Kconfig | 60 ++
drivers/firewire/Makefile | 10 +
drivers/firewire/fw-card.c | 544 +++++++++++
drivers/firewire/fw-cdev.c | 954 +++++++++++++++++++
drivers/firewire/fw-device.c | 781 +++++++++++++++
drivers/firewire/fw-device.h | 149 +++
drivers/firewire/fw-iso.c | 163 ++++
drivers/firewire/fw-ohci.c | 1896 +++++++++++++++++++++++++++++++++++++
drivers/firewire/fw-ohci.h | 153 +++
drivers/firewire/fw-sbp2.c | 1165 +++++++++++++++++++++++
drivers/firewire/fw-topology.c | 519 ++++++++++
drivers/firewire/fw-topology.h | 94 ++
drivers/firewire/fw-transaction.c | 889 +++++++++++++++++
drivers/firewire/fw-transaction.h | 505 ++++++++++
drivers/ieee1394/Kconfig | 2 +
include/linux/firewire-cdev.h | 268 ++++++
17 files changed, 8153 insertions(+), 0 deletions(-)
From: Olaf Hering [email blocked]
Subject: Re: [git pull] New firewire stack
Date: Wed, 2 May 2007 14:21:47 +0200
On Tue, May 01, Kristian Høgsberg wrote:
> drivers/firewire/Kconfig | 60 ++
NACK.
Upgrade the current drivers/ieee1394/ with the new code, and keep all
existing module names.
From: Kristian Høgsberg [email blocked]
Subject: Re: [git pull] New firewire stack
Date: Wed, 02 May 2007 15:53:08 -0400
Olaf Hering wrote:
> On Tue, May 01, Kristian Høgsberg wrote:
>
>> drivers/firewire/Kconfig | 60 ++
>
> NACK.
> Upgrade the current drivers/ieee1394/ with the new code, and keep all
> existing module names.
What's your reasoning here? Having different module names allows people to
compile both stacks and switch between them as they wish.
Another point in favour of different module names is that the new stack
doesn't actually provide the same user space interfaces as the old stack.
Basically, no applications use the raw kernel interfaces and the new stack is
only compatible at the library level. In the light of this, I think it's fair
to change the module names.
As for putting the new stack in drivers/ieee1394 - I don't know, I think it
makes sense to keep the new stack in it's own directory. If it's a deal
breaker for inclusion, let's talk about moving it, but it would be nice if you
could elaborate just a little bit beyond "NACK".
thanks,
Kristian
