P1394 Mail Archive: P1394> connection for Function or Service

P1394> connection for Function or Service

Nagasaka Fumio (Nagasaka.Fumio@exc.epson.co.jp)
Fri, 16 Oct 1998 20:57:16 +0900

In Savannah meeting, Brain opened SPI discussion, and it was really
productive. I would like to confirm some open issue. Actually I
would like to start e-mail discussion thread. Because as Brian
pointed in this reflector, meeting schedule is too short (only one day),
thus I felt e-mail discussion would be helpful to clear what is
required for current profile Rev.0.52.

An UnitDir is assumed as the entity of a function, a function (ex.
a printer, or a scanner, ) may have several services, for example
job control, printing, status monitoring and finisher control.
A "Function" is an abstracted software entity of a real device.
A "Service" is an abstracted software model of an executable
instance.

[Services]
UnitDir == Function (printer) -----|
|-----Job Control
|-----Status Monitoring
|-----Printing
|-----Finisher
|

We've discussed three ideas listed below;
(1) an initiator logins to the function.
(2) an initiator logins to each service.
(3) hybrid solution of (1) and (2).

If we choose (2), naturally each service shall be associated
with a LUN and the initiator shall specify the selected LUN in
parameter of "login".

If we choose (1), a function shall be assumed as one LUN.
The initiator shall specify this LUN at login, and this LUN
shall provide multiplexing to support several services.

I have no urge to describe (3). This idea seems to be too
complicated for me.

Second idea is neat. And current profile (0.52) is applicable
for this model. However I am not sure whether existing PC OS
is supporting PnP of this architecture.

UnitDir ---|-- LUN
|-- LUN
|-- LUN
|-- ...

Also I don't think current PC OS is supporting dynamic adding
of LUNs. Thus it is difficult to add service entity on demand.

The first idea is not neat, but may be supported even under
existing PC OS.

UnitDir ----- LUN
UnitDir ----- LUN
...

However, each service requires a multiplexed connection and
each connection requires flow control and send/receive queues.

My proposal suggested in the last meeting was describing
multiplexing, but it does not have description for flow control
of each logical channels. So my question is, shall we choose
second idea? or does anyone have better idea for (3) option?
Or is there new idea??
Thank you,

---
--------------------------------------------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111,  Fax +81 268 25 4627
E-mail to  <mailto:nagasaka.fumio@exc.epson.co.jp> nagasaka.fumio@exc.epson.
co.jp