Okay. I understand your comments.
In terms of change / addition to structure - the issues are key
definitions in 1212r and a registry for the function class values.
Cheers,
Greg
-----Original Message-----
From: Turner, Randy [SMTP:rturner at sharplabs.com]
Sent: Wednesday, May 27, 1998 5:21 PM
To: p1394 at pwg.org
Subject: RE: P1394> 1212 Issues - was May 1394 PWG Definitions
See my comments below...
Randy
-----Original Message-----
From: Greg LeClair [SMTP:gleclair at agentz.com]
Sent: Wednesday, May 27, 1998 4:34 PM
To: p1394 at pwg.org
Subject: P1394> 1212 Issues - was May 1394 PWG
Definitions
Others that have been involved in revisions work please
comment.....
My understanding is that current 1212 definitions are an issue.
See if the following applies:
Changes to Config ROM may be limited to new keys and or
structures.
Is this what you meant by "revise how config ROM is structured"?
Yes. But limiting changes to "structures" is not very limiting.
Our original proposal including the addition of a "function" directory
is just such a structure addition.
And yes, there is legacy within 1212. The existing spec, it's
inclusion as
a reference in other specs and bus standards......
I was referring to "legacy" in the case of "legacy" SBP-2
implementations in shipping devices that would be used as "targets".
I think 1212R is just extending 1212 to cover other requirements that
have come up since original publication. Whatever "R" does should be
backwards compatible with the original 1212. Of course, I may be wrong
about this.
The compliance terminology on new items is an issue.
Regards,
Greg
-----Original Message-----
From: Jeff Schnitzer [SMTP:jds at underscore.com]
Sent: Wednesday, May 27, 1998 6:34 AM
To: p1394 at pwg.org
Subject: RE: P1394> May 1394 PWG Definitions
From: "Turner, Randy" <rturner at sharplabs.com>
To: "'p1394 at pwg.org'" <p1394 at pwg.org>
Subject: RE: P1394> May 1394 PWG Definitions
Date: Tue, 26 May 1998 10:29:44 -0700
I was assuming that "current 1212 definitions" would not be an
issue,
and that p1212r would take our requirements into account and
revise how
config ROM is structured? With the almost non-existent 1394
product
base, I'm also assuming there are no legacy 1212 issues do deal
with.
Randy
-----Original Message-----
From: Greg Shue [SMTP:gregs at sdd.hp.com]
Sent: Tuesday, May 26, 1998 10:11 AM
To: atsnaka at bsd.canon.co.jp
Cc: p1394 at pwg.org
Subject: Re: P1394> May 1394 PWG Definitions
Ats wrote:
> I do not intend to take this up as a problem, but I
feel 1394 protocols
> (current actual usage) do not equate units with
functions, but as
> protocols. (ex. AV/C unit, SBP-2 unit, etc.)
> Under this circumstances and understanding, equating
units to drivers seemed
> to fit.
The big struggle I have with current 1212 definitions is
that
they do equate *_SW_VERSION with a monolithic driver
(where *
could be either Module, Node, or Unit), and they don't
provide a
way of encoding arbitrary number of layers of drivers
into the
Config ROM. Under this idea, all other layers would
have to
be queried using the identified driver. And this makes
sense
when we remember that 1212 is a Control and Status
REGISTER
Architecture. Now we're trying to encode things well
beyond
the register layer. :-)
> Greg said :
> >I think we need to expand the idea of function : unit
on a 1:1 ratio
>
> True. Another point is
> 1) function : unit on a 1:n ratio......1 function
using/supported by one or more protocols
> (unit dir level)
> 2) function : unit on a n:1 ratio......one or more
functions supported by 1 protocol.
> (unit dir level)
>
> Though the PWG profile may allow only 1), both have
to be allowed
> looking from the point of 1212 (and any protocols).
We may also need to look at the problem of how to encode
multiple
layers of protocols needed to access a function.
--
Greg Shue
Hewlett-Packard Company
Office Products Division
gregs at sdd.hp.com
----------------------------------------------------------------