Hi.
Here's a second patch; this exports gotoxy, reset_terminal, hide_cursor,
getconsxy and putconsxy for use in Software Suspend's nice display.
diff -ruN linux-2.6.1/drivers/char/vt.c software-suspend-linux-2.6.1-rev3/drivers/char/vt.c
--- linux-2.6.1/drivers/char/vt.c 2004-01-13 16:22:58.000000000 +1300
+++ software-suspend-linux-2.6.1-rev3/drivers/char/vt.c 2004-01-22 17:39:08.000000000 +1300
@@ -149,13 +149,13 @@
static void vc_init(unsigned int console, unsigned int rows,
unsigned int cols, int do_clear);
static void blank_screen(unsigned long dummy);
-static void gotoxy(int currcons, int new_x, int new_y);
+void gotoxy(int currcons, int new_x, int new_y);
static void save_cur(int currcons);
-static void reset_terminal(int currcons, int do_clear);
+void reset_terminal(int currcons, int do_clear);
static void con_flush_chars(struct tty_struct *tty);
static void set_vesa_blanking(unsigned long arg);
static void set_cursor(int currcons);
-static void hide_cursor(int currcons);
+void hide_cursor(int currcons);
static void unblank_screen_t(unsigned long dummy);
static void console_callback(void *ignored);
@@ -530,7 +530,7 @@
sw->con_putc(vc_cons[currcons].d, i, y, x);
}
-static void hide_cursor(int currcons)
+void hide_cursor(int currcons)
{
if (currcons == sel_cons)
clear_selection();
@@ -859,7 +859,7 @@
* might also be negative. If the given position is out of
* bounds, the cursor is placed at the nearest margin.
*/
-static void gotoxy(int currcons, int new_x, int new_y)
+void gotoxy(int currcons, int new_x, int new_y)
{
int min_y, max_y;
@@ -1403,7 +1403,7 @@
ESpalette };
/* console_sem is held (except via vc_init()) */
-static void reset_terminal(int currcons, int do_clear)
+void reset_terminal(int currcons, int do_clear)
{
top = 0;
bottom = video_num_lines;
@@ -2996,13 +2996,13 @@
return screenpos(currcons, 2 * w_offset, viewed);
}
-void getconsxy(int currcons, char *p)
+void getconsxy(int currcons, unsigned char *p)
{
p[0] = x;
p[1] = y;
}
-void putconsxy(int currcons, char *p)
+void putconsxy(int currcons, unsigned char *p)
{
gotoxy(currcons, p[0], p[1]);
set_cursor(currcons);
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
On Thu, Jan 22, 2004 at 09:12:00PM +1300, Nigel Cunningham wrote:
> Hi.
>
> Here's a second patch; this exports gotoxy, reset_terminal, hide_cursor,
> getconsxy and putconsxy for use in Software Suspend's nice display.
Why don't you open /dev/console on rootfs and use write(2)?
On Thu, Jan 22, 2004 at 09:12:00PM +1300, Nigel Cunningham wrote:
> Hi.
>
> Here's a second patch; this exports gotoxy, reset_terminal, hide_cursor,
> getconsxy and putconsxy for use in Software Suspend's nice display.
Really, swsusp shouldn't mess with console internals. And you don't even
explain what "nice display" is supposed to mean.
Hi.
'Nice display' means that it gives a simple, clean display with progress
bar etc. Al(?) Viro has informed me of the write call. I'll look it up
and see how I can improve things. As I said to Mr Viro, I'm just a user
who wanted Suspend to work better and ended up just about rewriting the
thing. Please forgive my ignorance!
Regards,
Nigel
On Thu, 2004-01-22 at 21:28, Christoph Hellwig wrote:
> On Thu, Jan 22, 2004 at 09:12:00PM +1300, Nigel Cunningham wrote:
> > Hi.
> >
> > Here's a second patch; this exports gotoxy, reset_terminal, hide_cursor,
> > getconsxy and putconsxy for use in Software Suspend's nice display.
>
> Really, swsusp shouldn't mess with console internals. And you don't even
> explain what "nice display" is supposed to mean.
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
On Fri, Jan 23, 2004 at 07:38:13AM +1300, Nigel Cunningham wrote:
> Hi.
>
> I'm not sure that write is what I want. At the very least, it will make
Sure it is. Write some wrapper functions that blat out the ANSI cursor
control sequences, just like anyone who does this from userspace
without using libcurses.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Hi.
I'm not sure that write is what I want. At the very least, it will make
the code harder to read and maintain. Here's a small portion of what I'm
currently doing:
/* Print version */
posn[0] = (unsigned char) (0);
posn[1] = (unsigned char) (video_num_lines);
putconsxy(suspend_console, posn);
cond_console_print(swsusp_version, strlen(swsusp_version));
/* Print header */
posn[0] = (unsigned char) ((video_num_columns - 29) / 2);
posn[1] = (unsigned char) ((video_num_lines / 3) -4);
putconsxy(suspend_console, posn);
The output looks something like this:
-----
S U S P E N D T O D I S K
Writing caches...
[-------- 120/640MB ]
2.0-rc4
-----
Bootsplash is also supported, so there's an even nicer version :>
Regards,
Nigel
On Thu, 2004-01-22 at 21:24, [email protected]
wrote:
> On Thu, Jan 22, 2004 at 09:12:00PM +1300, Nigel Cunningham wrote:
> > Hi.
> >
> > Here's a second patch; this exports gotoxy, reset_terminal, hide_cursor,
> > getconsxy and putconsxy for use in Software Suspend's nice display.
>
> Why don't you open /dev/console on rootfs and use write(2)?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
Also, by using write instead of blasting the low level code,
you will not have to worry about locking issues. (The way
you tap the low level stuff should require at least the console
semaphore held, write to /dev/console don't)
Ben
Hi.
On Fri, 2004-01-23 at 15:49, Benjamin Herrenschmidt wrote:
> Also, by using write instead of blasting the low level code,
> you will not have to worry about locking issues. (The way
> you tap the low level stuff should require at least the console
> semaphore held, write to /dev/console don't)
>
> Ben
Locking is not an issue. This is suspend-to-disk. Everything else is
stopped while we're working.
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)?
Regards,
Nigel
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
Sorry to reply to myself.
I don't think I worded that last message right... I didn't mean that
locking isn't an issue at all, just that we don't have to worry about
another process writing to the console while we are.
Nigel
On Sat, 2004-01-24 at 05:07, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2004-01-23 at 15:49, Benjamin Herrenschmidt wrote:
> > Also, by using write instead of blasting the low level code,
> > you will not have to worry about locking issues. (The way
> > you tap the low level stuff should require at least the console
> > semaphore held, write to /dev/console don't)
> >
> > Ben
>
> Locking is not an issue. This is suspend-to-disk. Everything else is
> stopped while we're working.
>
> 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)?
>
> Regards,
>
> Nigel
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
On Fri, 2004-01-23 at 14:07, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2004-01-23 at 15:49, Benjamin Herrenschmidt wrote:
> > Also, by using write instead of blasting the low level code,
> > you will not have to worry about locking issues. (The way
> > you tap the low level stuff should require at least the console
> > semaphore held, write to /dev/console don't)
> >
> > Ben
>
> 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...
> 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 :)
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 ?
In both cases, it should be fine.
Ben.
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.