[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C3227CA.8000600@garzik.org>
Date: Mon, 05 Jul 2010 14:43:22 -0400
From: Jeff Garzik <jeff@...zik.org>
To: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
CC: axboe@...nel.dk, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: remove unused REQ_TYPE_LINUX_BLOCK
On 07/05/2010 05:11 AM, FUJITA Tomonori wrote:
> You prefer to keep this for future possible users?
>
> This can be applied to block's for-2.6.36.
>
> =
> From: FUJITA Tomonori<fujita.tomonori@....ntt.co.jp>
> Subject: [PATCH] block: remove unused REQ_TYPE_LINUX_BLOCK
>
> Nobody uses REQ_TYPE_LINUX_BLOCK (and its REQ_LB_OP_*).
>
> Signed-off-by: FUJITA Tomonori<fujita.tomonori@....ntt.co.jp>
> ---
> include/linux/blkdev.h | 15 ---------------
> 1 files changed, 0 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 3a2c5d9..baf5258 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -60,7 +60,6 @@ enum rq_cmd_type_bits {
> REQ_TYPE_PM_RESUME, /* resume request */
> REQ_TYPE_PM_SHUTDOWN, /* shutdown request */
> REQ_TYPE_SPECIAL, /* driver defined type */
> - REQ_TYPE_LINUX_BLOCK, /* generic block layer message */
> /*
> * for ATA/ATAPI devices. this really doesn't belong here, ide should
> * use REQ_TYPE_SPECIAL and use rq->cmd[0] with the range of driver
> @@ -70,20 +69,6 @@ enum rq_cmd_type_bits {
> REQ_TYPE_ATA_PC,
> };
>
> -/*
> - * For request of type REQ_TYPE_LINUX_BLOCK, rq->cmd[0] is the opcode being
> - * sent down (similar to how REQ_TYPE_BLOCK_PC means that ->cmd[] holds a
> - * SCSI cdb.
> - *
> - * 0x00 -> 0x3f are driver private, to be used for whatever purpose they need,
> - * typically to differentiate REQ_TYPE_SPECIAL requests.
> - *
> - */
> -enum {
> - REQ_LB_OP_EJECT = 0x40, /* eject request */
> - REQ_LB_OP_FLUSH = 0x41, /* flush request */
> -};
Acked-by: Jeff Garzik <jgarzik@...hat.com>
Having a second level of opcodes, under REQ_TYPE_LINUX_BLOCK, always
seems less desirable than the current course of action you are now
pursuing (REQ_FLUSH, etc.)... nice cleanup.
Jeff
--
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/
Powered by blists - more mailing lists