Subject: P1394> Re: Device discovery on 1394

From: [email-masked]
Date: Tue, 17 Jun 1997 13:41:52 -0400 (EDT)

In a message dated 97-06-17 08:21:42 EDT, [email-masked] (Danny Mitchell)
writes:

<<I believe the problem I am seeing is the easy determination of what type of
devices are out there.  For example in current os's a generic monitor driver
can be loaded just by knowing an unknown device is a monitor.  For a printer
or other generic device ( like a camera complying with the sony desktop
camera specification ) could be loaded.  In the case of a low-end digital
camera,  the camera would like to be able to assess that a printer is out
there that would support the "Digital Still Image" protocol with very little
overhead.>>

I'm still uncertain as to whether or not you and the PWG believe there is a
difficulty.

I read what you've written above and say to myself, "Ya, sure...that's the
way it works."

Is there agreement that it is a Unit Directory that identifies the presence
of any particular 1394 device? If we are, the searcher (the digital camera in
your example) needs to read configuration ROM of the other nodes on the bus.

OK. No there's the question of the order in which you determine a) protocol
and b) device type. At the moment the presumed order is protocol first,
device type second. This is because there is no universal registration
authority to assign device class ID numbers---it is left to the specifier of
the protocol to assign numeric values to device class ID's. The SCSI family
of commands is one illustration: you have to know that the device is a SCSI
device, first, before you can discover that device type 0x02 means a printer.

Could you be more specific as to where you think the problems, if any, lie?

Regards,

Peter Johansson

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

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

[email-masked]

---

From: [email-masked]
Date: Wed, 18 Jun 1997 14:55:57 -0400 (EDT)

In a message dated 97-06-17 11:28:34 EDT, [email-masked] (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.

Regards,

Peter Johansson

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

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

[email-masked]