• Stefan Richter's avatar
    firewire: cdev: fix ABI for FCP and address range mapping, add fw_cdev_event_request2 · e205597d
    Stefan Richter authored
    The problem:
    
    A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
    needs to be able to act as responder and requester.  In the latter role,
    it needs to send requests to nods from which it received requests.  This
    is currently impossible because fw_cdev_event_request lacks information
    about sender node ID.
    Reported-by: default avatarJay Fenlason <fenlason@redhat.com>
    
    Libffado + libraw1394 + firewire-core is currently unable to drive two
    or more audio devices on the same bus.
    Reported-by: default avatarArnold Krille <arnold@arnoldarts.de>
    
    This is because libffado requires destination node ID of FCP requests
    and sender node ID of FCP responses to match.  It even prohibits
    libffado from working with a bus on which libraw1394 opens a /dev/fw* as
    default ioctl device that does not correspond with the audio device.
    This is because libraw1394 does not receive the sender node ID from the
    kernel.
    
    Moreover, fw_cdev_event_request makes it impossible to tell unicast and
    broadcast write requests apart.
    
    The fix:
    
    Add a replacement of struct fw_cdev_event_request request, boringly
    called struct fw_cdev_event_request2.  The new event will be sent to a
    userspace client instead of the old one if the client claims
    compatibility with <linux/firewire-cdev.h> ABI version 4 or later.
    
    libraw1394 needs to be extended to make use of the new event, in order
    to properly support libffado and other FCP or address range mapping
    users who require correct sender node IDs.
    
    Further notes:
    
    While we are at it, change back the range of possible values of
    fw_cdev_event_request.tcode to 0x0...0xb like in ABI version <= 3.
    The preceding change "firewire: expose extended tcode of incoming lock
    requests to (userspace) drivers" expanded it to 0x0...0x17 which could
    catch sloppily coded clients by surprise.  The extended range of codes
    is only used in the new fw_cdev_event_request2.tcode.
    
    Jay and I also suggested an alternative approach to fix the ABI for
    incoming requests:  Add an FW_CDEV_IOC_GET_REQUEST_INFO ioctl which can
    be called after reception of an fw_cdev_event_request, before issuing of
    the closing FW_CDEV_IOC_SEND_RESPONSE ioctl.  The new ioctl would reveal
    the vital information about a request that fw_cdev_event_request lacks.
    Jay showed an implementation of this approach.
    
    The former event approach adds 27 LOC of rather trivial code to
    core-cdev.c, the ioctl approach 34 LOC, some of which is nontrivial.
    The ioctl approach would certainly also add more LOC to userspace
    programs which require the expanded information on inbound requests.
    This approach is probably only on the lighter-weight side in case of
    clients that want to be compatible with kernels that lack the new
    capability, like libraw1394.  However, the code to be added to such
    libraw1394-like clients in case of the event approach is a straight-
    forward additional switch () case in its event handler.
    Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    e205597d
firewire-cdev.h 31.5 KB