On Wed, May 25 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Tue, May 24 2005, Jeff Garzik wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>I agree, it's a cleaner approach, with the rq being a container for
> >>>generel messages as well not just SCSI commands. The one missing piece
> >>>for that was the rq->end_io() callback so everything doesn't have to go
> >>>down sync, but that is in now as well.
> >>>
> >>>I'll try and cook something up.
> >>
> >>Very cool ;)
> >
> >
> >This is the base for it. It splits request->flags into two variables:
> >
> >- cmd_type. this is not a bitmask, but a value indicating what type of
> > request this is.
> >
> >- cmd_flags. various command modified flags.
> >
> >The idea is to add a REQ_TYPE_LINUX_BLOCK request type, where we define
> >a set of command opcodes that signify an upper level defined function
> >(such as flush) that is implemented differently at the hardware/driver
> >level. Basically a way to pass down messages or commands generically.
> >
> >I like this better than using scsi opcodes always, it's a cleaner
> >abstraction. For sending generic commands to a device, we could add a
> >function ala:
>
> cmd_type just adds a needless layer of switch{} statements in block
> drivers, and its information that can be trivially derived from the
> command opcode itself.
>
> cmd_type = cmd_types[opcode];
>
> HOWEVER, don't fall in love with SCSI opcodes.
Eh, I don't follow. The opcode is only valid for cmd_type
REQ_TYPE_LINUX_MSG, not for anything else. Or for REQ_TYPE_BLOCK_PC of
course, like it is right now as well.
> We want _Linux_ commands, not SCSI commands. Just think of a
> request_queue as having its own command protocol, one that you can
> _change at will_.
>
> Yes, often request_queue commands may map seamlessly to SCSI (or ATA or
> I2O) commands. And that's good. But don't let yourself be locked into
> SCSI. SCSI is not generic enough, nor mutable enough for all our needs.
>
> Just the other day I was thinking about the simpler approach, like the
> attached :) It
> * adds RQ_ to avoid namespace conflicts
> * adds RQ_FLUSH, RQ_PM_EVENT
>
> So, overall, I would say "think Linux opcodes" as the preferred direction.
And that's exactly what I proposed, the REQ_LB_OP_xxx are the linux
specific opcodes that can be defined at will. I'm not locking myself
into SCSI at all, I'm just putting ->cmd[] to use for a new command
type.
Don't confuse/mixup fs.h and the block layer, I don't see your proposal
adding anything of use. The fs.h READ/WRITE/etc were divorced from the
block layer in 2.5.
--
Jens Axboe
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
