Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <7e3d534a42bf119c92d9e81145940fb02dbc676e.camel@sipsolutions.net>
Subject: Re: [PATCH] nl80211: fix tx_control_port trace point
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Markus Theil <markus.theil@tu-ilmenau.de>
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 04 Mar 2020 13:36:23 +0100
In-Reply-To: <1073945b-ec01-7303-0bfb-92456e1ca7a5@tu-ilmenau.de>
References: <20200304114952.1827-1-markus.theil@tu-ilmenau.de>
         <5c542c4ce1b5373e8fe280913b74926f4d36e2d1.camel@sipsolutions.net>
         <1073945b-ec01-7303-0bfb-92456e1ca7a5@tu-ilmenau.de>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Wed, 2020-03-04 at 13:32 +0100, Markus Theil wrote:
> 
> 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:

Sure.

But trace-cmd has infrastructure to handle such "function calls" in the
output format, so it should be able to handle this pretty easily.

So really it's mostly a presentation issue, and having the data in big
endian when it's that way over the air etc. IMHO does make sense.

johannes