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
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.
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94707
(510) 527-3856 FAX
This archive was generated by hypermail 2b29 : Mon Jun 12 2000 - 20:28:20 EDT