On 22 Jun 2015 5:54 pm, "Mike Leach" <Mike.Leach@arm.com> wrote:
>
> Hi Mathieu,
>
> Thanks for the feedback. I'll not comment individually on each section other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
>
> There will be a new version of the document published shortly which will include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
>
> To the C++ question - the answer is yes. The work we are currently undertaking on the infrastructure and packet decoders is implemented in C++.
Is your current intention to change to C in the future? The discussion in the meetings had been that the library would be C based to maximise deployability. If the external interfaces of the library are C++ based that seems like it might cause problems binding to other languages.
>
> Regards
>
> Mike
>
> ----------------------------------------------------------------
> Mike Leach +44 (0)1254 893911 (Direct)
> Principal Engineer +44 (0)1254 893900 (Main)
> Arm Blackburn Design Centre +44 (0)1254 893901 (Fax)
> Belthorn House
> Walker Rd mailto:mike.leach@arm.com
> Guide
> Blackburn
> BB1 2QE
> ----------------------------------------------------------------
>
> > -----Original Message-----
> > From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org]
> > Sent: 16 June 2015 17:52
> > To: Mike Leach
> > Cc: coresight@lists.linaro.org
> > Subject: Re: API Document
> >
> > Good day Mike,
> >
> > I reviewed the document that was submitted and have the following
> > comments - at this time most of them surround the terminology that was
> > used. I may be a little slow to catch on but for someone not familiar
> > with trace decoding engines it is extremely difficult to wrap one's
> > head around new concepts when variations are used.
> >
> > I read the entire document twice but can't provide comments on section
> > 2.3 and beyond before the following points are clarified.
> >
> > Section 2.1.1:
> > 1. "Where the source is a core the decoder will be a PE decoder..." :
> > Are we still talking about the "packet trace decoder" or something
> > else?
> >
> > 2. "The protocol block will require..." : Are we talking about the
> > "Protocol decode block"?
> >
> > 3. The reader must assume the "generic trace primitives" are the same
> > as the "generic trace elements" introduced in chapter 2.1.5. If so
> > the latter should be used throughout the document.
> >
> > Section 2.1.2:
> > 1. "The trace formatted frame decoder is provided..." : Are we talking
> > about the "trace frame deformatter". Without using the same terms,
> > there is no way to tell.
> >
> > 2. "A decode block can be attached..." : What is a "decode block"? I
> > must assume we are referring to a "Protocol decode block".
> >
> > Section 2.1.4:
> > 1. "Packet processors and decoders can be...": Are we talking about
> > the packet processor and packet "trace decoder" presented in section
> > 2.1.1? If so "trace decoder" needs to be referenced explicitly.
> >
> > Figure 1:
> > 1. Is the "Trace Decode Block" the "Protocol decode block" presented
> > in section 2.1.1? If so section 2.1.1 needs to be modified to include
> > the "Trace Frame Deformatter". Following the figure I think the
> > latter should be presented first, followed by the "packet processor"
> > and "packet decoder" descriptions.
> >
> > One of the main provider of trace stream to the "Trace Decode Block"
> > will be the user space Perf tool. I am currently working on how the
> > gap between Perf and the Trace Decode Block will be bridged.
> >
> > Figure 2:
> > 1. One must assume the green box labelled "stream protocol decode
> > block" is the same as what was presented in Figure 1. If so the same
> > names need to be used in both figures.
> >
> > 2. I would add "Perf" in the "formatted trace source" box.
> >
> > 3. Should the "Trace Formatted Frame Decoder" be introduced somewhere
> > in the documentation? Or maybe it was under a different name?
> >
> > 4. "... is the Stream Protocol decode block as previously described".
> > I must assume this is the "Protocol Decode Block" introduced in
> > section 2.1.1. If so the same terminology has to be use throughout
> > the document.
> >
> > Section 3.1:
> >
> > I noticed that C++ syntax was used - is this strictly for
> > documentation purposes or should I deduce that ARM favours using C++
> > in the implementation?
> >
> > Best regards,
> > Mathieu
> >
> >
> > On 27 May 2015 at 10:29, Mike Leach <Mike.Leach@arm.com> wrote:
> > > Hi,
> > >
> > > As discussed I have attached the API document that describes the design
> > and current implementation of a CoreSight decoder library framework that
> > we have been working on within ARM.
> > >
> > > This is very much a work in progress (both the document and the API) - but
> > questions / comments etc. are always welcome.
> > >
> > > The document does have a distribution list on the front but it is not limited
> > by this so if I have missed anyone off I apologise.
> > >
> > > Regards
> > >
> > > Mike
> > >
> > > ----------------------------------------------------------------
> > > Mike Leach +44 (0)1254 893911 (Direct)
> > > Principal Engineer +44 (0)1254 893900 (Main)
> > > Arm Blackburn Design Centre +44 (0)1254 893901 (Fax)
> > > Belthorn House
> > > Walker Rd mailto:mike.leach@arm.com
> > > Guide
> > > Blackburn
> > > BB1 2QE
> > > ----------------------------------------------------------------
> > >
> > >
> > >
> > > -- IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended recipient,
> > please notify the sender immediately and do not disclose the contents to any
> > other person, use it for any purpose, or store or copy the information in any
> > medium. Thank you.
> > >
> > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> > Registered in England & Wales, Company No: 2557590
> > > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
> > 9NJ, Registered in England & Wales, Company No: 2548782
> > >
> > > _______________________________________________
> > > CoreSight mailing list
> > > CoreSight@lists.linaro.org
> > > https://lists.linaro.org/mailman/listinfo/coresight
> > >
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
> _______________________________________________
> CoreSight mailing list
> CoreSight@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/coresight