On 3/4/20 1:16 PM, Johannes Berg wrote: > On Wed, 2020-03-04 at 12:49 +0100, Markus Theil wrote: >> Endianess conversion should not happen when writing out the string, >> instead convert proto endiannes when creating the trace point data, >> like its already done for control port rx. >> >> Without this patch, trace looks like: >> <...>-53819 [000] 12957.654875: rdev_tx_control_port: [FAILED TO PARSE] >> wiphy_name=phy0 name=wlan0 ifindex=3 dest=ARRAY[dc, 7b, 94, a5, bb, 3e] >> proto=36488 unencrypted=1 >> >> After applying this patch: >> wpa_supplicant-553 [001] 121.211264: rdev_tx_control_port: phy0, >> netdev:wlan0(3), dc:7b:94:a5:bb:3e, proto: 0x888e, unencrypted: true > This is from trace-cmd? That just means it doesn't know about the endian > conversion, but I don't really see any reason to change this - big > endian is a perfectly valid format for trace points? Yes, its trace-cmd output. Without this patch, the print fmt in the trace data file looks like this: print fmt: "%s, netdev:%s(%d), %pM, proto: 0x%x, unencrypted: %s", REC->wiphy_name, REC->name, REC->ifindex, (REC->dest), (__u16)__builtin_bswap16((__u16)(( __u16)(__be16)(REC->proto))), (REC->unencrypted) ? "true" : "false" With the patch, the builtin_bswap16 does not get placed there: print fmt: "%s, netdev:%s(%d), %pM, proto: 0x%x, unencrypted: %s", REC->wiphy_name, REC->name, REC->ifindex, (REC->dest), REC->proto, (REC->unencrypted) ? "true" : "false" Markus > Maybe teach trace-cmd to understand it? We already did that for > __le16_to_cpu(). > > johannes >
