libraw1394 struct layouts, i386 vs. x86_64

Jarod Wilson jarod at wilsonet.com
Wed Jan 7 16:32:41 EST 2009


On Wed, 2009-01-07 at 16:00 -0500, Michael ODonnell wrote:
> 
> > I have no clue offhand what's up, but of curiosity, which firewire
> > is this?  The (really crappy) old ieee1394 stack, or the newer
> > firewire stack?
> 
> The app in question is a 32bit-compiled app that links with
> libraw1394 so I guess that means it's the (really crappy) old
> ieee1394 stack.

Not necessarily. libraw1394 works with both stacks. You have to look at
the loaded drivers or sysfs or /dev/ to figure out which is active.

If lsmod |grep ohci shows firewire-ohci, its the new stuff, if it shows
ohci1394, its the old stuff. If it shows both... That's a whole 'nother
mess... :)

> We intend to rebuild it as a 64bit app but that's
> not an option at the moment, and we heard good things about the 32bit
> compatibility of the x86_64 versions of Linux, so here we are...

In userspace, generally, yes. But once you start having to talk to the
kernel or a kernel driver, it often gets slightly messy -- as you've
seen, struct alignment issues can crop up, and you often need 32-bit
compat ioctls as well.

> > Hrm.  I frequent most of the firewire mailing lists out there and
> > haven't heard of this either, that I can recall.
> 
> Assuming this problem is what I believe it to be (32bit-compiled apps
> and libs disagree w/the 64bit-compiled kernel module [raw1394.ko,
> the one that implements /dev/raw1394]

That'd be old stack, but remember, just because you're using libraw1394
doesn't mean you're using raw1394.ko. But if you do have /dev/raw1394,
you're indeed on the old stack. (The new stack uses /dev/fw* for each
individual device, rather than a single raw interface for the entire
stack, which is a gaping security hole the new stack was written to
rememdy).

> about the layout of certain
> data structures) then it should be easy to reproduce this problem on
> RHEL5 or CentOS5 by trying to run any 32bit apps that link against
> /usr/lib/libraw1394* - they should choke pretty much immediately
> as they can't even complete the initialization phase.  There aren't
> many but I think Kino is one such app.

libiec61883's utilities, dvgrab, kino, coriander, and a few others too.
I'll put it on my todo list to poke at it some.



-- 
Jarod Wilson
jarod at wilsonet.com



More information about the gnhlug-discuss mailing list