linux-kernel - Re: [PATCH 1/4] block: blk-mq: support draining mq queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20131226105316.GA16268@infradead.org>
Date:	Thu, 26 Dec 2013 02:53:16 -0800
From:	Christoph Hellwig <hch@...radead.org>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Jens Axboe <axboe@...nel.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] block: blk-mq: support draining mq queue

On Thu, Dec 26, 2013 at 06:12:30PM +0800, Ming Lei wrote:
> IMO, if one block API can serve for both non-MQ and MQ cases, why do
> we have to split it into blk_foo() and blk_mq_foo()?

To make the usage obvious and to allow killing the old code more
easily.  Looking back I have to see I'd actually prefer it the MQ
code simply used different data structures.

> 
> IMO it is very possible that parallel path might keep for a while, and at least
> the current scsi-mq patches do so.

That might be okay for the current prototype, but there's not point in
merging it if it can't replace the old legacy request code.  And yes,
this will require a lot more work.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/