[lkml]   [2006]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)
Gene Heskett wrote:
> On Wednesday 13 December 2006 22:32, Linus Torvalds wrote:
>>On Wed, 13 Dec 2006, Gene Heskett wrote:
>>> Ok, one not so silly Q (IMO) from the resident old fart. I saw,
>>> sometime in the past week, a relatively huge ieee1394 update go by.
>>> And I have some issues with the present 2.6.19 version causeing
>>> segfaults and kino go-aways when trying to capture from my firewire
>>> movie camera. Problems occur when trying to control the camera from
>>> kino.
>>> Is this patchset in this -rc1? If it is, I'll see if I can get a
>>> build to work and check it out.

This time everything which was in linux1394-2.6.git before the post
2.6.19 merge window went into 2.6.20-rc1. However it wasn't much
substantial stuff; we didn't get much done during the past few months.
Here is my pull message:

You can patch the ieee1394 drivers in 2.6.{19,18,16.x} to nearly the
same level as in 2.6.20-rc1 (that is, minus changesets which only
address in-kernel API changes) by means of the patchkit v212 from However I'm 99.9% sure
that it won't fix the problems you got.

>>-rc1 does include a reasonably big firewire update, but I'm not sure how
>>it will affect your camera usage. In fact, the ieee1394 people seem to
>> be trying to deprecate the dv1394 stuff, in favour of just raw1394 and
>> user-mode libraries.

That's right.

>>I think you can tell Kino to use either the DV or the raw interface, but
>>I'm not sure. If you can, try either. The raw interface seems to be
>>horribly misdesigned (security problems), but is the one to use.

These security issues are partly inherent to the IEEE 1394 architecture,
if I may say so. Dan Dennedy has a patch as work in progress to improve
raw1394's security towards devices as far as possible (while still
allowing non-root users access to /dev/raw1394, unless the administrator
thinks otherwise).

The other issue is security of the local host against attacks from
malicious external devices or other PCs. Here the issue is with
OHCI-1394's physical DMA feature and the fact that the sbp2 driver needs
it enabled. I'm planning to implement filtered physical DMA as a simple
security improvement and, at some day in a /distant/ future, implement a
DMA mapping in sbp2 to work completely without physical DMA.

(Anyway, that's unrelated to Gene's issues.)
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: 2006-12-14 18:53    [W:0.192 / U:4.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site