All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>, Ming Lei <ming.lei@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org
Subject: Re: [PATCH 3/3] block: Specify the operation type when calling blk_mq_map_queue()
Date: Mon, 20 Jun 2022 09:29:10 +0200	[thread overview]
Message-ID: <20220620072910.GA11786@lst.de> (raw)
In-Reply-To: <d510cb62-4b19-9ae0-cad4-1ca6756cc3fd@acm.org>

On Fri, Jun 17, 2022 at 11:25:41AM -0700, Bart Van Assche wrote:
> I looked into adding a __bitwise annotation for request flags by 
> introducing a new type that is called blk_mq_opf_t. Introducing such a type 
> without modifying a lot of code seems difficult to me. This is what I ran 
> into:
> * If the type of the operation type constants (REQ_OP_READ etc.) is 
> modified into blk_mq_opf_t then their type changes from 'enum req_opf' into 
> type blk_mq_opf_t and sparse complains when passing e.g. REQ_OP_READ to a 
> function that accepts an argument with type enum req_opf.
> * If the type of the operation type constants is not modified then sparse 
> complains about bitwise or-ing the operation type and a request flag, e.g. 
> REQ_OP_WRITE | REQ_FUA.
>
> I'm not sure how to solve this other than by modifying the functions that 
> accept an 'opf' argument into accepting an additional argument (enum 
> req_opf op + blk_mq_opf_t op_flags).

I actually always though of one type for the operation plus flags
as we basically always use the together.  That might still run into
a lot of problems, but is definitively way simpler and matches how
all the argument passing actually works.

      reply	other threads:[~2022-06-20  7:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14 17:57 [PATCH 0/3] Three small block layer patches Bart Van Assche
2022-06-14 17:57 ` [PATCH 1/3] blk-iocost: Simplify ioc_rqos_done() Bart Van Assche
2022-06-14 18:26   ` Tejun Heo
2022-06-15  5:58   ` Christoph Hellwig
2022-06-14 17:57 ` [PATCH 2/3] block: Rename a blk_mq_map_queue() argument Bart Van Assche
2022-06-15  5:58   ` Christoph Hellwig
2022-06-14 17:57 ` [PATCH 3/3] block: Specify the operation type when calling blk_mq_map_queue() Bart Van Assche
2022-06-14 19:31   ` Jens Axboe
2022-06-15  0:31   ` Ming Lei
2022-06-15  6:08     ` Christoph Hellwig
2022-06-15  6:24       ` Ming Lei
2022-06-17 18:25       ` Bart Van Assche
2022-06-20  7:29         ` Christoph Hellwig [this message]

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=20220620072910.GA11786@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.