[git pull] New firewire stack

[Kristian Høgsberg <krh@redhat.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/