Re: [RFC] Hard disk protection revisited

[Jens Axboe <axboe@suse.de>]

On Fri, Oct 07 2005, Jon Escombe wrote:
> Jens Axboe wrote:
> 
> >I have to nack this one for now, I still want the generic command types
> >patch to go in first. We have far too many queue hooks already, adding
> >two more for a relatively obscure use such as this one is not a good
> >idea.
> >
> >My suggestion is to maintain this patch out of tree for now, it will be
> >a few kernel release iterations before the command type patch is in.
> > 
> >
> 
> That's a fair comment (and not entirely unexpected), I don't have a 
> problem with looking after this out of tree for now...
> 
> One issue with the generic command approach occured to me while making 
> this patch - although it's more likely an issue with my understanding ;)
> 
> I'm assuming that it would work like this -- the block layer still has 
> the sysfs attribute, and queues the new command for the lower driver to 
> pick up. The driver receives the command and does it's custom 
> park/freeze work, then calls a common block layer function to setup the 
> timer (all good so far). Where it gets hazy (for me) is how the block 
> layer starts the queue up again - as this ended up needing to be driver 
> specific & I can't see how the block layer would get another command 
> down if the queue is stopped?

It just sends an unfreeze request. It's similar to how we have to allow
suspend commands on an otherwise suspended queue. Since the block layer
has control of the frozen queue, it should not be a problem.

-- 
Jens Axboe