Re: PATCH: Export console functions for use by Software Suspend nice display

[Nigel Cunningham <ncunningham@users.sourceforge.net>]

[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]

Hi.

On Fri, 2004-01-23 at 16:12, Benjamin Herrenschmidt wrote:
> > Locking is not an issue. This is suspend-to-disk. Everything else is
> > stopped while we're working.
> 
> No. You can still get a printk from irq... 

Mmm. But we also adjust the console loglevel depending upon the
verbosity of debugging info required. (And reset it when we're done).
When the nice display is on, the loglevel is 0 or 1. If a driver wants
to printk at KERN_EMERG or KERN_ALERT then, well the display should get
messed up a little :>

> > By the way, am I understanding the suggestion correctly? Do you
> > (collective) mean getting a fd for /dev/console from within kernel code
> > and using that? I've been looking at the way printk works and wondering
> > if con->write is equivalent (once I find the right console to write to)?
> 
> Yes. get an fd and write to it. grep for write to find other uses :)

I did. Didn't find much. I'll look again. Perhaps I'm just blind :>

> You may have to be a bit careful about what context you are in, but I
> suppose it's whatever userland process triggered the sleep in the
> first place, no ? For load, it's probably whatever process did swapon ?

No. There's a kernel daemon - kswsuspd - that does all the hard work.
The userland process that initiates the suspend sleeps in
wait_for_completion until post resume. At boot time, we initiate the
resume via an init call. Still fine?

Regards,

Nigel
.
-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]