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@sdd.hp.com]
Sent: Tuesday, May 26, 1998 10:11 AM
To: atsnaka@bsd.canon.co.jp
Cc: p1394@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@sdd.hp.com
----------------------------------------------------------------