From: Al Viro <viro@zeniv.linux.org.uk>
To: David Howells <dhowells@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
Jens Axboe <axboe@kernel.dk>, Jan Kara <jack@suse.cz>,
Jeff Layton <jlayton@kernel.org>,
Jason Gunthorpe <jgg@nvidia.com>,
Logan Gunthorpe <logang@deltatee.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Hellwig <hch@lst.de>,
John Hubbard <jhubbard@nvidia.com>
Subject: Re: [PATCH] iov_iter: Use __bitwise with the extraction_flags
Date: Thu, 26 Jan 2023 22:27:07 +0000 [thread overview]
Message-ID: <Y9L+O4V5uJIWFnmI@ZenIV> (raw)
In-Reply-To: <2638928.1674729230@warthog.procyon.org.uk>
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 <david@redhat.com> 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.
next prev parent reply other threads:[~2023-01-26 22:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 21:06 [PATCH v10 0/8] iov_iter: Improve page extraction (pin or just list) David Howells
2023-01-25 21:06 ` [PATCH v10 1/8] iov_iter: Define flags to qualify page extraction David Howells
2023-01-26 9:25 ` David Hildenbrand
2023-01-26 9:49 ` David Howells
2023-01-26 9:52 ` David Hildenbrand
2023-01-26 10:33 ` [PATCH] iov_iter: Use __bitwise with the extraction_flags David Howells
2023-01-26 10:41 ` David Hildenbrand
2023-01-26 22:27 ` Al Viro [this message]
2023-01-25 21:06 ` [PATCH v10 2/8] iov_iter: Add a function to extract a page list from an iterator David Howells
2023-01-25 21:06 ` [PATCH v10 3/8] iomap: Don't get an reference on ZERO_PAGE for direct I/O block zeroing David Howells
2023-01-25 21:06 ` [PATCH v10 4/8] block: Fix bio_flagged() so that gcc can better optimise it David Howells
2023-01-25 21:06 ` [PATCH v10 5/8] block: Replace BIO_NO_PAGE_REF with BIO_PAGE_REFFED with inverted logic David Howells
2023-01-26 9:28 ` David Hildenbrand
2023-01-26 9:32 ` David Hildenbrand
2023-01-26 11:34 ` David Howells
2023-01-26 15:14 ` Christoph Hellwig
2023-01-25 21:06 ` [PATCH v10 6/8] block: Add BIO_PAGE_PINNED and associated infrastructure David Howells
2023-01-26 9:29 ` David Hildenbrand
2023-01-25 21:06 ` [PATCH v10 7/8] block: Convert bio_iov_iter_get_pages to use iov_iter_extract_pages David Howells
2023-01-25 21:06 ` [PATCH v10 8/8] block: convert bio_map_user_iov " David Howells
2023-01-26 11:36 ` [PATCH v10 2/8] iov_iter: Add a function to extract a page list from an iterator David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9L+O4V5uJIWFnmI@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=david@redhat.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=logang@deltatee.com \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox