Re: transport_dbg and TLM_IGNORE_COMMAND

Sounds good to me.

Perhaps it would be useful to remind the reader:

Targets implementing the TLM_IGNORE_COMMAND have the onus to document
behavior with respect to the payload fields. Implementors of initiators
using the TLM_IGNORE_COMMAND had better read each TLM target's respective
documentation carefully. Clearly, TLM_IGNORE_COMMAND may not modify anything
that might mess-up interconnect behavior in this regard.

This would be something more like a foot note.

On Wed, Dec 1, 2010 at 8:54 PM, <john.aynsley@doulos.com> wrote:

> Jerome, All,
>
> Let's see if we can deal with the easier issues.
>
> Your original 4th point was about the value returned from transport_dbg for
> TLM_IGNORE_COMMAND. My answer was that an application is already free to
> return whatever value it likes without breaking the base protocol, although
> I would agree that is a matter of interpretation, and the LRM wording could
> be made more explicit.
>
> In other words, TLM_IGNORE_COMMAND says that the target does not perform a
> BP read or write, but is free to do something else. The value returned from
> transport_dbg is tightly defined for read or write, but if the application
> is executing an extended command, the target is free to choose the return
> value.
>
> Does that meet your requirement? Is everyone else okay with that?
>
> Thanks,
>
> John A
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.