Re: [PATCH] libata: device suspend/resume

[Jens Axboe <axboe@suse.de>]

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