> >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.
> >FCP operates along fundamentally similar lines: the searcher (initiator)
> >examines configuration ROM looking for a unit directory that declares
itself
> >to be FCP.
This is exactly the issue we want to solve;
Currently in the above example, there is no way to tell that a
SCSI/SBP-2 device is not a disk, but maybe a printer.
There may also be an internet capable digital camera,video
camcorder,scanner......which one will it be?
As for the FCP example, the initiator will find a FCP device,
and furthur know that it supports the AV/C command set(for example),
but it will not discover it's actual function(printer,camera,stereo...)
unless the initiator supports that protocol and initiates communication
in AV/C over FCP, then inquiring.
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.
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.
> 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.
I agree with Danny's opinion.
Regards,
Atsushi Nakamura
BJ Printing Technology Development 22
Canon Inc.
+81-3-5482-8396 (tel)
+81-3-3756-6052 (fax)
Atsushi_Nakamura@cbj.canon.co.jp
----------
> 差出人 : Danny Mitchell <DMitchell@ti.com>
> 宛先 : pjohansson@aol.com
> CC : Pwg1394@cbs.canon.co.jp; p1394@pwg.org
> 件名 : P1394> Re: Device discovery on 1394
> 送信日時 : 1997年6月17日 18:10
>
> Peter,
>
> 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