> >> Another is that I feel (and I know Pavel doesn't agree here) that
> >> the disk driver should also block further incoming requests (that
> >> is leave them in the queue) instead of panic'ing. That is the
> >> driver should not rely on not beeing fed any more request, but
> >> rather make sure it will leave them in the queue and deal with
> >> them when resumed.
> >
> >It is cleaner if the ordering of power off is right. If the model is
> >right then the first suspend would be the drives. Part of drive suspend
> >ought to be corking the queue.
>
> Yup.
>
> My point here is that while Pavel approach is to kill/suspend anything
> that may trigger new IO requests (thus topping all userland, stopping
> selected kernel threads, etc...), I tend to think we leave all that
> alive, and just block requests going to suspended devices until those
> get alive again. That used to work well on pmac and leads to very
> fast suspend/resume cycles.
I believe it is simpler to do my way ;-). Of couse, adding stopping to
drivers will only add robustness and may enable faster suspends in
future (I do not think it is going to be significant)....
Pavel
-- When do you have heart between your knees? - 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/