Re: suspend.c vs driver-model.txt

[Pavel Machek <pavel-AlSwsSmVLrQ@public.gmane.org>]

Hi!

> The nice thing here, I beleive, is that suspend to disk could then just
> be an additional generic step between 1) and 2) that takes care of
> dumping memory content to disk.

It can not, because after saving state you can not easily write to
swap partition.

> As far as suspend to disk is concerned, we have all sort of nasty issues
> we discussed that I don't feel like resuming right now, so I would rather
> have the lowest level driver able to play the backing store export a
> couple of "hooks" used to dump the pages to the medium, those would work
> synchronously, without VM activity, etc... The driver that is target for
> that would have pre-allocated what it needs, pre-mapped DMA mappings it
> needs etc...

Too complicated. Look at swsusp -- it is designed not to need
pre-allocated pages, pre-mapped DMA etc.

> Though, thinking as I write, injecting requests via the BIO layer may
> be a nicer solution, provided we make sure the driver won't get any
> request _but_ the ones we feed it. I don't trust a mecanism that would
> selectively stop given kernel threads, then just hope nobody will push
> requests any more. That's way too fragile to my taste. I'd rather
> freeze

Why is it fragile? You just have to be carefull. If you mark thread as
PF_IOTHREAD it must *not* generate requests unless told to.
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
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