[lkml]   [2005]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: eth1394 and sbp2 maintainers
Matthias Schniedermeyer wrote:
> Rogério Brito wrote:
>>Let me add my voice to the choir here. I agree with Randy when he says
>>that Stefan does a superb job supporting firewire with Linux.
> Then let me be the voice telling about the flip-side.

...or me, for that matter. :-) Firstly, maintenance is a different job
than answering questions on linux1394-user or posting a few patches.

> I've used Firewire with SBP2-driver for nearly 4 years and most of the
> time there was one problem or another (beginning from not-SMP-safe to
> "plainly not working" for nearly a year, where i had to downpatch
> Firewire (The nodemanager "desaster") for a very long time)

Sbp2 has been working very well under many Linux 2.4 releases. But there
were some severe regressions under Linux 2.6.

> When the last problem crept up (sbp2-module couldn't be unloaded if only
> a none-HDD-device was connected) i was so feed up with the continuous
> hassle that i completly replaced my firewire hardware with USB2 Hardware.

This very old problem of Linux 2.6 was recently fixed. But the fix is
not yet available in any released kernel.

> With USB pluging/unplugging works flawlessly (couldn't say that for 4
> years Firewire). Operating several devices concurrently works flawlessly
> (I was lucky when my 2 devices worked concurrently with Firewire. Most
> of the time only 1 device couldn't be connected without risking
> desaster), in constrast i've had 10 HDDs running concurrently connected
> via USB2 without a problem!

The hotunplug bugs made usage of multiple devices difficult or even
impossible, and they prevented implementation of some enhancements for
usage of multiple devices on the same bus. Fortunately these bugs are
out of the way now.

But besides that, there are still big issues with SCSI command aborts
especially with soft RAID over sbp2 and with some firmwares, notably
those with firmware-"R"AID-0. There is no prognosis yet if and when
these more elusive problems will be sorted out.

> I know that i may have skipped the time where USB hasn't been mature to
> the time where USB was mature, but it got there. So forgive me when i'm
> too negative about firewire and too positive about USB.

On the other hand, there have also been positive reports about usage of
multiple SBP-2 devices. (I have several too, though mostly quality
brands...) But you are absolutely right that sbp2 has not been reliable
for a long time, and still isn't quite there.

> To say it short:
> - Firewire and especially SBP2 haven't been very mature in my 4 YEARS(!)
> using it.
> - As far as i see the userbase just isn't big enough to make it mature.

Yes, there is a smaller user base than for usb-storage. Combine this
with the complexities of IEEE 1394 and SCSI and of their respective
Linux implementations, plus near absence of any commercial interest in
SBP-2 support for Linux. All this contributes to lack of manpower in
development and lack of maintenance routine, IMO.

> Taking aside some niche usages, i guess firewire WILL DIE because of USB
> sooner then later. For me firewire died 6 month ago. Rest in peace.

FireWire won't die because of USB. There are fields of applications
which FireWire and USB do not share. Sure, FireWire for _storage_
applications will definitively lose more of its already weak market
share to USB (cheap and slow) and to external SATA (cheap and fast). But
FireWire won't vanish from storage applications completely, thanks to a
few unique features like multiple initiator capability, the ability to
power even 5.25" drives by bus power, or choice of special-purpose cable
or fiber media.
Stefan Richter
-=====-=-=-= =--= -==--
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: 2005-09-12 18:42    [W:0.028 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site