lkml.org 
[lkml]   [2006]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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: 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/

    \
     
     \ /
      Last update: 2006-12-14 18:53    [W:3.730 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site