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(-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
