xiaoxiang781216 commented on pull request #1271: URL: https://github.com/apache/incubator-nuttx/pull/1271#issuecomment-647003582
> > > > With the hardware solution, the instrumentation data will be encoded and sent out via a parallel port immediately when the call-out occurs. There will be no buffering in RAM; there will be not application driver. Those will all be disabled. The USB parallel solution will be direct instrumentation to hardware. > > > > To make that job simpler and fully compatible with the effort you are doing, perhaps we need to have standalone logic to encode instrumentation data to a stream. Perhaps using struct lib_outstream_s as defined in include/nuttx/stream.h. That way, the encoded data can go to either a memory stream or to the hardware parallel interface. > > > > Similar rate/content controls will be needed. > > > > > > Yes, we can extend sched_note.c driver to support the different transport just like syslog(ramlog, itm, serial, file...). > > No, you do not understand. With the hardware solution there is nothing buffered in ram, there is no driver, and sched_note.c is not built. sched_note.c is ONLY built if data will will buffered in RAM. None of that logic applies in the hardware solution. Nothing will be buffered in RAM. > > You don't understand the architecture. > > The path is direct from the instrumentation call-out functions in the OS to a new driver that immediately sends the date to the host via a parallel-to-USB device. CONFIG_SCHED_INSTRUMENTATION_BUFFER will not be enabled. A block diagram would be very space: > > CORE OS ->Parallel port driver / USB ->Host driver -> Host Application > > When CONFIG_SCHED_INSTRUMENTATION_BUFFER is enabled the path is like: > > CORE OS -> RAM -> driver -> embedded application > > What you envision is incorrect. I understand your requirement, but we still need a layer between the sched_* callback and the real transport(either USB or ram), because we don't want duplicate these for each transport: 1.The start/stop trace control 2.The runtime filter functionality 3.Format to ftrace for graphic tool The better path is: Core OS->sched_note->transport(RAM or USB) Sorry, I reuse sched_note terminoloy, the old sched_note should become a transport. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
