Juju Migration

From IEEE 1394 FireWire Wiki
Revision as of 07:31, 8 December 2008 by Stefanr (Talk | contribs)

Jump to: navigation, search

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.)


Compatibility and stability

At the time of this writing (December 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.
  • Some missing features in the userspace ABI. See To Do.
  • A few remaining compatibility issues with some external devices, controllers and/or motherboards. Notably:
    • dvgrab cannot capture DV on OHCI 1.0 variants of VIA VT6306/6307 based cards. (VIA VT6307 and perhaps VT6306 chips can support OHCI 1.1 mode if reprogrammed to do so, see Utilities#vt6307ohciver.)
    • NVIDIA NForce2 and ALi M525x controllers don't work at all yet.
    • There are perhaps still problems with the Apple UniNorth rev.1 controller.
    • No support for PCILynx controllers. These do not implement the OHCI-1394 standard and are nowadays very rare, hence it is unlikely that support for them will ever be written for the new driver stack.
  • Missing IP over 1394 support.

Don't use the new drivers in Linux kernel versions older than They are too buggy.

Regarding Linux and later, the best advice to Linux distributors (kernel packagers) as well as to regular users is: Either build only the old IEEE 1394 drivers, or build both stacks as modules but make sure that only one of them (the one you want) is being loaded. I.e. create proper blacklist entries in /etc/modprobe.conf; see below. Also, you need to upgrade your userland to libraw1394 v2 if you want to switch to the new drivers (or freely between old and new drivers).

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 having trouble 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.

Permissions and ownership for /dev/fw*

Without any configuration file, the device files will be only accessible to root. This is fine and intended for SCSI block device files. But it is usually desirable to access the /dev/fw* character device files as non-root user.

The following example udev rule allows any user in group "video" to access /dev/fw* with programs such as dvgrab, kino, gscanbus, coriander...

# /etc/udev/rules.d/40-example-firewire.rules

SUBSYSTEM=="firewire", GROUP="video"

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 (storage devices, scanners etc.) should get restrictive file permissions and ownership. Actually, the default should be restrictive on most systems.
  • Files pertaining to ausio and video devices (AV/C or IIDC compliant nodes) can get liberal permissions so that they are accessible to application programs without root privilege.
  • Alas, libraw1394 clients currently require also access to the local node, hence its permissions need to be liberal too. To the author's knowledge, this does not have any actual security impact on systems on which user access to AV/C and IIDC devices is already allowed.

Here are rules to implement this finer-grained control over permissions, also using the example "video" group:

# /etc/udev/rules.d/40-example-firewire.rules

# Set GROUP="video" for some IEEE 1394 device types, driven by the new firewire stack.
# We cannot use the GROUP directive because the significant device type attributes
# live in child devices. So change the group after the fact with chgrp.

# IIDC devices: industrial cameras and some webcams
SUBSYSTEM=="firewire", ATTR{specifier_id}=="0x00a02d", ATTR{version}=="0x00010?",\
 PROGRAM="/bin/chgrp video /dev/%P"

# AV/C devices: camcorders, set-top boxes, TV sets, various audio devices, and more
SUBSYSTEM=="firewire", ATTR{specifier_id}=="0x00a02d", ATTR{version}=="0x010001",\
 PROGRAM="/bin/chgrp video /dev/%P"

# libraw1394 clients typically also need access to the local node(s). Alas there is
# no simple way to tell local nodes apart from remote ones; here is a simple hack.
SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video"

There are also schemes which are based on access control lists instead of UNIX file permissions. For example, the Fedora Linux distribution currently contains a mechanism to add read and write permission for the locally logged in user to the ACLs of fw* files of some FireWire device types.

Symlinks to SCSI block device files

Reasonably recent udev scripts create symbolic links in /dev/disk/by-id/*, pointing to the block devices of FireWire harddisks. These links are convenient for example to use them in static fstab entries: Their names are always the same because they are based on persistent and unique device identifiers, while the actual device files have arbitrary names that change all the time when disks are plugged in and out.

The names of the by-id links look per default a little bit different with firewire-sbp2 compared to 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.

You only need this if you plan to switch between sbp2 and firewire-sbp2 and if you are using the /dev/disk/by-id symlinks.

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?


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.



Compatibility with the new drivers is available since libraw1394 v2.0.0, released in July 2008. This version is able to transparently switch between old and new stack, depending on which drivers you have loaded.

Either get libraw1394 2.0.0 or later, or build libraw1394 from a fresh git checkout:

$ git clone git://dennedy.org/libraw1394
$ cd libraw1394/
$ autoreconf -fi
$ ./configure
$ make
$ sudo make install

Note the following requirements:

You need headers from a kernel with Juju support (at least 2.6.22 headers, better 2.6.24 headers). It may be necessary to install a recent kernel-headers package. Or you can point libraw1394's configure to a directory with these headers with "./configure --with-fw-dir=<dir>".

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 have a look at the following patches for libraw1394: patch 1, patch 2. They don't apply to recent versions of libraw1394 anymore though.

Libraw1394's Juju backend furthermore expects that the kernel was configured and built with the following options:


The inotify options are located in the "File systems" section of the Kconfig dialogs. CONFIG_EPOLL is already enabled in usual kernel configurations and not even visible in the Kconfig dialogs. But if the kernel was configured for embedded systems it may be necessary to switch CONFIG_EPOLL on explicitly; it is then found in the "General setup" section of the kernel configuration.


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
$ make
$ sudo make install

Note, the "--with-juju-dir" switch disables support for the old ieee1394 stack. If you want to switch back to the old drivers, you have to run "./configure" without this switch, rebuild, and reinstall libdc1394.

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.

Personal tools