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.
This is where the PWG(s) are coming from.
Unless you are stating that the >From: PJohansson@aol.com
>Date: Fri, 13 Jun 1997 13:47:41 -0400 (EDT)
>To: DMitchell@ti.com
>Subject: Re: Device discovery on 1394
>
>In a message dated 97-06-13 07:22:56 EDT, DMitchell@ti.com (Danny Mitchell)
>writes:
>
><< Even if we decide to use an SBP2 transport protocol there is no method for
> device discovery. This begins to push us to an FCP like protocol which at
> least has defined methods for device discovery.
> >>
>
>I believe that there is an education problem here, not a lack of "defined
>methods for discovery" in SBP-2.
>
>The method is simple: the initiator examines configuration ROM for a unit
>directory with a Unit_Spec_ID of 0x00609e and a Unit_SW_Version of 0x010483.
>At this point the initiator knows it has discovered an SBP-2 device. What
>kind of device is it looking for? A printer? A disk that uses the SCSI
>command set? A still image camera? An Internet capable node? At this point,
>in the same unit directory, it takes a look at Command_Set_Spec_ID and
>Command_Set to find the desired match.
>
>To make this example a little more concrete, if the PWG invented a new
>command set that is unlike things that have existed in the past, the PWG (or
>whatever standards body becomes responsible for the care and feeding and
>future extensions to your standard) would acquire a 24-bit "company" ID from
>the IEEE and then pick a number to mean "PWG printer command set." These
>numbers would be Command_Set_Spec_ID and Command_Set.
>
>FCP operates along fundamentally similar lines: the searcher (initiator)
>examines configuration ROM looking for a unit directory that declares itself
>to be FCP.
>
>FCP also has a broadcast "Is anyone there?" feature. I think I can safely
>speak for quite a few in the 1394 community who believe that broadcast is not
>as attractive as it might appear---particularly if the volume becomes higher.
>Among broadcast's problems are a) required fixed address offsets to receive
>the broadcast, b) FIFO overflow problems in devices that have to receive the
>broadcast to determine that they're not interested, c) probable poor use of
>"global" broadcast in a bridged environment and d) lack of confirmation (did
>you fail to get an answer to your "Are you there query?" because no one was
>there or because the broadcast was discarded by a target whose FIFO was
>full?).
>
>Please feel free to recirculate this with the PWG.
>
>Regards,
>
>Peter Johansson
>
>Congruent Software, Inc.
>3998 Whittle Avenue
>Oakland, CA 94602
>
>(510) 531-5472
>(510) 531-2942 FAX
>
>pjohansson@aol.com
>
>
>
Regards, Danny Mitchell ( Dallas, Tx )
BuS Solutions SW Manager ( 1394, USB )
Ph: 972-480-3411 www.ti.com/sc/USB
Fx: 972-480-3160 www.ti.com/sc/1394
Texas Instruments, 8505 Forest Lane, MS-8710, Dallas, TX 75243