9/17/2007
More Firewire Complaints
So I’ve been working on trying to sort heads from tails from all the Firewire support in Linux. And unfortunately it appears that Firewire support in Linux suffers from the bash it real quick until it works and leave it be. All of the developers that work on the core parts and the userspace libraries, are all maintainers of consuming applications so they really don’t bother themselves with fleshing out the userspace libraries too much. In fact, libraw1394 is the only library that’s documented at all, and even that is an old version. The other libraries are simply read the source, which has no comments. The other bit that adds complication is that the new Firewire stack called juju which went into 2.6.22 and is enabled by Fedora Core 7 by default doesn’t even have support from the userspace libraries which are writing by the same guys that wrote the kernel code. Sure you can do a git checkout of their latest juju branch and get a what they call “mostly” working libraw1394 and libdv1394, but that’s still not considered a release by any means if you have to use git.
My biggest complaint however is with libavc1394. Someone clearly just simply wrapped the firewire spec and the library shouldn’t even be called a library. It’s a set of a handful of functions that require the developer to use the 200+ defines and bitwise add them together to make a valid command and send that out using one of the few functions available. Why this isn’t abstracted away properly for the developer I don’t know. There’s also wonderful stuff in here like returning “quadlet_t *” (which is simply a guaranteed 32 bit int) but no where does it say what the data is or how long it will be. Turns out if you scour the code, you will learn it’s always 8 long. But hey, who needs documentation? Another wonderful thing is that you have to send commands to specific item types on a specific subunit of a node. Now you can query if the node supports a specific type but there’s no way to programmatically determine the subunit that type is on. This results in most apps having a set of vendor IDs and model IDs and hardcoding it based on this. Also since there are so many bitwise operations required by the developer of an application, all apps I’ve found hardcode some of this to some extent since it was obviously too complex to do correctly to support all types.
A library should be an abstraction to take the difficultly out of the task, not to add additional difficultly.
Filed under: Linux
One Response to “More Firewire Complaints”
Leave a Reply
November 25th, 2007 at 2:17 pm
I am working on firewire stack on ppc8349,
I am facing the same problem,nothing is documented in kernel level.only libraw1394 is documented.
Did you got any documentetion…or only way is go through the code?