[lkml]   [2007]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[git pull] New firewire stack
    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.


    - 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:// juju


    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-01 22:31    [W:0.024 / U:40.336 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site