patacongo commented on pull request #1271: URL: https://github.com/apache/incubator-nuttx/pull/1271#issuecomment-647005523
> 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: It would be as good if as much is common as possible. But the hardware solution has severe performance constaints (as the embedded solution may have severe memory constraints). > 1.The start/stop trace control There is no target user interface. The host interface is unidirectional. > 2.The runtime filter functionality Probably... but this depends on data rates. > 3.Format to ftrace for graphic tool No, this would not be done in the target in the hardware solution. This would be done on the host. But I will not be using ftrace. I will be using a Windows application. I don't do Linux develop; this will be a Windows only solution initially. The "transport" is a binary byte stream. It has no particular application format. The receiving application can use the data in any way this it chooses. This is a different project with different end-user objectives. > 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. Currently, sched_note only buffers data to RAM. But the binary encoding logic should be sharable. ---------------------------------------------------------------- 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]
