On Fri, Jan 19, 2018 at 10:37:22AM -0300, Philippe Mathieu-Daudé wrote: > On 01/19/2018 05:51 AM, Pavel Pisa wrote: > > On Tuesday 16 of January 2018 01:12:09 Philippe Mathieu-Daudé wrote: > >> On 01/15/2018 06:29 PM, Pavel Pisa wrote: > > But if the second format is preferred then I update the patch. > > > >>> Trace events seems as nice feature. But simple text printf > >>> like output has been enough till now for CAN testing. > >>> There is no debugging output in production build. > >>> So I would add tracing infrastructure later if needed. > >> > >> They are as useful as console printf, but less invasive and more > >> powerful: you can use a much precise timing, select which set of events > >> to display without having to recompile. > >> The default backend behaves as console printf. > >> > >> You should try them :) > > > > I have tried them on > > > > pci_update_mappings_del > > pci_update_mappings_add > > pci_cfg_write > > > > and they work great. They would be nice for SJA1000 > > register accesses, PCI boards configuration etc. > > I am not sure how to use them for CAN messages > > which has a variable length data field. > > Yes, I hit this problem with variable length data in the SD Bus. > > Let's ask Stefan what is the best approach (he said "Tracing is not > great for dumping large amounts of data")
Yes, tracing isn't pcap. It's not designed for dumping payloads - especially when the length is more than 64 bytes or so. I suggest writing out a pcap file so wireshark or tcpdump can be used to analyze it. The code is pretty simple, see net/dump.c. Stefan
signature.asc
Description: PGP signature
