Messages in this thread | | | Date | Thu, 14 Dec 2006 18:48:30 +0100 | From | Stefan Richter <> | Subject | ieee1394 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: http://lkml.org/lkml/2006/12/07/323
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 http://me.in-berlin.de/~s5r6/linux1394/merged/. 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 -=====-=-==- ==-- -===- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |