[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100706113954L.fujita.tomonori@lab.ntt.co.jp>
Date: Tue, 6 Jul 2010 11:40:41 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: jeff@...zik.org
Cc: fujita.tomonori@....ntt.co.jp, axboe@...nel.dk,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: remove unused REQ_TYPE_LINUX_BLOCK
On Mon, 05 Jul 2010 14:43:22 -0400
Jeff Garzik <jeff@...zik.org> wrote:
> > -/*
> > - * 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.
Agreed. We are running out of rq_flag_bits though. We can rethink when
we actually run out of it.
--
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