P1394 Mail Archive: Re: P1394> Re: Device discovery on 1394

P1394 Mail Archive: Re: P1394> Re: Device discovery on 1394

Re: P1394> Re: Device discovery on 1394

Wed, 18 Jun 1997 14:55:57 -0400 (EDT)

In a message dated 97-06-17 11:28:34 EDT, atsnaka@mxa.meshnet.or.jp (Atsushi
Nakamura) writes:

<<The unit_directory definitions of current transport protocols is defined in
a way that the initiator will discover the characteristics of a node by it's
protocol first, and then finding the actual device function by "talking"in
that protocol It shows that the current ROM definitions support
protocol(device) discovery, but not function device discovery.>>

"Talking" in the specific protocol is not necessarily as involved as sending
a command in the protocol. SBP-2 defines a device type field in configuration
ROM that can be simply accessed. See the Logical_Unit_Entry, described in
7.3.9 of the SBP-2 draft.

<<PWG/PWG-C's approach to the device discovery scheme (not the printing
protocol, they are separate because device discovery is a scheme that applies
to any device, not just printers.) is to provide a common
(protocol-free)"short-cut" to discovering the "device",or functions FIRST,
then the protocol it supports. It will not conflict with the existing ROM
definitions (SBP-2,FCP), but co-exist so that the initiator can choose
discovery paths; existing ROM definitions for protocol-first device
discovery, and the PWG/PWG-C path for function-first device discovery.>>

This is an interesting and worthwhile discussion to have, but because it
hinges on the matter of a central registration authority it is a higher level
matter than PWG-Xxxxxxx. Perhaps the IEEE P1212 revision project should
undertake this.

Unfortunately, your assertion that "...it will not conflict with existing ROM
definitions..." is not true. The meanings of ALL entries in the unit
directory are specified by either a) ISO/IEC 13213:1994 (the CSR
architecture) or b) the organization or company that owns the 24-bit ID in
the Unit_Spec_ID entry in the unit directory.

Issues like this need broader visibility or it is likely that a number of
incompatible solutions will be developed.

I suggest that the matter of device function identification be addressed at
the July meeting of the Architecture working group at the 1394 Trade
Association meeting.


Peter Johansson

Congruent Software, Inc.
3998 Whittle Avenue
Oakland, CA 94602

(510) 531-5472
(510) 531-2942 FAX