On Fri, Apr 25 2003, Alexander Atanasov wrote:
> Hello,
>
> Benjamin Herrenschmidt wrote:
>
>
> >The point is to pipe the power management requests through the request
> >queue for proper locking. Since those requests involve several
> >operations that have to be tied together with the queue beeing locked
> >for further 'user' requests, they are implemented as a state machine
> >with specific callbacks in the subdrivers
> >
> [cut]
> >
> >One thing that should probably be cleaned up is the difference between
> >the suspend and the resume request. I didn't want to implement 2
> >different request bits to avoid using too much of that bit-space, and
> >because most of the core handling is the same. So right now, I carry in
> >the special structure attached to the request, 2 fields. An int
> >indicating if we are doing a suspend or a resume op, and an int that is
> >the actual state machine step.
>
> > ===== include/linux/blkdev.h 1.100 vs edited =====
> > --- 1.100/include/linux/blkdev.h Sun Apr 20 18:20:10 2003
> > +++ edited/include/linux/blkdev.h Thu Apr 24 14:30:50 2003
> > @@ -116,6 +116,7 @@
> > __REQ_DRIVE_CMD,
> > __REQ_DRIVE_TASK,
> > __REQ_DRIVE_TASKFILE,
> > + __REQ_POWER_MANAGEMENT,
> > __REQ_NR_BITS, /* stops here */
> > };
>
>
> What about this - add __REQ_DRIVE_INTERNAL, and carry args
> in rq->cmd[16] [0] = PM, [1] = SUSPEND/RESUME, [2]= STATE ? IDE can use it
> for power managment, error handling (do not do it from interrupt
> context, but queue it), may be more. This way it would really makes
> things a bit better with the complicated IDE locking. SCSI and probably
> other block devices can benefit from this internal requests too, so the
> bit is not wasted.
There are already lots of "INTERNAL" - basically take your pick from all
the ones you quote above (DRIVE_TASK, DRIVE_CMD, DRIVE_TASKFILE - it's a
MESS). A power management special request makes sense to me.
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 30 2003 - 22:00:20 EST