Stefan Richter posted the IEEE1394 subsytem and FireWire subsystem TODO lists noting, "it seems also appropriate to disclose the current manpower behind FireWire driver development and maintenance. There are just two people who regularly work on the drivers: Kristian Høgsberg (author and maintainer of the new firewire subsystem, in the past also involved with the old ieee1394 subsystem) and me (co-maintainer of both the new and old subsystems). But we both have a lot of other projects going on at the moment."
The current IEEE1394 subsystem is available for the 2.6 and 2.4 kernels, also known as the Linux1394 driver stack. Kristian Høgsberg started development of the new FireWire stack, nicknamed "Juju", in December of 2006. The Linux1394 website notes, "when the new stack's initial bugs and missing features have been addressed, it is anticipated that the old driver stack (ieee1394, ohci1394, pcilynx, raw1394, video1394, dv1394, sbp2, eth1394) will be scheduled for removal from the mainline kernel sources. (There is by the way no replacement for pcilynx planned at the moment, because this controller has become very rare.) The main reasons to replace the old stack by the new one are: lower code footprint, hence lower maintenance cost; better security; consolidation of the currently three or four different userspace ABIs (depending on how you count them) into a single, modern ABI."
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."