From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58C83C61DA7 for ; Thu, 26 Jan 2023 22:27:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232946AbjAZW1W (ORCPT ); Thu, 26 Jan 2023 17:27:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55710 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232921AbjAZW1T (ORCPT ); Thu, 26 Jan 2023 17:27:19 -0500 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 10A6C5894E; Thu, 26 Jan 2023 14:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=STYji93U3ACAaGQFYmzFPWVQjHiGVhb+LyWgK4H0YqE=; b=doVxp+d4MftLA/hoq1I/XVGa9k vznOjMNWPk/5xKmfT78tFmvPfpqLZm55p/BDZLhARkzVgjqati18BiuamgW2J9J6i0PASTm2t02i3 oFGu+A9yxtL51prBiRJeJm2dCcuwWHZjRBVpcV/H3S2KIlfAyqdRHzMmMHgUT37wIOcxlDx1lNmOe qwfJIAo4C+28FNp8DW9IzxLr7Jr+gwoEc94wC3jhLe+TqcMotyHGewLoBdYFsZR/pitGWlOszRXz9 aQTHvlVi/DQcE3vQomIDalXhSF1aR+wAWQ7senFmGvOHTCPVadBxfAW7XCTQX2Pc5R3D+JevZqXFb 8vBPfsGA==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1pLAi3-004KMs-11; Thu, 26 Jan 2023 22:27:07 +0000 Date: Thu, 26 Jan 2023 22:27:07 +0000 From: Al Viro To: David Howells Cc: David Hildenbrand , Christoph Hellwig , Matthew Wilcox , Jens Axboe , Jan Kara , Jeff Layton , Jason Gunthorpe , Logan Gunthorpe , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig , John Hubbard Subject: Re: [PATCH] iov_iter: Use __bitwise with the extraction_flags Message-ID: References: <20230125210657.2335748-1-dhowells@redhat.com> <20230125210657.2335748-2-dhowells@redhat.com> <2613249.1674726566@warthog.procyon.org.uk> <2638928.1674729230@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2638928.1674729230@warthog.procyon.org.uk> Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 26, 2023 at 10:33:50AM +0000, David Howells wrote: > X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.2 > -------- > David Hildenbrand wrote: > > > >> Just a note that the usage of new __bitwise types instead of "unsigned" is > > >> encouraged for flags. > > Something like the attached? > > > $ git grep "typedef int" | grep __bitwise | wc -l > > 27 > > $ git grep "typedef unsigned" | grep __bitwise | wc -l > > 23 > > git grep __bitwise | grep typedef | grep __u | wc -l > 62 > > *shrug* > > Interestingly, things like __be32 are __bitwise. I wonder if that actually > makes sense or if it was just convenient so stop people doing arithmetic on > them. I guess doing AND/OR/XOR on them isn't a problem provided both > arguments are appropriately byte-swapped. Forget the words "byte-swapped". There are several data types. With different memory representations. Bitwise operations are valid between the values of the same type and yield the result of that same type. The fact that mapping between those representations happens to be an involution is an accident; keeping track of the number of times you've done a byteswap to the value currently in this variable is asking for trouble. It's really easy to fuck up. "Am I trying to store the value of type X in variable of type Y (presumably having forgotten that I need to use X_to_Y(...) to convert)" is much easier to keep track of.