Re: suspend.c vs driver-model.txt

[Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>]

>I do not know if such feelings are worth the effort of driver authors.

My experience with drivers here is that it isn't very difficult
to get that done right, but well...

>Certainly, it feels safer that way. But I believe that what I
>currently have is bulletproof...

If you say so... I'm still afraid with relying on the kernel
not triggering any IO for whatever random reason, I'd rather
have things designed to be bulletproof from the ground up, but
that may well be due to my lack of intimate knowledge of various
parts of the kernel not directly related to arch code & drivers.

We can end the debate here anyway, there is nothing in the
driver semantics I propose incompatible with software suspend
anyway, I'd suggest to document those semantics with blocking
of IOs and time will show how drivers keep up.

Patrick: On my side, I'll start moving the pmac drivers to
the new model as soon as I can get a recent 2.5 to boot a pmac
again, then I'll move my PM stuff to the new model and see what
issues arise. I'll try to have both suspend-to-RAM and suspend-
to-disk using Pavel's stuff working so we can validate the whole
mecanism.

No promise on time frame though, I've been pretty busy lately
and I have to get 2.4 working on some new Apple HW as well...

Ben.




-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31