Migration to the new FireWire driver stack

Watch this page for future updates on migration requirements.
(Or better yet, add here what you know about it.)

Contents

Migration to the new FireWire driver stack

Compatibility and stability

At the time of this writing (01/2008), there are still multiple problems with the new FireWire kernel driver stack (alias Juju) compared to the old stack:

Lacking userspace integration. See Libraries.
Lack of testing. Therefore compatibility issues with some controllers and external devices.
Missing support of isochronous I/O over OHCI 1.0 cards. This has been fixed in Linux 2.6.24-rc5. There are still problems with isochronous reception on some OHCI 1.0 variants of VIA VT6306/6307 based cards. Cameras and audio devices are unusable with the new drivers if you have such a chip. (VIA VT6307 and perhaps VT6306 chips can support OHCI 1.1 mode if reprogrammed to do so, see vt6307ohciver information at Links/Software/Utilities.)
Almost no support for IIDC cameras: Not compatible with libdc1394 v1. Highly experimental support in libdc1394 v2 which works with some luck on only a few OHCI 1.1 controllers. Improvements are to be expected in Linux 2.6.25-rc1.
Stability issues of the storage device driver firewire-sbp2 on some hardware. This is being gradually improved in each new kernel version.
Missing IP over 1394 support.

Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors (kernel packagers) as well as to regular users is: Build only the old IEEE 1394 drivers.

Building the new drivers is only for advanced users (who for example want the better speed of firewire-sbp2 relative to sbp2) - and for distributors who know what is required in userspace to make use of the new drivers and who can get bugfixes backported and rolled out quickly.

Building both the new drivers and the old drivers together is only for advanced users and for distributors who know exactly how to handle this. E.g. create blacklist entries in /etc/modprobe.conf to control which drivers are loaded.

In any case, whoever builds kernels, please mind the "EXPERIMENTAL" tag on the new driver stack's Kconfig prompt. Of course the developers like to hear if you are HavingTrouble with the new drivers.

Why the migration?

The code base of the new stack is smaller, cleaner, and closer follows modern Linux kernel programming paradigms. There are already some features in the new stack which the old one lacks, notably bus manager capability and so-called gap count optimization. The latter provides a noticeable speedup of SBP-2 and other asynchronous protocols. Instead of 3 or 5 userspace interfaces in the old stack, there is a single universal interface in the new stack. Furthermore, there are some fundamental bugs and security considerations with the old stack which to a large part motivated the rewrite of the driver stack.

FIXME: Add a Wiki page on FireWire security.

Module auto-loading

How to get auto-loading

The drivers firewire-ohci and firewire-sbp2 contain the module aliases "pci:v*d*sv*sd*bc0Csc00i10*" and "ieee1394:ven*mo*sp0000609Ever00010483*" which should suffice with hotplug scripts and recent coldplug scripts to automatically load these two drivers when respective hardware is detected. The dependence of both drivers on firewire-core is of course recognized by modprobe.

If the kernel was configured without ohci1394 and sbp2 as modules, then firewire-core and firewire-sbp2 also contain the module aliases ohci1394 and sbp2 respectively. That is, "modprobe ohci1394" will load firewire-ohci (and firewire-core) instead of ohci1394 if ohci1394 was excluded from the kernel build.

How to suppress auto-loading

To avoid confusion, it is recommended that either the old or the new driver stack is built, but not both together. It is nevertheless possible to build and install both stacks together. If you chose to do so, you may want to add lines like

#blacklist firewire-ohci
#blacklist firewire-sbp2

blacklist ohci1394
blacklist sbp2
blacklist dv1394
blacklist raw1394
blacklist video1394

to /etc/modprobe.d/file_of_your_choice or /etc/modprobe.conf to suppress auto-loading of one of the stacks. Very old modutils which do not support the blacklist keyword can be instructed by

# install firewire-ohci /bin/true
# install firewire-sbp2 /bin/true

install ohci1394 /bin/true
install sbp2 /bin/true
install dv1394 /bin/true
install raw1394 /bin/true
install video1394 /bin/true

to suppress loading of one of the stacks.

Character device files, block device files

Basic operation

Out of the box, udevd and udev scripts automatically create and remove

/dev/fw* devices exposed by firewire-core (for use by libraries like libraw1394 and libdc1394, provided the libraries are updated),
/dev/{sd,sg,sr,st}* devices exposed by SCSI command set drivers (sd_mod, sg, sr_mod, st) with firewire-sbp2 underneath.

Extra features

By evaluating information in firewire-core's sysfs files, it is possible to automatically adapt file permissions and ownership of /def/fw* files according to device types. Files pertaining to local nodes (the controllers) and SBP-2 nodes should get restrictive file permissions and ownership. Files pertaining to AV/C nodes (camcorders, set-top boxes, and the like) and IIDC nodes (industrial cameras, some webcams) can get liberal permissions so that they are accessible to application programs without root privilege.

FIXME: Explain how to set file permissions based on device properties.

The /dev/disk/by-id/* symlinks which reasonably recent udev scripts create for FireWire harddisks look per default a little bit different with firewire-sbp2 versus sbp2. To make them look exactly the same, add the following to /etc/modprobe.d/file_of_your_choice or /etc/modprobe.conf:

options sbp2 long_ieee1394_id=y

This option has been added to sbp2 in Linux 2.6.22.

Hald support

It has been reported that firewire-sbp2 driven disks don't show up on desktops, even though they are recognized by the drivers and can be manually mounted just fine.

FIXME: Is special support by hald required?

Initrd

Scripts which generate initrd (an initial RAM disk used during boot) may need to be updated to deal with the new kernel module names firewire-core, firewire-ohci, firewire-sbp2. Scripts within initrd may already work with the new drivers, see Module auto-loading.

Libraries

libraw1394

There is a compatibility extension for libraw1394 but

it has not been integrated into a libraw1394 release yet,
it is not feature-complete, and
if it is patched in it disables support for the old raw1394 driver.

Steps to build libraw1394 for use with firewire-core:

$ git clone git://people.freedesktop.org/~krh/libraw1394
$ cd libraw1394/
$ git merge origin/juju
$ autoreconf -fi
$ ./configure --with-juju-dir=/usr/src/linux/include

Update: There is work in progress to make libraw1394 work with either stack without compile-time switch.

Note, the Juju backend of libraw1394 requires the inotify kernel interface. If you have got an old libc which does not contain support for inotify, you can try the following patches for libraw1394: patch 1, patch 2

libdc1394

There is compatibility with libdc1394 v2, released in January 2008. Many deployed libdc1394 applications still use the older libdc1394 v1 though which has no support for the Juju drivers.

Depending on your distribution, libdc1394 v2 packages may exist with enabled Juju support. On Gentoo Linux, the "juju" use flag enables Juju support.

If life on the bleeding edge appeals to you, you can check libdc1394 v2 out from Subversion and build it with Juju support by the following steps:

$ svn co https://libdc1394.svn.sourceforge.net/svnroot/libdc1394
$ cd libdc1394/trunk/libdc1394/
$ autoreconf -fi
$ ./configure --with-juju-dir=/usr/src/linux/include

FFmpeg: libavformat

Alas the dv1394 module of FFmpeg's libavformat has not been ported to firewire-core yet. This particularly affects players like MPlayer and Xine.