Alan, Randy I was sorry may be you are confused as I
did not separate these two thread.
1. Timer issue
Greg explained the 1394 PWG transport is predictable
as same as CBT (Credit Based Transport). Thus I understood
a timer to detect a hanging read ORB is not required.
However the T to I transaction will easily be stalled
when the initiator does not provide any input ORBs.
Greg Shue:
> As far as "stalling" goes, the I2T direction and T2I direction
> could be stalled simply by the initiator not providing ORBs.
> What is prevented is that the data flow will not be blocked by
> _other_ communication.
Thus we at 1394 PWG shall describe a method to force an
initiator to provides ORBs without utilizing unsolicited
status from the target. Because some operating system does
not support this functionality.
2. Transport requirements
Greg Shue:
> I suggested that he create a written alternate proposal for the
> next PWG meeting, so that his concerns get raised.
Yes, I will.
Greg Shue and Fumio Nagasaka:
fn> gs>
fn> gs> Defined SBP-2 No | Yes
fn> gs> command set
fn>
fn> This is one benefit of 1284.4. IEEE P1284.4 is pure transport.
fn> I mean 1284.4 is abstracted from any data link layer and it
fn> does not have any dependency for data link design. If you
fn> want to say your commands have some dependency for SBP-2
fn> in words "defined SBP-2 command set", I feel it is better
fn> to develop command set which does not have any dependency on
fn> data link layer. We are defining transport layer.
gs>
gs> Nope, we are defining a complete stack up through the transport
gs> layer. This means we must also define the "data link" layer and
gs> how to glue them together. Without an SBP-2 command set, there
gs> is no SBP-2 based solution.
When we are defining a data link layer which is applicable
for other transport protocol, then may be open/close/move
data I2T or move data T 2I/ are enough functions in this
layer. However if you say we are defining "a complete stack
up through the transport layer", then we shall provide
services to ease a session layer to find or to use facilities
provided in the 1394 PWG peripherals. So we shall provide
some higher service capability and functions abstracted
from SBP-2 transaction.
To give a simple example, "Universal Serial Bus (USB) Device
Class Definition for Printing Device" is defining two
interesting "Class Specific Requests" GET_DEVICE_ID and
GET_PORT_STATUS. The first request makes it easy for the
session layer to get 1284 PnP ID from a printer. The later
request fakes the session layer as if the transport is
providing a conventional 8 bit printer port. Actually
these requests are really usable for a PortMonitor developer
who is working for some existing PC OS(s).
A SBP-2/1394 PWG supportive printer provides 1284 PnP ID in a
configuration ROM. So a higher level protocol driver
may read textual descriptor from the configuration ROM.
But this method has a strong dependency for 1394 bus
system. If the transport layer protocol driver has a
function which reports 1284 PnP ID to higher level
protocol driver, the higher level protocol driver would
be abstracted from 1394 Bus system. And the printer
driver developer will be able to write a common session
layer program which covers both USB and SBP-2.
Still 40% of my mind is wondering these description
shown above seems to be inconsistent. Because still
I am not sure what Greg is saying as "a complete stack
up through the transport layer". It seems to be very
big scope. We shall just design a transport layer.
Greg Shue:
>
>> I agree. I'm lost too. I thought my previous email got lost....
>>
>> Randy
>
>Welcome to topic drift ...
>
>The topic was timeouts. No one has come up with any other ones
>than those listed by Alan, so no additional action items exist
>for the draft.
>
>In the course of discussion, Fumio expressed his concern that
>the current proposal is no better (or possibly even worse)
>than a 1284.4-based solution. He also thought that we were
>defining a transport layer, rather than a transport stack.
>
>I suggested that he create a written alternate proposal for the
>next PWG meeting, so that his concerns get raised.
>
>
>--
>Greg Shue
>Hewlett-Packard Company
>All-in-One Division gregs@sdd.hp.com
>----------------------------------------------------------------
>
--- Fumio Nagasaka EPSON Software Deveopment Lab., Inc. voice: +81 268 25-4111