[RFC] Maverick - switch to new firewire stack.

Manoj Iyer manoj.iyer at canonical.com
Thu May 20 18:44:53 UTC 2010


During Lucid beta cycle we noticed that certain fire-wire drives don't 
mount. I did some investigation and I proposed that we switch from the old 
stack to the new stack in a blueprint:

https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-maverick-firewire-stack

* upstream recommends that distros should switch to the new stack, all new 
bug fixes, security fixes, and features will be in the new stack. Here is 
a link to bugzilla where known issues with the old driver are recorded but 
wont be fixed. https://bugzilla.kernel.org/show_bug.cgi?id=10046 . Wiki 
page on kernel.org says that there are some fundamental design & security 
issues with the old stack and that prompted the re-write of the stack.

* as per the proposed blueprint, the old drivers will be blacklisted and 
new drivers will be white-listed, this will be done as a fall back for 
users who experience issues migrating to the new drivers. Kernel config 
options are enabled already to build both old and new stack.

* as per the new fire-wire stack migration guide ( juju migration guide ), 
user space libraries should already work with the new drivers. We need 
help from foundations team to
  1. verify that the libraries listed in the migration guide, libraw1394 
and libdc1394, are installed are of the correct latest version. As per 
documentation the core libraries were already compatible back in 2008.
  2. modify udev rules to give /dev/fw* user access privilege, so that 
groups like video can read /dev/fw* as non root. As per the migration 
guide, rules have been merged into /lib/udev/rules.d/50-udev-default.rules 
of udev v144.
  3. blacklist ohci1394 sbp2 eth1394 dv1394 raw1394 video1394 and 
whitelist firewire-ohci firewire-sbp2 firewire-core firewire-net in 
/etc/modprobe.d/blacklist-firewire.conf. As far as I can see this is the 
only real change that needs to happen to make this switch.

* it will be desirable to make this switch before alpha1 and get it 
tested by community and also develop some tests targeted at firwire and 
include them in the kernel-qa suite. Kernel bug triage will issue a call 
for testing & track bugs against the new stack.

thoughts ?

Cheers
--- manjo




More information about the kernel-team mailing list