P1394 Mail Archive: Re: P1394> Logical_Unit_Number - Device_

P1394 Mail Archive: Re: P1394> Logical_Unit_Number - Device_

Re: P1394> Logical_Unit_Number - Device_Type field question

From: Peter Johansson (PJohansson@ACM.org)
Date: Mon Jun 12 2000 - 20:10:33 EDT

  • Next message: Farrell, Lee: "RE: P1394> PWG-1394 Mtg in San Fran"

    At 04:40 PM 6/12/00, RICE,CHUCK (HP-Vancouver,ex1) wrote:

    >The last sentence on page 49 of Draft 1.1 of the 1394.3 spec reads: "The
    >device_type field shall be 1F, unspecified device type.". I was wondering
    >if someone could shed some light as to why 1F is mandated for
    >device_type. If the device_type is required to be unspecified then what
    >determines the device type associated with the Unit directory?

    The discovery of "device type" was the whole point of "service discovery",
    which may have evolved (or devolved) into something other than what was
    first imagined.

    The device_type field is strongly connected to command set. See, for
    example, implementations of RBC (reduced block commands, aka simple disks)
    via SBP-2. It's easy to report a device_type of zero (direct access) since
    all the commands pertain to disks.

    In the case of P1394.3, the "commands" are the transport flow ORBs. These
    "commands" describe the movement of generic data; they do not concern
    themselves with the nature of the data.

    IF (a very big "if") P1394.1 described some device_type value for printers,
    some for scanners, what would this mean?

    > An example of this would be an MFP that implements a PPDT Printer and a
    > PPDT Scanner. If a device does not list it's device type in the Instance
    > Keyword leaf or if someone gets to the Unit directory without going
    > through the Instance directory; what would differentiate the Unit
    > directories of the printer and the scanner? How would the initiator know
    > which one is which?

    You've described exactly why the instance directories (and their keywords)
    are to be used!

    Imagine a dual-purpose device that can print and can also scan. It could
    have two unit directories, one pointed to by an instance correlated with a
    "PRINT" keyword and the other by one that refers to "SCAN". The device
    might implement a PRT_SVC and a SCAN_SVC. Unless the designer added a
    sanity check to prevent it, it might easily be the case that either service
    is accessible from either logical unit! The point of mentioning this is
    that the identity of the logical unit is arguably less important than the
    identity of the service to which one connects.


    Peter Johansson

    Congruent Software, Inc.
    98 Colorado Avenue
    Berkeley, CA 94707

    (510) 527-3926
    (510) 527-3856 FAX


    This archive was generated by hypermail 2b29 : Mon Jun 12 2000 - 20:28:20 EDT