[RFC] userland swsusp

[RFC] userland swsusp

[Pavel Machek]

Hi!

This is prototype of userland swsusp. I'd like kernel parts to go in,
probably for 2.6.16. Now, I'm not sure about the interface, ioctls are
slightly ugly, OTOH it would be probably overkill to introduce
syscalls just for this. (I'll need to add an ioctl for freeing memory
in future).

Small question is where should userspace parts go. In-kernel
kernel/power/swsusp.c is basically replaced by usr/swsusp.c.... 

[Of course, I'll need to fix the patch up so that it does not modify
existing behaviour].

Signed-off-by: Pavel Machek <pavel@suse.cz>
								Pavel

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -27,6 +27,7 @@
 #include <linux/crash_dump.h>
 #include <linux/backing-dev.h>
 #include <linux/bootmem.h>
+#include <linux/suspend.h>
 
 #include <asm/uaccess.h>
 #include <asm/io.h>
@@ -559,6 +561,45 @@ static ssize_t write_port(struct file * 
 }
 #endif
 
+static int
+ioctl_kmem(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
+{
+        int retval = 0;
+
+        switch (cmd) {
+	case IOCTL_FREEZE:
+		retval = sys_freeze();
+		break;
+	case IOCTL_UNFREEZE:
+		retval = sys_unfreeze();
+		break;
+	case IOCTL_ATOMIC_SNAPSHOT:
+		retval = sys_atomic_snapshot(arg);
+		break;
+	case IOCTL_ATOMIC_RESTORE:
+		{
+			int pages;
+			void *pgdir;
+			get_user(pages, (long *) arg);
+			get_user(pgdir, (void **) (arg + 4));
+			retval = sys_atomic_restore(pgdir, pages);
+		}
+		break;
+	case IOCTL_KMALLOC:
+		retval = get_zeroed_page(GFP_KERNEL);
+		break;
+	case IOCTL_KFREE:
+		free_page(arg);
+		break;
+        default:
+                retval = -ENOTTY;
+                break;
+        }
+
+        return retval;
+}
+
+
 static ssize_t read_null(struct file * file, char __user * buf,
 			 size_t count, loff_t *ppos)
 {
@@ -769,6 +810,7 @@ static struct file_operations mem_fops =
 static struct file_operations kmem_fops = {
 	.llseek		= memory_lseek,
 	.read		= read_kmem,
+	.ioctl		= ioctl_kmem,
 	.write		= write_kmem,
 	.mmap		= mmap_kmem,
 	.open		= open_kmem,
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -1,6 +1,7 @@
 #ifndef _LINUX_SWSUSP_H
 #define _LINUX_SWSUSP_H
 
+#ifdef __KERNEL__
 #if defined(CONFIG_X86) || defined(CONFIG_FRV) || defined(CONFIG_PPC32)
 #include <asm/suspend.h>
 #endif
@@ -9,6 +10,7 @@
 #include <linux/config.h>
 #include <linux/init.h>
 #include <linux/pm.h>
+#endif
 
 /* page backup entry */
 typedef struct pbe {
@@ -30,6 +32,7 @@ typedef struct pbe {
 #define for_each_pb_page(pbe, pblist) \
 	for (pbe = pblist ; pbe ; pbe = (pbe+PB_PAGE_SKIP)->next)
 
+#ifdef __KERNEL__
 
 #define SWAP_FILENAME_MAXLENGTH	32
 
@@ -79,4 +82,24 @@ unsigned long get_safe_page(gfp_t gfp_ma
  */
 #define PAGES_FOR_IO	512
 
+#endif
+
+struct restore_ioctl {
+	void *pgdir;
+	int nr_pages;
+};
+
+#define IOCTL_FREEZE _IO('3', 1)
+#define IOCTL_UNFREEZE _IO('3', 2)
+#define IOCTL_ATOMIC_SNAPSHOT _IOW('3', 3, void **)
+#define IOCTL_ATOMIC_RESTORE _IOR('3', 4, struct restore_ioctl)
+#define IOCTL_KMALLOC _IO('3', 5)
+#define IOCTL_KFREE _IOR('3', 6, void *)
+
+extern int sys_freeze(void);
+extern int sys_unfreeze(void);
+extern int sys_atomic_snapshot(void **pgdir);
+extern int sys_atomic_restore(void *pgdir, int pages);
+
+
 #endif /* _LINUX_SWSUSP_H */
diff --git a/kernel/power/console.c b/kernel/power/console.c
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -9,6 +9,7 @@
 #include <linux/console.h>
 #include "power.h"
 
+#undef SUSPEND_CONSOLE
 static int new_loglevel = 10;
 static int orig_loglevel;
 #ifdef SUSPEND_CONSOLE
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -143,12 +144,25 @@ thaw:
 
 static void unprepare_processes(void)
 {
-	platform_finish();
 	thaw_processes();
 	enable_nonboot_cpus();
 	pm_restore_console();
 }
 
+
+int sys_freeze(void)
+{
+	return prepare_processes();
+}
+
+int sys_unfreeze(void)
+{
+	thaw_processes();
+	enable_nonboot_cpus();
+	pm_restore_console();
+	return 0;
+}
+
 /**
  *	pm_suspend_disk - The granpappy of power management.
  *
@@ -243,6 +257,9 @@ static int software_resume(void)
 	if ((error = swsusp_check()))
 		goto Done;
 
+	/* Prepare processes only after swsusp_check; we could do it before,
+	   but it would mean an ugly console switch even in case of normal boot.
+	 */
 	pr_debug("PM: Preparing processes for restore.\n");
 
 	if ((error = prepare_processes())) {
diff --git a/kernel/power/swsusp.c b/kernel/power/swsusp.c
--- a/kernel/power/swsusp.c
+++ b/kernel/power/swsusp.c
@@ -498,6 +499,8 @@ static int write_pagedir(void)
 
 	printk( "Writing pagedir...");
 	for_each_pb_page (pbe, pagedir_nosave) {
+		/* FIXME: pagedir only has 768 entries. We may overflow it,
+		   if we write around 768000 pages, thats ~4GB. */
 		if ((error = write_page((unsigned long)pbe, &swsusp_info.pagedir[n++])))
 			return error;
 	}
@@ -537,7 +540,10 @@ static int write_suspend_image(void)
 
 	if (!enough_swap(nr_copy_pages)) {
 		printk(KERN_ERR "swsusp: Not enough free swap\n");
+#if 0
+		/* FIXME: should be done earlier */
 		return -ENOSPC;
+#endif
 	}
 
 	init_header();
@@ -1008,3 +1028,55 @@ void swsusp_close(void)
 
 	blkdev_put(resume_bdev);
 }
+
+static int in_suspend __nosavedata = 0;
+
+int sys_atomic_snapshot(void **pgdir)
+{
+	int err;
+
+	err = device_suspend(PMSG_FREEZE);
+	if (err)
+		return err;
+
+	in_suspend = 1;
+	err = swsusp_suspend();
+
+	*pgdir = pagedir_nosave; /* FIXME: put_user */
+
+	{
+		struct pbe *p = pagedir_nosave;
+		int i = 0;
+		for_each_pbe (p, pagedir_nosave)
+			i++;
+	}
+
+	if (!err)
+		err = nr_copy_pages;
+	if (in_suspend == 2) {
+		err = -ENOANO;
+	}
+
+	device_resume();
+	return err;
+}
+
+int sys_atomic_restore(void *pgdir, int pages)
+{
+	int err;
+	/* FIXME: we'll probably overwrite pagedir with itself in inconsistent state...
+	 ...no, pagedir is NOSAVE.
+	*/
+
+	err = device_suspend(PMSG_FREEZE);
+	if (err)
+		return err;
+
+	in_suspend = 2;
+	pagedir_nosave = pgdir;
+	nr_copy_pages = pages;
+
+	err = swsusp_resume();
+	printk(KERN_CRIT "This should never return\n");
+	return err;
+}
diff --git a/usr/swsusp-init b/usr/swsusp-init
new file mode 100755
--- /dev/null
+++ b/usr/swsusp-init
@@ -0,0 +1,9 @@
+#!/bin/bash
+#
+# swapoff /dev/hda1; cat /dev/zero | head -c 4096 > /dev/hda1
+# /tmp/swsusp /dev/hda1 -s -b
+/tmp/swsusp /dev/hda1 -r 
+exec /sbin/init
+exit
+
+
diff --git a/usr/swsusp.c b/usr/swsusp.c
new file mode 100755
--- /dev/null
+++ b/usr/swsusp.c
@@ -0,0 +1,529 @@
+#if 0
+#
+# Swsusp3 control program
+#
+# Copyright 2005 Pavel Machek <pavel@suse.cz>
+#
+# Distribute under GPLv2
+#
+gcc -g -Wall usr/swsusp.c -o /tmp/swsusp; cp -a usr/swsusp-init /tmp
+exit
+#
+#endif
+
+#define PAGE_SIZE 4096
+
+#include <unistd.h>
+#include <syscall.h>
+//#include <fcntl.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <sys/mman.h>
+#include <sys/ioctl.h>
+#include <asm/fcntl.h>
+#include <string.h>
+
+extern __off64_t lseek64 (int __fd, __off64_t __offset, int __whence) __THROW;
+
+typedef long swp_entry_t;
+
+#include "/data/l/linux-sw3/include/linux/suspend.h"
+#include "/data/l/linux-sw3/include/linux/reboot.h"
+
+char forbidden_pages[(0xffffffff / PAGE_SIZE)+1];
+
+struct resume {
+	int nr_copy_pages;
+	void *pagedir;
+} resume;
+
+struct pbe_page {
+	unsigned long address;		/* address of the copy */
+	unsigned long orig_address;	/* original address of page */
+	swp_entry_t swap_address;	
+
+	struct pbe *next;	/* also used as scratch space at
+				 * end of page (see link, diskpage)
+				 */
+	char data[4096-16];
+};
+
+int kmem;
+
+void
+seek(unsigned long dest)
+{
+	if (lseek64(kmem, dest, SEEK_SET) != dest) {
+		fprintf(stderr, "Could not do intial seek to %lx: %m\n", dest);
+		fprintf(stderr, "lseek64(%d) returned: %lx\n", kmem, (long) lseek64(kmem, dest, SEEK_SET));
+		exit(1);
+	}
+}
+
+typedef int (*walker_t)(struct pbe *p, int i);
+typedef int (*walker2_t)(struct pbe_page *p, int i);
+
+int
+walk_chain(struct resume *r, walker_t w)
+{
+	struct pbe p;
+	int i = 0;
+	long pos;
+
+	seek(pos = (long) r->pagedir);
+	while (1) {
+		if (read(kmem, &p, sizeof(p)) != sizeof(p)) {
+			fprintf(stderr, "Could not read pbe #%d: %m\n", i);
+			exit(1);
+		}
+		if (w != NULL) {
+			w(&p, i);
+			seek(pos);
+			if (write(kmem, &p, sizeof(p)) != sizeof(p)) {
+				fprintf(stderr, "Could not write back pbe #%d: %m\n", i);
+				exit(1);
+			}
+		}
+		i++;
+		if (!p.next)
+			break;
+		seek(pos = (long) p.next);
+	}
+	return i;
+}
+
+void
+walk_pages_chain(struct resume *r, walker2_t w)
+{
+	struct pbe_page p;
+	int i = 0;
+	long pos;
+
+	seek(pos = (long) r->pagedir);
+	while (1) {
+		if (read(kmem, &p, sizeof(p)) != sizeof(p)) {
+			fprintf(stderr, "Could not read pbe #%d: %m\n", i);
+			exit(1);
+		}
+		if ((w != NULL) && !(pos & 0xfff)) {
+			w(&p, i);
+			seek(pos);
+			if (write(kmem, &p, sizeof(p)) != sizeof(p))
+				fprintf(stderr, "Could not write back pbe #%d: %m\n", i);
+		}
+		i++;
+		if (!p.next)
+			break;
+		seek(pos = (long) p.next);
+	}
+}
+
+
+int image_fd, image_pos = 4096;
+
+static int write_page(unsigned long addr, swp_entry_t * loc)
+{
+	swp_entry_t entry;
+
+	entry = image_pos;
+	image_pos += 4096;
+
+	{
+		char buf[4096];
+		seek(addr);
+		if (read(kmem, buf, 4096) != 4096) {
+			fprintf(stderr, "Could not read page #%lx: %m\n", addr);
+			exit(1);
+		}
+		*loc = image_pos;
+		if (lseek(image_fd, image_pos, SEEK_SET) != image_pos) {
+			fprintf(stderr, "Could not seek in image to #%d: %m\n", image_pos);
+			exit(1);
+		}
+		if (write(image_fd, buf, 4096) != 4096) {
+			fprintf(stderr, "Could not write to image at #%d: %m\n", image_pos);
+			exit(1);
+		}
+	}
+	return 0;
+}
+
+unsigned int mod;
+
+static int data_write_one(struct pbe *p, int i)
+{
+	int error;
+	if (!(i%mod))
+		printf( "\b\b\b\b%3d%%", i / mod );
+	if ((error = write_page(p->address, &(p->swap_address))))
+		return error;
+	return 0;
+}
+
+
+struct swsusp_info {
+	int			nr_copy_pages;
+	int			version_code;
+	char			signature[10];
+	swp_entry_t		pagedir[768];
+} __attribute__((aligned(4096)));
+
+struct swsusp_info swsusp_info, zeros;
+
+/**
+ *	data_write - Write saved image to swap.
+ */
+static int data_write(void)
+{
+	int error = 0;
+	mod = resume.nr_copy_pages / 100;
+
+	if (!mod)
+		mod = 1;
+
+	printf( "Writing data to swap (%d pages)...     ", resume.nr_copy_pages );
+	walk_chain(&resume, data_write_one);
+	printf("\b\b\b\bdone\n");
+	return error;
+}
+
+unsigned n = 0;
+
+static int pgdir_write_one(struct pbe_page *pbe, int i)
+{
+	int error;
+	if ((error = write_page((unsigned long)pbe, &swsusp_info.pagedir[n++])))
+		return error;
+	return 0;
+}
+
+/**
+ *	write_pagedir - Write the array of nr_copy_pages holding the page directory.
+ *	@last:	Last swap entry we write (needed for header).
+ */
+
+static int write_pagedir(void)
+{
+	int error = 0;
+
+	printf( "Writing pagedir...");
+	walk_pages_chain(&resume, pgdir_write_one);
+
+	swsusp_info.nr_copy_pages = n;
+	printf("done (%u pages)\n", n);
+	return error;
+}
+
+
+/**
+ *	write_suspend_image - Write entire image and metadata.
+ *
+ */
+static int write_suspend_image(void)
+{
+	int error;
+
+	if ((error = data_write()))
+		goto Done;
+
+	if ((error = write_pagedir()))
+		goto Done;
+
+	swsusp_info.nr_copy_pages = resume.nr_copy_pages;
+	swsusp_info.version_code = 1;
+	strcpy(swsusp_info.signature, "swsusp3");
+	lseek(image_fd, 0, SEEK_SET);
+	write(image_fd, &swsusp_info, 4096);
+ Done:
+	return error;
+}
+
+char *image;
+
+int
+do_suspend(void)
+{
+	kmem = open("/dev/kmem", O_RDWR | O_LARGEFILE);
+	image_fd = open(image, O_RDWR | O_CREAT, 0600);
+	resume.nr_copy_pages = -1;
+	resume.pagedir = NULL;
+
+	if (kmem < 0) {
+		fprintf(stderr, "Could not open /dev/kmem: %m\n");
+		exit(1);
+	}
+
+	if (ioctl(kmem, IOCTL_FREEZE, 0)) {
+		fprintf(stderr, "Could not freeze system: %m\n");
+		exit(1);	/* We do not want to reboot in case of failure */
+	}
+
+	resume.nr_copy_pages = ioctl(kmem, IOCTL_ATOMIC_SNAPSHOT, &resume.pagedir);
+	if (resume.nr_copy_pages < 0) {
+		fprintf(stderr, "Could not snapshot system: %m\n");
+
+		if (ioctl(kmem, IOCTL_UNFREEZE, 0)) {
+			fprintf(stderr, "Could not unfreeze system: %m\n");
+			return 1;
+		}
+		exit(1);	/* Stop infinite loop of reboots */
+	}
+
+	walk_chain(&resume, NULL);
+	/* Ouch, at this point we'll appear in ATOMIC_SNAPSHOT syscall, with no way to tell... */
+
+	printf("Snapshotted, have %d pages, pagedir at %lx\n", resume.nr_copy_pages, (long) resume.pagedir);
+	walk_chain(&resume, NULL);
+	write_suspend_image();
+	fsync(image_fd);
+
+	return 0;
+
+}
+
+
+
+/**
+ *	fill_pb_page - Create a list of PBEs on a given memory page
+ */
+
+static inline void fill_pb_page(struct pbe *pbpage)
+{
+	struct pbe *p;
+
+	p = pbpage;
+	pbpage += PB_PAGE_SKIP;
+	do
+		p->next = p + 1;
+	while (++p < pbpage);
+}
+
+unsigned long get_page(void)
+{
+	unsigned long ret;
+
+	do {
+		ret = ioctl(kmem, IOCTL_KMALLOC, 1);
+	} while(forbidden_pages[ret/PAGE_SIZE]);	
+
+	return ret;
+}
+
+/**
+ *	alloc_pagedir - Allocate the page directory.
+ *
+ *	First, determine exactly how many pages we need and
+ *	allocate them.
+ *
+ *	We arrange the pages in a chain: each page is an array of PBES_PER_PAGE
+ *	struct pbe elements (pbes) and the last element in the page points
+ *	to the next page.
+ *
+ *	On each page we set up a list of struct_pbe elements.
+ */
+
+static struct pbe * alloc_pagedir(unsigned nr_pages)
+{
+	unsigned num;
+	struct pbe *pblist;
+	struct pbe buf[PBES_PER_PAGE];
+	int i;
+
+	printf("alloc_pagedir(): nr_pages = %d\n", nr_pages);
+	resume.pagedir = pblist = (struct pbe *) get_page();
+	for (num = PBES_PER_PAGE; num < nr_pages;
+        		nr_pages -= PBES_PER_PAGE) {
+
+		for (i=0; i<PBES_PER_PAGE-1; i++)
+			buf[i].next = &pblist[i+1];
+		buf[PBES_PER_PAGE-1].next = (struct pbe *) get_page();
+
+		seek((long) pblist);
+		write(kmem, buf, PAGE_SIZE);
+		pblist = buf[PBES_PER_PAGE-1].next;
+	}
+
+	for (i=0; i<nr_pages-1; i++)
+		buf[i].next = &pblist[i+1];
+	buf[nr_pages-1].next = 0;
+
+	seek((long) pblist);
+	write(kmem, buf, PAGE_SIZE);
+	return NULL;
+}
+
+
+
+
+/**
+ *	read_pagedir - Read page backup list pages from swap
+ */
+
+static int read_pagedir_one(struct pbe *pbpage, int pos)
+{
+	struct pbe buf[PBES_PER_PAGE];
+	int error;
+	int i;
+	unsigned long offset = swsusp_info.pagedir[pos/PBES_PER_PAGE];
+
+	error = -1;
+	if (!offset)
+		printf("Something went very wrong at pagedir #%d\n", pos);
+
+	lseek(image_fd, offset, SEEK_SET);
+	error = (read(image_fd, (void *)buf, PAGE_SIZE) != PAGE_SIZE);
+
+	for (i=0; i<PBES_PER_PAGE; i++) {
+		pbpage[i].orig_address = buf[i].orig_address;
+		forbidden_pages[pbpage[i].orig_address / PAGE_SIZE] = 1;
+		pbpage[i].swap_address = buf[i].swap_address;
+		pbpage[i].address = buf[i].address;
+	}
+
+	return error;
+}
+
+
+
+/**
+ *	data_read - Read image pages from swap.
+ */
+static int data_read_one(struct pbe *p, int i)
+{
+	int error = 0;
+	char buf[PAGE_SIZE];
+
+	if (!(i % mod))
+		printf("\b\b\b\b%3d%%", i / mod);
+
+	lseek(image_fd, p->swap_address, SEEK_SET);
+
+	p->address = get_page();
+	error = (read(image_fd, buf, PAGE_SIZE) != PAGE_SIZE);
+	seek(p->address);
+	error = (write(kmem, buf, PAGE_SIZE) != PAGE_SIZE);
+
+	return error;
+}
+
+int
+do_resume(void)
+{
+	kmem = open("/dev/kmem", O_RDWR | O_LARGEFILE);
+	image_fd = open(image, O_RDWR);
+
+	if (kmem < 0) {
+		fprintf(stderr, "Could not open /dev/kmem: %m\n");
+		return 1;
+	}
+
+	memset(&swsusp_info, 0, sizeof(swsusp_info));
+	read(image_fd, &swsusp_info, sizeof(swsusp_info));
+	resume.nr_copy_pages = swsusp_info.nr_copy_pages;
+
+	if (strcmp("swsusp3", swsusp_info.signature))
+		exit(0);
+	if (lseek(image_fd, 0, SEEK_SET) != 0) {
+		printf("Could not seek to kill sig: %m\n");
+		exit(1);
+	}
+	if (write(image_fd, &zeros, sizeof(swsusp_info)) != sizeof(swsusp_info)) {
+		printf("Could not write to kill sig: %m\n");
+		exit(1);
+	}
+	if (fsync(image_fd)) {
+		printf("Could not fsync to kill sig: %m\n");
+		exit(1);
+	}
+	printf("Got image, %d pages, signature [%s]\n", resume.nr_copy_pages, swsusp_info.signature);
+
+	alloc_pagedir(resume.nr_copy_pages);
+	printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
+	printf("swsusp: Reading pagedir ");
+	walk_pages_chain(&resume, (void *) read_pagedir_one);
+	printf("ok\n");
+
+	/* Need to be done twice; so that forbidden_pages comes into effect */
+	alloc_pagedir(resume.nr_copy_pages);
+	printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
+	printf("swsusp: Reading pagedir ");
+	walk_pages_chain(&resume, (void *) read_pagedir_one);
+	printf("ok\n");
+
+	printf("Verifying allocated pagedir: %d pages\n", walk_chain(&resume, NULL));
+
+	/* FIXME: Need to relocate pages */
+	mod = swsusp_info.nr_copy_pages / 100;
+	if (!mod)
+		mod = 1;
+	printf("swsusp: Reading image data (%d pages):     ",
+			swsusp_info.nr_copy_pages);
+	walk_chain(&resume, data_read_one);
+	printf("\b\b\b\bdone\n");
+
+	if (ioctl(kmem, IOCTL_FREEZE, 0)) {
+		fprintf(stderr, "Could not freeze system: %m\n");
+		return 1;
+	}
+
+	if (ioctl(kmem, IOCTL_ATOMIC_RESTORE, &resume)) {
+		fprintf(stderr, "Could not restore system: %m\n");
+	}
+	/* Ouch, at this point we'll appear in ATOMIC_SNAPSHOT syscall, if
+	   things went ok... */
+
+	return 0;
+}
+
+/*
+#define  LINUX_REBOOT_CMD_RESTART        0x01234567
+#define  LINUX_REBOOT_CMD_HALT           0xCDEF0123
+#define  LINUX_REBOOT_CMD_POWER_OFF      0x4321FEDC
+#define  LINUX_REBOOT_CMD_RESTART2       0xA1B2C3D4
+#define  LINUX_REBOOT_CMD_SW_SUSPEND     0xD000FCE2
+*/
+
+int reboot(unsigned long todo)
+{
+	syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, todo, 0);
+	return 0;
+}
+
+int
+main(int argc, char *argv[])
+{
+	int error;
+
+	sync();
+	setvbuf(stdout, NULL, _IONBF, 0);
+	setvbuf(stderr, NULL, _IONBF, 0);
+
+	if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
+		fprintf(stderr, "Could not lock myself: %m\n");
+		return 1;
+	}
+
+	image = argv[1];
+
+	while (argv[2]) {
+
+		if (!strcmp(argv[2], "-s"))
+			error = do_suspend();
+
+		if (!strcmp(argv[2], "-b"))
+			reboot(LINUX_REBOOT_CMD_RESTART);
+
+		if (!strcmp(argv[2], "-h"))
+			reboot(LINUX_REBOOT_CMD_HALT);
+
+		if (!strcmp(argv[2], "-o"))
+			reboot(LINUX_REBOOT_CMD_POWER_OFF);
+
+		if (!strcmp(argv[2], "-r"))
+			error = do_resume();
+
+		argv++;
+	}
+	return error;
+}
+

-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Tue, Nov 15, 2005 at 10:29:42PM +0100, Pavel Machek wrote:
> Hi!
> 
> This is prototype of userland swsusp. I'd like kernel parts to go in,
> probably for 2.6.16. Now, I'm not sure about the interface, ioctls are
> slightly ugly, OTOH it would be probably overkill to introduce
> syscalls just for this. (I'll need to add an ioctl for freeing memory
> in future).

What's wrong with 4 new syscalls?  It seems the cleanest way.

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > This is prototype of userland swsusp. I'd like kernel parts to go in,
> > probably for 2.6.16. Now, I'm not sure about the interface, ioctls are
> > slightly ugly, OTOH it would be probably overkill to introduce
> > syscalls just for this. (I'll need to add an ioctl for freeing memory
> > in future).
> 
> What's wrong with 4 new syscalls?  It seems the cleanest way.

I'd need about 7 of them, and that is on at least 3 architectures
(i386, x86-64, ppc, not sure about ppc64/arm). And it does not fix the
interface -- userland parts will still need to read/write /dev/kmem
:-(.

Yep, I can do it...
								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Tue, Nov 15, 2005 at 10:29:42PM +0100, Pavel Machek wrote:
 > Hi!
 > 
 > This is prototype of userland swsusp. I'd like kernel parts to go in,
 > probably for 2.6.16. Now, I'm not sure about the interface, ioctls are
 > slightly ugly, OTOH it would be probably overkill to introduce
 > syscalls just for this. (I'll need to add an ioctl for freeing memory
 > in future).

Just for info: If this goes in, Red Hat/Fedora kernels will fork
swsusp development, as this method just will not work there.
(We have a restricted /dev/mem that prevents writes to arbitary
 memory regions, as part of a patchset to prevent rootkits)

Even it were not for this, the whole idea seems misconcieved to me
anyway.

		Dave

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

>  > This is prototype of userland swsusp. I'd like kernel parts to go in,
>  > probably for 2.6.16. Now, I'm not sure about the interface, ioctls are
>  > slightly ugly, OTOH it would be probably overkill to introduce
>  > syscalls just for this. (I'll need to add an ioctl for freeing memory
>  > in future).
> 
> Just for info: If this goes in, Red Hat/Fedora kernels will fork
> swsusp development, as this method just will not work there.
> (We have a restricted /dev/mem that prevents writes to arbitary
>  memory regions, as part of a patchset to prevent rootkits)

If this goes in, you can still keep using old method... I'll not
remove it anytime soon.

> Even it were not for this, the whole idea seems misconcieved to me
> anyway.

...but how do you provide nice, graphical progress bar for swsusp
without this? People want that, and "esc to abort", compression,
encryption. Too much to be done in kernel space, IMNSHO.
							Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Wed, Nov 16, 2005 at 12:32:01AM +0100, Pavel Machek wrote:

 > If this goes in, you can still keep using old method... I'll not
 > remove it anytime soon.

Ok.

 > > Even it were not for this, the whole idea seems misconcieved to me
 > > anyway.
 > 
 > ...but how do you provide nice, graphical progress bar for swsusp
 > without this? People want that, and "esc to abort", compression,
 > encryption. Too much to be done in kernel space, IMNSHO.
 
I'll take "rootkit doesnt work" over "bells and whistles".

I think most users actually care more about "works" than
"looks pretty, and then fails spectacularly".

		Dave

Re: [linux-pm] [RFC] userland swsusp

[Dumitru Ciobarcianu]

În data de Mi, 16-11-2005 la 00:32 +0100, Pavel Machek a scris:
> ...but how do you provide nice, graphical progress bar for swsusp
> without this? People want that, and "esc to abort", compression,
> encryption. Too much to be done in kernel space, IMNSHO.

Pavel, you really should _listen_ when someone else is talking about the
same things in different implementations. suspend2 has this feature
(nice graphical progress bars in userspace) for a long time now and it's
compatible with the fedora kernels.

Why don't you and Nigel (of suspend2) can just work together on this ?
It's a shame that much work is wasted in duplicated effort.

-- 
Cioby

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi.

On Wed, 2005-11-16 at 17:14, Greg KH wrote:
> On Wed, Nov 16, 2005 at 06:35:30AM +0200, Dumitru Ciobarcianu wrote:
> > ??n data de Mi, 16-11-2005 la 00:32 +0100, Pavel Machek a scris:
> > > ...but how do you provide nice, graphical progress bar for swsusp
> > > without this? People want that, and "esc to abort", compression,
> > > encryption. Too much to be done in kernel space, IMNSHO.
> > 
> > Pavel, you really should _listen_ when someone else is talking about the
> > same things in different implementations. suspend2 has this feature
> > (nice graphical progress bars in userspace) for a long time now and it's
> > compatible with the fedora kernels.
> 
> It's also implemented in the kernel, which is exactly the wrong place
> for this.  Pavel is doing this properly, why do you doubt him?

You yourself called it a hack not long ago. I'm not sure why you think
the userspace is the right place for suspending. It seems to me that the
very fact that it requires access to structures that are normally only
visible to the kernel is pretty telling. To be fair, it is true at the
same time that graphical interfaces don't belong in the kernel - but the
vast majority of it - calculating what to write and doing the writing
does. It's only by hamstringing himself and the user - limiting the
image to half of memory that Pavel (and dropping support for writing to
swap) that Pavel can make this work.

> > Why don't you and Nigel (of suspend2) can just work together on this ?
> > It's a shame that much work is wasted in duplicated effort.
> 
> It's not duplicated, Nigel knows what need to be done to work together,
> if he so desires.

I know that Pavel and I have such different ideas about what should be
done that it's not worth the effort.

Regards,

Nigel

> thanks,
> 
> greg k-h
> 
> ______________________________________________________________________
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
-- 

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Wed, Nov 16, 2005 at 06:35:30AM +0200, Dumitru Ciobarcianu wrote:
> ??n data de Mi, 16-11-2005 la 00:32 +0100, Pavel Machek a scris:
> > ...but how do you provide nice, graphical progress bar for swsusp
> > without this? People want that, and "esc to abort", compression,
> > encryption. Too much to be done in kernel space, IMNSHO.
> 
> Pavel, you really should _listen_ when someone else is talking about the
> same things in different implementations. suspend2 has this feature
> (nice graphical progress bars in userspace) for a long time now and it's
> compatible with the fedora kernels.

It's also implemented in the kernel, which is exactly the wrong place
for this.  Pavel is doing this properly, why do you doubt him?

> Why don't you and Nigel (of suspend2) can just work together on this ?
> It's a shame that much work is wasted in duplicated effort.

It's not duplicated, Nigel knows what need to be done to work together,
if he so desires.

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

>  > > Even it were not for this, the whole idea seems misconcieved to me
>  > > anyway.
>  > 
>  > ...but how do you provide nice, graphical progress bar for swsusp
>  > without this? People want that, and "esc to abort", compression,
>  > encryption. Too much to be done in kernel space, IMNSHO.
>  
> I'll take "rootkit doesnt work" over "bells and whistles".

It moves bunch of code from kernelspace to userspace. You don't have
to add bells and whistles at the same time. That's normally called
good thing. If Fedora has special needs, fine.
								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Wed, Nov 16, 2005 at 05:00:45PM +1100, Nigel Cunningham wrote:
> Hi.
> 
> On Wed, 2005-11-16 at 17:14, Greg KH wrote:
> > On Wed, Nov 16, 2005 at 06:35:30AM +0200, Dumitru Ciobarcianu wrote:
> > > ??n data de Mi, 16-11-2005 la 00:32 +0100, Pavel Machek a scris:
> > > > ...but how do you provide nice, graphical progress bar for swsusp
> > > > without this? People want that, and "esc to abort", compression,
> > > > encryption. Too much to be done in kernel space, IMNSHO.
> > > 
> > > Pavel, you really should _listen_ when someone else is talking about the
> > > same things in different implementations. suspend2 has this feature
> > > (nice graphical progress bars in userspace) for a long time now and it's
> > > compatible with the fedora kernels.
> > 
> > It's also implemented in the kernel, which is exactly the wrong place
> > for this.  Pavel is doing this properly, why do you doubt him?
> 
> You yourself called it a hack not long ago.

I did, in the proud tradition of neat hacks.  It's a very nice
accomplishment that this even works, and I'm impressed.

> I'm not sure why you think the userspace is the right place for
> suspending.

If he can come up with an implementation that works, and puts stuff like
the pretty spinning wheels and progress bars and encryption in
userspace, that's great.  That stuff doesn't belong in the kerenel if we
can possibly help it.

> It seems to me that the very fact that it requires access to
> structures that are normally only visible to the kernel is pretty
> telling.

So it needs some work :)

> To be fair, it is true at the same time that graphical interfaces
> don't belong in the kernel - but the vast majority of it - calculating
> what to write and doing the writing does. It's only by hamstringing
> himself and the user - limiting the image to half of memory that Pavel
> (and dropping support for writing to swap) that Pavel can make this
> work.

Then propose a better way to do this, if you can see one.

> > > Why don't you and Nigel (of suspend2) can just work together on this ?
> > > It's a shame that much work is wasted in duplicated effort.
> > 
> > It's not duplicated, Nigel knows what need to be done to work together,
> > if he so desires.
> 
> I know that Pavel and I have such different ideas about what should be
> done that it's not worth the effort.

I'm sorry that you feel this way.  I thought that after our meeting in
July that things were different.

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi Greg.

On Thu, 2005-11-17 at 03:50, Greg KH wrote:
> On Wed, Nov 16, 2005 at 05:00:45PM +1100, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Wed, 2005-11-16 at 17:14, Greg KH wrote:
> > > On Wed, Nov 16, 2005 at 06:35:30AM +0200, Dumitru Ciobarcianu wrote:
> > > > ??n data de Mi, 16-11-2005 la 00:32 +0100, Pavel Machek a scris:
> > > > > ...but how do you provide nice, graphical progress bar for swsusp
> > > > > without this? People want that, and "esc to abort", compression,
> > > > > encryption. Too much to be done in kernel space, IMNSHO.
> > > > 
> > > > Pavel, you really should _listen_ when someone else is talking about the
> > > > same things in different implementations. suspend2 has this feature
> > > > (nice graphical progress bars in userspace) for a long time now and it's
> > > > compatible with the fedora kernels.
> > > 
> > > It's also implemented in the kernel, which is exactly the wrong place
> > > for this.  Pavel is doing this properly, why do you doubt him?
> > 
> > You yourself called it a hack not long ago.
> 
> I did, in the proud tradition of neat hacks.  It's a very nice
> accomplishment that this even works, and I'm impressed.
> 
> > I'm not sure why you think the userspace is the right place for
> > suspending.
> 
> If he can come up with an implementation that works, and puts stuff like
> the pretty spinning wheels and progress bars and encryption in
> userspace, that's great.  That stuff doesn't belong in the kerenel if we
> can possibly help it.

I can agree with putting splash screens and userspace stuff in
userspace. Suspend2 has had that too, since March. But the guts of the
code is a different thing. Encryption - well, I think we're both using
cryptoapi now, so that's more easily done in the kernel.

> > It seems to me that the very fact that it requires access to
> > structures that are normally only visible to the kernel is pretty
> > telling.
> 
> So it needs some work :)

rm :)

> > To be fair, it is true at the same time that graphical interfaces
> > don't belong in the kernel - but the vast majority of it - calculating
> > what to write and doing the writing does. It's only by hamstringing
> > himself and the user - limiting the image to half of memory that Pavel
> > (and dropping support for writing to swap) that Pavel can make this
> > work.
> 
> Then propose a better way to do this, if you can see one.

We've done the user interface in userspace using netlink to
communication.

We've done storing a full image of memory by storing the page cache
separately to the rest of the image, so that it doesn't need to have an
atomic copy made. (Nothing that uses the page cache is running anyway).
Having done this, we can use the memory occupied by the page cache for
our atomic copy, and just reread the overwritten page cache pages if we
need to cancel the suspend. Suspend2 has done this since... beta18 I
think.

> > > > Why don't you and Nigel (of suspend2) can just work together on this ?
> > > > It's a shame that much work is wasted in duplicated effort.
> > > 
> > > It's not duplicated, Nigel knows what need to be done to work together,
> > > if he so desires.
> > 
> > I know that Pavel and I have such different ideas about what should be
> > done that it's not worth the effort.
> 
> I'm sorry that you feel this way.  I thought that after our meeting in
> July that things were different.

I'm sorry you came away with that impression. I want to work together,
but I'm not willing to settle for a minimalist implementation. Pavel, on
the other hand, wanted a minimalist implementation at first. He seems to
be changing his mind a bit now, but I'm not sure how far that will go.

Regards,

Nigel

> thanks,
> 
> greg k-h
-- 

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi

On Thu, 2005-11-17 at 08:35, Pavel Machek wrote:
> Hi, all!
> 
> > > > > It's also implemented in the kernel, which is exactly the wrong place
> > > > > for this.  Pavel is doing this properly, why do you doubt him?
> > > > 
> > > > You yourself called it a hack not long ago.
> > > 
> > > I did, in the proud tradition of neat hacks.  It's a very nice
> > > accomplishment that this even works, and I'm impressed.
> > > 
> > > > I'm not sure why you think the userspace is the right place for
> > > > suspending.
> > > 
> > > If he can come up with an implementation that works, and puts stuff like
> > > the pretty spinning wheels and progress bars and encryption in
> > > userspace, that's great.  That stuff doesn't belong in the kerenel if we
> > > can possibly help it.
> > 
> > I can agree with putting splash screens and userspace stuff in
> > userspace. Suspend2 has had that too, since March. But the guts of
> > the
> 
> Well, I'd say that having to resort to netlink is ... not quite
> nice. You get all the complexity of having userspace running during
> suspend, and get very little benefit.

Mmm, but less complexity than with trying to do the whole suspend from
userspace. (I don't need to export pageflags, bio routines etc or work
around it by using /dev/kmem).

> > code is a different thing. Encryption - well, I think we're both using
> > cryptoapi now, so that's more easily done in the kernel.
> 
> Its not only encryption. It is encryption, compression, support for
> suspend over network, support for suspend into file. That's quite a
> lot of stuff.
> 
> > > Then propose a better way to do this, if you can see one.
> > 
> > We've done the user interface in userspace using netlink to
> > communication.
> > 
> > We've done storing a full image of memory by storing the page cache
> > separately to the rest of the image, so that it doesn't need to have an
> > atomic copy made. (Nothing that uses the page cache is running anyway).
> > Having done this, we can use the memory occupied by the page cache for
> > our atomic copy, and just reread the overwritten page cache pages if we
> > need to cancel the suspend. Suspend2 has done this since... beta18 I
> > think.
> 
> ...at expense of complexity, and hooks all over the kernel. Yes, if
> you modify kernel a bit, nothing will use the page cache.

Could you back your "hooks all over the kernel" statement up? I do have
some BUG_ON()s aimed at double checking that nothing bad happens, but
they never get hit and obviously aren't required to stop processes using
the page cache. All that's really required is to freeze processes.

> Anyway, I believe we have solution for that one. See Rafael's recent
> patches -- "only free as much memory as neccessary" should do the
> trick, without excessive complexity.

That's still imposing a 1/2 of memory limit, though.

> > > > I know that Pavel and I have such different ideas about what should be
> > > > done that it's not worth the effort.
> > > 
> > > I'm sorry that you feel this way.  I thought that after our meeting in
> > > July that things were different.
> > 
> > I'm sorry you came away with that impression. I want to work together,
> > but I'm not willing to settle for a minimalist implementation. Pavel, on
> > the other hand, wanted a minimalist implementation at first. He seems to
> > be changing his mind a bit now, but I'm not sure how far that will go.
> 
> Well, I do not want the complexity of two page sets. I think Rafael's
> patches will provide almost equivalent functionality. Other than that,
> all your features should be doable. I'm not saying I'm going to write
> those patches myself, but I'll certainly not reject them just because
> they are too big.

I'm sorry for making you think that having two pagesets is a complex
issues. I know that when I first did it, I put tight restrictions on
memory usage while the first pageset was written and used a separate
memory pool. Since then, I've realised a far simpler way of handling
this, and the code has been greatly simplified. In essence, all you need
to do is make your I/O code generic enough that it can be passed a list
of pages to write and put page cache pages in a separate list when
figuring out what pages need to be saved. Then you save those pages
before doing your atomic copy of the other pages, and reload them after
restoring the atomic copy at resume time.

Regards,

Nigel

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi, all!

> > > > It's also implemented in the kernel, which is exactly the wrong place
> > > > for this.  Pavel is doing this properly, why do you doubt him?
> > > 
> > > You yourself called it a hack not long ago.
> > 
> > I did, in the proud tradition of neat hacks.  It's a very nice
> > accomplishment that this even works, and I'm impressed.
> > 
> > > I'm not sure why you think the userspace is the right place for
> > > suspending.
> > 
> > If he can come up with an implementation that works, and puts stuff like
> > the pretty spinning wheels and progress bars and encryption in
> > userspace, that's great.  That stuff doesn't belong in the kerenel if we
> > can possibly help it.
> 
> I can agree with putting splash screens and userspace stuff in
> userspace. Suspend2 has had that too, since March. But the guts of
> the

Well, I'd say that having to resort to netlink is ... not quite
nice. You get all the complexity of having userspace running during
suspend, and get very little benefit.

> code is a different thing. Encryption - well, I think we're both using
> cryptoapi now, so that's more easily done in the kernel.

Its not only encryption. It is encryption, compression, support for
suspend over network, support for suspend into file. That's quite a
lot of stuff.

> > Then propose a better way to do this, if you can see one.
> 
> We've done the user interface in userspace using netlink to
> communication.
> 
> We've done storing a full image of memory by storing the page cache
> separately to the rest of the image, so that it doesn't need to have an
> atomic copy made. (Nothing that uses the page cache is running anyway).
> Having done this, we can use the memory occupied by the page cache for
> our atomic copy, and just reread the overwritten page cache pages if we
> need to cancel the suspend. Suspend2 has done this since... beta18 I
> think.

...at expense of complexity, and hooks all over the kernel. Yes, if
you modify kernel a bit, nothing will use the page cache.

Anyway, I believe we have solution for that one. See Rafael's recent
patches -- "only free as much memory as neccessary" should do the
trick, without excessive complexity.

> > > I know that Pavel and I have such different ideas about what should be
> > > done that it's not worth the effort.
> > 
> > I'm sorry that you feel this way.  I thought that after our meeting in
> > July that things were different.
> 
> I'm sorry you came away with that impression. I want to work together,
> but I'm not willing to settle for a minimalist implementation. Pavel, on
> the other hand, wanted a minimalist implementation at first. He seems to
> be changing his mind a bit now, but I'm not sure how far that will go.

Well, I do not want the complexity of two page sets. I think Rafael's
patches will provide almost equivalent functionality. Other than that,
all your features should be doable. I'm not saying I'm going to write
those patches myself, but I'll certainly not reject them just because
they are too big.
								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Rafael J. Wysocki]

Hi,

On Wednesday, 16 of November 2005 00:40, Dave Jones wrote:
> On Wed, Nov 16, 2005 at 12:32:01AM +0100, Pavel Machek wrote:
> 
>  > If this goes in, you can still keep using old method... I'll not
>  > remove it anytime soon.
> 
> Ok.
> 
>  > > Even it were not for this, the whole idea seems misconcieved to me
>  > > anyway.
>  > 
>  > ...but how do you provide nice, graphical progress bar for swsusp
>  > without this? People want that, and "esc to abort", compression,
>  > encryption. Too much to be done in kernel space, IMNSHO.
>  
> I'll take "rootkit doesnt work" over "bells and whistles".
> 
> I think most users actually care more about "works" than
> "looks pretty, and then fails spectacularly".

I've been discussing this with Pavel for quite some time and my opinion is
that moving the image-writing and reading functionality of swsusp
to the user space makes sense from the technical point of view.

For example it would allow us to add the image encryption (real, eg.
with a passphrase-protected key), image compression, and image
verification in a rather straightforward way.  These are important
functionalities, at least for some users.

However, I think we should not try to read and/or set up kernel
data structures from the users space.  Instead, we can create an interface
that will allow us to convey the image data and metadata from the
kernel to the user space and vice versa.

Greetings,
Rafael

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi.

On Thu, 2005-11-17 at 09:47, Pavel Machek wrote:
> Hi!
> 
> > > > I can agree with putting splash screens and userspace stuff in
> > > > userspace. Suspend2 has had that too, since March. But the guts of
> > > > the
> > > 
> > > Well, I'd say that having to resort to netlink is ... not quite
> > > nice. You get all the complexity of having userspace running during
> > > suspend, and get very little benefit.
> > 
> > Mmm, but less complexity than with trying to do the whole suspend from
> > userspace. (I don't need to export pageflags, bio routines etc or work
> > around it by using /dev/kmem).
> 
> Well, userland swsusp has pretty low impact on kernel code -- it adds
> something like 150 lines:
> 
>  drivers/char/mem.c      |   42 +
>  include/linux/suspend.h |   23
>  kernel/power/console.c  |    1
>  kernel/power/disk.c     |   19
>  kernel/power/swsusp.c   |   78 +
>  usr/swsusp-init         |    9
>  8 files changed, 2696 insertions(+), 4 deletions(-)
> 
> i don't think you can do much better than that...
> 
> > > ...at expense of complexity, and hooks all over the kernel. Yes, if
> > > you modify kernel a bit, nothing will use the page cache.
> > 
> > Could you back your "hooks all over the kernel" statement up? I do have
> > some BUG_ON()s aimed at double checking that nothing bad happens, but
> > they never get hit and obviously aren't required to stop processes using
> > the page cache. All that's really required is to freeze processes.
> 
> Are you willing to merge the code without BUG_ONs?

Yes.

> > > Anyway, I believe we have solution for that one. See Rafael's recent
> > > patches -- "only free as much memory as neccessary" should do the
> > > trick, without excessive complexity.
> > 
> > That's still imposing a 1/2 of memory limit, though.
> 
> Yes, hopefully users will not notice.

Users with more memory probably won't care so much, depending on what
apps they want to run and how responsive they want the system to be
post-resume.

> > > Well, I do not want the complexity of two page sets. I think Rafael's
> > > patches will provide almost equivalent functionality. Other than that,
> > > all your features should be doable. I'm not saying I'm going to write
> > > those patches myself, but I'll certainly not reject them just because
> > > they are too big.
> > 
> > I'm sorry for making you think that having two pagesets is a complex
> > issues. I know that when I first did it, I put tight restrictions on
> > memory usage while the first pageset was written and used a separate
> > memory pool. Since then, I've realised a far simpler way of handling
> > this, and the code has been greatly simplified. In essence, all you need
> > to do is make your I/O code generic enough that it can be passed a list
> > of pages to write and put page cache pages in a separate list when
> > figuring out what pages need to be saved. Then you save those pages
> > before doing your atomic copy of the other pages, and reload them after
> > restoring the atomic copy at resume time.
> 
> Okay, it may have gotten better. Anyway, this is the only part that
> really needs to be in-kernel. Saving 50% of memory is still going to
> produce *way* more responsive system than "save as little as
> possible", and I hope it will be good enough.

I agree about the 'way more responsive system'. Good enough will depend
on the user and which way the wind is blowing at the time. I guess if
that's the only option they have, it's still better than rebooting.

Regards,

Nigel

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > > I can agree with putting splash screens and userspace stuff in
> > > userspace. Suspend2 has had that too, since March. But the guts of
> > > the
> > 
> > Well, I'd say that having to resort to netlink is ... not quite
> > nice. You get all the complexity of having userspace running during
> > suspend, and get very little benefit.
> 
> Mmm, but less complexity than with trying to do the whole suspend from
> userspace. (I don't need to export pageflags, bio routines etc or work
> around it by using /dev/kmem).

Well, userland swsusp has pretty low impact on kernel code -- it adds
something like 150 lines:

 drivers/char/mem.c      |   42 +
 include/linux/suspend.h |   23
 kernel/power/console.c  |    1
 kernel/power/disk.c     |   19
 kernel/power/swsusp.c   |   78 +
 usr/swsusp-init         |    9
 8 files changed, 2696 insertions(+), 4 deletions(-)

i don't think you can do much better than that...

> > ...at expense of complexity, and hooks all over the kernel. Yes, if
> > you modify kernel a bit, nothing will use the page cache.
> 
> Could you back your "hooks all over the kernel" statement up? I do have
> some BUG_ON()s aimed at double checking that nothing bad happens, but
> they never get hit and obviously aren't required to stop processes using
> the page cache. All that's really required is to freeze processes.

Are you willing to merge the code without BUG_ONs?

> > Anyway, I believe we have solution for that one. See Rafael's recent
> > patches -- "only free as much memory as neccessary" should do the
> > trick, without excessive complexity.
> 
> That's still imposing a 1/2 of memory limit, though.

Yes, hopefully users will not notice.

> > Well, I do not want the complexity of two page sets. I think Rafael's
> > patches will provide almost equivalent functionality. Other than that,
> > all your features should be doable. I'm not saying I'm going to write
> > those patches myself, but I'll certainly not reject them just because
> > they are too big.
> 
> I'm sorry for making you think that having two pagesets is a complex
> issues. I know that when I first did it, I put tight restrictions on
> memory usage while the first pageset was written and used a separate
> memory pool. Since then, I've realised a far simpler way of handling
> this, and the code has been greatly simplified. In essence, all you need
> to do is make your I/O code generic enough that it can be passed a list
> of pages to write and put page cache pages in a separate list when
> figuring out what pages need to be saved. Then you save those pages
> before doing your atomic copy of the other pages, and reload them after
> restoring the atomic copy at resume time.

Okay, it may have gotten better. Anyway, this is the only part that
really needs to be in-kernel. Saving 50% of memory is still going to
produce *way* more responsive system than "save as little as
possible", and I hope it will be good enough.
								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Alan Cox]

On Maw, 2005-11-15 at 17:25 -0500, Dave Jones wrote:
> Just for info: If this goes in, Red Hat/Fedora kernels will fork
> swsusp development, as this method just will not work there.
> (We have a restricted /dev/mem that prevents writes to arbitary
>  memory regions, as part of a patchset to prevent rootkits)

Perhaps it is trying to tell you that you should be using SELinux rules
not kernel hacks for this purpose ?

> Even it were not for this, the whole idea seems misconcieved to me
> anyway.

I'm sceptical too but several Win9x BIOS vendor suspend paths were
implemented in roughly this way. I don't however see how you can
co-ordinate the freeze with outstanding O_DIRECT DMA to user pages for
one item.

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Fri, Nov 18, 2005 at 07:36:29PM +0000, Alan Cox wrote:
 > On Maw, 2005-11-15 at 17:25 -0500, Dave Jones wrote:
 > > Just for info: If this goes in, Red Hat/Fedora kernels will fork
 > > swsusp development, as this method just will not work there.
 > > (We have a restricted /dev/mem that prevents writes to arbitary
 > >  memory regions, as part of a patchset to prevent rootkits)
 > 
 > Perhaps it is trying to tell you that you should be using SELinux rules
 > not kernel hacks for this purpose ?

I don't think selinux can give you the granularity to say
"process can access this bit of the file only", at least not yet.

Even if that was capable however, it still doesn't solve the problem.
Pavel's implementation wants to write to arbitary address spaces, which is
what we're trying to prevent. The two are at odds with each other.

		Dave

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Fri, Nov 18, 2005 at 04:18:47PM -0500, Dave Jones wrote:
> Even if that was capable however, it still doesn't solve the problem.
> Pavel's implementation wants to write to arbitary address spaces, which is
> what we're trying to prevent. The two are at odds with each other.

I agree, he needs to find a different way to get that information into
and out of the kernel than that device node for it to be accepted into
mainline.  But for now, it's a nice way to mock up the fuctionality
needed.

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Arjan van de Ven]

On Fri, 2005-11-18 at 19:36 +0000, Alan Cox wrote:
> On Maw, 2005-11-15 at 17:25 -0500, Dave Jones wrote:
> > Just for info: If this goes in, Red Hat/Fedora kernels will fork
> > swsusp development, as this method just will not work there.
> > (We have a restricted /dev/mem that prevents writes to arbitary
> >  memory regions, as part of a patchset to prevent rootkits)
> 
> Perhaps it is trying to tell you that you should be using SELinux rules
> not kernel hacks for this purpose ?

actually no. SELinux can't work, we've looked at that bigtime. Basically
/dev/mem has 3 types in one, and to apply security you need different
roles for each in selinux. so the only option to apply selinux
*anything* is to first split /dev/mem up.

types:
1) accessing non-ram memory (eg PCI mmio space) by X and the likes
   (ideally should use sysfs but hey, changing X for this will take 
   forever)
2) accessing bios memory in the lower 1Gb for various emulation like
   purposes (including vbetool and X mode setting)
3) accessing things the kernel sees as RAM

they are very distinct security wise.

Re: [linux-pm] [RFC] userland swsusp

[Alan Cox]

On Gwe, 2005-11-18 at 22:23 +0100, Arjan van de Ven wrote:
> 1) accessing non-ram memory (eg PCI mmio space) by X and the likes
>    (ideally should use sysfs but hey, changing X for this will take 
>    forever)

Once sysfs supports the relevant capabilities fixing X actually doesn't
look too horrible, the PCI mapping routines are abstracted and done by
PCITAG (ie PCI device). You would need the ISA hole too in some cases.

> 2) accessing bios memory in the lower 1Gb for various emulation like
>    purposes (including vbetool and X mode setting)
> 3) accessing things the kernel sees as RAM
> 
> they are very distinct security wise.

Agreed.

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > Even it were not for this, the whole idea seems misconcieved to me
> > anyway.
> 
> I'm sceptical too but several Win9x BIOS vendor suspend paths were
> implemented in roughly this way. I don't however see how you can
> co-ordinate the freeze with outstanding O_DIRECT DMA to user pages for
> one item.

I do not see a problem. swsusp process stops all other processes, freezes
the drivers, then asks for system snapshot. It certainly does *not* ask for
O_DIRECT........

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [linux-pm] [RFC] userland swsusp

[Jesse Barnes]

On Friday, November 18, 2005 2:07 pm, Alan Cox wrote:
> On Gwe, 2005-11-18 at 22:23 +0100, Arjan van de Ven wrote:
> > 1) accessing non-ram memory (eg PCI mmio space) by X and the likes
> >    (ideally should use sysfs but hey, changing X for this will take
> >    forever)
>
> Once sysfs supports the relevant capabilities fixing X actually
> doesn't look too horrible, the PCI mapping routines are abstracted
> and done by PCITAG (ie PCI device). You would need the ISA hole too
> in some cases.

It's actually partly done already (at least for ia64, but the code I put 
together works on x86 too, iirc, and should work elsewhere).  The ISA 
stuff is exported on a per-bus basis in legacy_io and legacy_mem files.

If vbetool and friends want to get at the ROM, they can use the sysfs 
rom file like everyone else.  There are problems with this however, on 
systems where the ROM is unpacked at 0xc0000 or something, especially 
if the unpacked version is modified by the BIOS at startup time, not 
sure how to address that reliably.

Jesse

Re: [linux-pm] [RFC] userland swsusp

[Arjan van de Ven]

On Fri, 2005-11-18 at 22:07 +0000, Alan Cox wrote:
> On Gwe, 2005-11-18 at 22:23 +0100, Arjan van de Ven wrote:
> > 1) accessing non-ram memory (eg PCI mmio space) by X and the likes
> >    (ideally should use sysfs but hey, changing X for this will take 
> >    forever)
> 
> Once sysfs supports the relevant capabilities fixing X actually doesn't
> look too horrible

I think the kernel already supports this since at least july if not
earlier. If there's something missing... someone needs to speak up..

(yes vga arbitrage is missing but well that's not there today by any
means either so not a regression)

> , the PCI mapping routines are abstracted and done by
> PCITAG (ie PCI device). You would need the ISA hole too in some cases.

this may need /dev/mem a bit longer, but hopefully is rarer. Once the
pci side is fixed I bet this only is easy to do as well

Re: [linux-pm] [RFC] userland swsusp

[Rob Landley]

On Wednesday 16 November 2005 00:00, Nigel Cunningham wrote:
> > It's not duplicated, Nigel knows what need to be done to work together,
> > if he so desires.
>
> I know that Pavel and I have such different ideas about what should be
> done that it's not worth the effort.

So first it was Pavel and Patrick Mochel...

Then Pavel and Nigel...

Recently Dave Jones rumbled about a suspend fork...

You sure you software suspend guys haven't been hanging out with the IDE 
maintainers?

Rob

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

>  > > Just for info: If this goes in, Red Hat/Fedora kernels will fork
>  > > swsusp development, as this method just will not work there.
>  > > (We have a restricted /dev/mem that prevents writes to arbitary
>  > >  memory regions, as part of a patchset to prevent rootkits)
>  > 
>  > Perhaps it is trying to tell you that you should be using SELinux rules
>  > not kernel hacks for this purpose ?
> 
> I don't think selinux can give you the granularity to say
> "process can access this bit of the file only", at least not yet.
> 
> Even if that was capable however, it still doesn't solve the problem.
> Pavel's implementation wants to write to arbitary address spaces, which is
> what we're trying to prevent. The two are at odds with each other.

I do not think thats a security problem. By definition, suspending code
can change arbitrary things in memory -- it could just write image with
changes it desires, then resume from it. Whether this code is in kernel
or not, it has to be trusted.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > > It's not duplicated, Nigel knows what need to be done to work together,
> > > if he so desires.
> >
> > I know that Pavel and I have such different ideas about what should be
> > done that it's not worth the effort.
> 
> So first it was Pavel and Patrick Mochel...
> 
> Then Pavel and Nigel...
> 
> Recently Dave Jones rumbled about a suspend fork...

Pavel and Patrick is solved, and there's no Pavel and Nigel... Its just Pavel
vs. way too much code. See my reply to Dave.

> You sure you software suspend guys haven't been hanging out with the IDE 
> maintainers?

:-)

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Sat, Nov 19, 2005 at 11:43:32PM +0000, Pavel Machek wrote:
 > Hi!
 > 
 > >  > > Just for info: If this goes in, Red Hat/Fedora kernels will fork
 > >  > > swsusp development, as this method just will not work there.
 > >  > > (We have a restricted /dev/mem that prevents writes to arbitary
 > >  > >  memory regions, as part of a patchset to prevent rootkits)
 > >  > 
 > >  > Perhaps it is trying to tell you that you should be using SELinux rules
 > >  > not kernel hacks for this purpose ?
 > > 
 > > I don't think selinux can give you the granularity to say
 > > "process can access this bit of the file only", at least not yet.
 > > 
 > > Even if that was capable however, it still doesn't solve the problem.
 > > Pavel's implementation wants to write to arbitary address spaces, which is
 > > what we're trying to prevent. The two are at odds with each other.
 > 
 > I do not think thats a security problem. By definition, suspending code
 > can change arbitrary things in memory -- it could just write image with
 > changes it desires, then resume from it. Whether this code is in kernel
 > or not, it has to be trusted.

Stop thinking about the suspend usage case for a minute.

With your proposed changes, an attacker can scribble over random
bits of /dev/mem without suspending in order to do whatever he wants.

With what we have in-kernel, and a restricted /dev/mem, achieving the
attack you mention is a lot less feasible, as the attacker has no access
to the memory being written out to the suspend partition, even as root.
Even if they did, people tend to notice boxes shutting down pretty quickly
making this a not-very-stealthy attack.

		Dave

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

>  > >  > > Just for info: If this goes in, Red Hat/Fedora kernels will fork
>  > >  > > swsusp development, as this method just will not work there.
>  > >  > > (We have a restricted /dev/mem that prevents writes to arbitary
>  > >  > >  memory regions, as part of a patchset to prevent rootkits)
>  > >  > 
>  > >  > Perhaps it is trying to tell you that you should be using SELinux rules
>  > >  > not kernel hacks for this purpose ?
>  > > 
>  > > I don't think selinux can give you the granularity to say
>  > > "process can access this bit of the file only", at least not yet.
>  > > 
>  > > Even if that was capable however, it still doesn't solve the problem.
>  > > Pavel's implementation wants to write to arbitary address spaces, which is
>  > > what we're trying to prevent. The two are at odds with each other.
>  > 
>  > I do not think thats a security problem. By definition, suspending code
>  > can change arbitrary things in memory -- it could just write image with
>  > changes it desires, then resume from it. Whether this code is in kernel
>  > or not, it has to be trusted.
> 
> Stop thinking about the suspend usage case for a minute.
> 
> With your proposed changes, an attacker can scribble over random
> bits of /dev/mem without suspending in order to do whatever he
> wants.

Well, without my changes, an attacker can scribble over random bits of
memory, too; I was not the one that introduced /dev/mem :-).

> With what we have in-kernel, and a restricted /dev/mem, achieving the
> attack you mention is a lot less feasible, as the attacker has no access
> to the memory being written out to the suspend partition, even as root.
> Even if they did, people tend to notice boxes shutting down pretty quickly
> making this a not-very-stealthy attack.

Can I read somewhere about security model you are using? Would it be
enough to restrict /dev/[k]mem to those people that have right to
update kernel anyway? Or your approach is "noone, absolutely noone has
right to modify running kernel"? [Do you still use loadable modules?]

								Pavel

-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Rafael J. Wysocki]

Hi,

On Sunday, 20 of November 2005 23:09, Pavel Machek wrote:
}-- snip --{ 
> > With what we have in-kernel, and a restricted /dev/mem, achieving the
> > attack you mention is a lot less feasible, as the attacker has no access
> > to the memory being written out to the suspend partition, even as root.
> > Even if they did, people tend to notice boxes shutting down pretty quickly
> > making this a not-very-stealthy attack.
> 
> Can I read somewhere about security model you are using? Would it be
> enough to restrict /dev/[k]mem to those people that have right to
> update kernel anyway? Or your approach is "noone, absolutely noone has
> right to modify running kernel"? [Do you still use loadable modules?]

The problem is that, whatever the security model, if you have access to the
kernel memory (eg. via /dev/kmem), you can modify the security rules
themselves, so this should better be avoided.

Apart from this, IMO, if it's necessary to access the kernel memory directly
from a userland process, this means that the process' functionality really
belongs to the kernel.  Consequently, the code in swsusp that needs
to access the kernel memory should stay in the kernel, and the rest
can go to the userland.

Greetings,
Rafael

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > > With what we have in-kernel, and a restricted /dev/mem, achieving the
> > > attack you mention is a lot less feasible, as the attacker has no access
> > > to the memory being written out to the suspend partition, even as root.
> > > Even if they did, people tend to notice boxes shutting down pretty quickly
> > > making this a not-very-stealthy attack.
> > 
> > Can I read somewhere about security model you are using? Would it be
> > enough to restrict /dev/[k]mem to those people that have right to
> > update kernel anyway? Or your approach is "noone, absolutely noone has
> > right to modify running kernel"? [Do you still use loadable modules?]
> 
> The problem is that, whatever the security model, if you have access to the
> kernel memory (eg. via /dev/kmem), you can modify the security rules
> themselves, so this should better be avoided.

Well, under current linux security model, root has all permissions,
including inserting modifying running kernel, touching hardware
directly, and installing rootkits. Fedora may be trying to change
that... but if so, I'd like to know what they are planning.
								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Lorenzo Colitti]

Pavel Machek wrote:
> Yes, hopefully users will not notice.

? So the idea is to merge inferior code and "hope users won't notice"?

Users  might not notice that half their memory is gone, but they *will* 
notice that their system is dog slow when it resumes because all their 
caches are gone and a most of their stuff is swapped out.

Non-responsive system on resume is one of the main reasons that swsusp2 
is much better than swsusp1, and yes, users *do* notice (I was one of 
them, as I pointed out a while back). Yes, 50% is better than nothing, 
but it's still a pretty poor show.

Seen from the perspective of a user, the situation is simple: suspend2 
works, it's fast, and it's rock-solid. Just use it.


Regards,
Lorenzo

P.S. Don't "show me the code" me. I can't write the code. :-) But based 
on what I see of how well suspend2 works, I think Nigel can...

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

On St 23-11-05 11:16:27, Lorenzo Colitti wrote:
> Pavel Machek wrote:
> >Yes, hopefully users will not notice.
> 
> ? So the idea is to merge inferior code and "hope users won't notice"?
> 
> Users  might not notice that half their memory is gone, but they *will* 
> notice that their system is dog slow when it resumes because all their 
> caches are gone and a most of their stuff is swapped out.
> 
> Non-responsive system on resume is one of the main reasons that swsusp2 
> is much better than swsusp1, and yes, users *do* notice (I was one of 
> them, as I pointed out a while back). Yes, 50% is better than nothing, 
> but it's still a pretty poor show.

Did you actually benchmark it?

> Seen from the perspective of a user, the situation is simple: suspend2 
> works, it's fast, and it's rock-solid. Just use it.

About as helpful as "Windows XP works, it's fast, and it's
rock-solid".

							Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > What unstable implementation? swsusp had very little regressions over past
> > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> 
> Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> suspend-to-disk or both?

Read the docs. swsusp is suspend-to-disk, of course.

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [linux-pm] [RFC] userland swsusp

[Jacek Kawa]

Greg KH wrote;

> > > > > What unstable implementation? swsusp had very little regressions over past
> > > > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > > > Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> > > > suspend-to-disk or both?
> > > Both.  -to-ram depends on your video chip, but to-disk should work just
> > > fine.  If not, please report bugs.
> > Thanks, I've just realized, that I probably forgot to CC anyone last time... 
> > :)
> > So, may I kindly ask to look on:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?
> Care to file this in bugzilla.kernel.org and assign it to Pavel?

Sure :)

http://bugzilla.kernel.org/show_bug.cgi?id=5626

Thanks


-- 
Jacek Kawa

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Thu, Nov 17, 2005 at 09:15:09PM +0100, Jacek Kawa wrote:
> Greg KH wrote:
> 
> > > > What unstable implementation? swsusp had very little regressions over past
> > > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > > Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> > > suspend-to-disk or both?
> > Both.  -to-ram depends on your video chip, but to-disk should work just
> > fine.  If not, please report bugs.
> 
> Thanks, I've just realized, that I probably forgot to CC anyone last time... 
> :)
> 
> So, may I kindly ask to look on:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?

Care to file this in bugzilla.kernel.org and assign it to Pavel?

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Diego Calleja]

El Thu, 17 Nov 2005 13:18:56 -0800,
Chris Wright <chrisw@osdl.org> escribió:

> Yeah, bad bug reports are indeed a pain.  One thing that may help ALSA is
> more frequent merging with mainline.  Then the delta between ALSA cvs
> (and hence ALSA developers) and mainline (users) is smaller.

What about using kernel's bugzilla? Alsa has a (weird) bug tracker but
some people reports bugs in bugzilla.kernel.org aswell (just a suggestion,
it seems weird to have two places to report bugs and I bet that's not good
for users)

Re: [linux-pm] [RFC] userland swsusp

[Chris Wright]

* Lee Revell (rlrevell@joe-job.com) wrote:
> OK I should not single out Red Hat or OSDL, it just seems like we get a
> lot more general gripes about ALSA regressions than we see good bug
> reports.  All I am saying is that maybe someone from a distro with
> access to bug reports from a huge user base has some ideas for how we
> could better deal with these regressions.  The ALSA project does not get
> many good bug reports because we are farther from the users.

Yeah, bad bug reports are indeed a pain.  One thing that may help ALSA is
more frequent merging with mainline.  Then the delta between ALSA cvs
(and hence ALSA developers) and mainline (users) is smaller.

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 21:09 +0000, Matthew Garrett wrote:
> Dave Jones <davej@redhat.com> wrote:
> 
> > I don't know about other distros, but here's how that usually goes for Fedora users..
> 
> It Works in Ubuntu(TM)[0]. More seriously: recent alsa-libs should
> provide a pile of stuff in /usr/share/alsa/cards which switches dmix on
> by default in most cards[1]. Obviously, for this to work usefully, your
> application needs to be using libalsa (either natively or using the aoss
> wrapper).
> 
> [0] The only patch is to enable symbol versioning
> [1] Not ones with hardware mixing

[1] is already done for most of the hardware that needs it.  No user
configuration at all should be required.  Please, let us know if you
find a device it does not work that way for.

Lee

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 13:06 -0800, Chris Wright wrote:
> * Lee Revell (rlrevell@joe-job.com) wrote:
> > On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> > > (Although every release we seem to trade one set of
> > >  working sound drivers for a new set of broken ones). 
> > 
> > Because the ALSA project does not have access to the wide variety of
> > hardware required to regression test every sound driver change.  People
> > like Red Hat and OSDL do, but they don't help.  I always figured that
> > this was because those entities consider audio support a low priority.
> 
> Haven't seen these heaps of audio hardware yet.  It's not an audio only
> issue, it's pervasive across many device classes.  And hardware alone is
> not quite sufficient.  Need ability to automate testing as well.
> 

OK I should not single out Red Hat or OSDL, it just seems like we get a
lot more general gripes about ALSA regressions than we see good bug
reports.  All I am saying is that maybe someone from a distro with
access to bug reports from a huge user base has some ideas for how we
could better deal with these regressions.  The ALSA project does not get
many good bug reports because we are farther from the users.

Lee

Re: [linux-pm] [RFC] userland swsusp

[Matthew Garrett]

Dave Jones <davej@redhat.com> wrote:

> I don't know about other distros, but here's how that usually goes for Fedora users..

It Works in Ubuntu(TM)[0]. More seriously: recent alsa-libs should
provide a pile of stuff in /usr/share/alsa/cards which switches dmix on
by default in most cards[1]. Obviously, for this to work usefully, your
application needs to be using libalsa (either natively or using the aoss
wrapper).

[0] The only patch is to enable symbol versioning
[1] Not ones with hardware mixing
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: [linux-pm] [RFC] userland swsusp

[Chris Wright]

* Lee Revell (rlrevell@joe-job.com) wrote:
> On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> > (Although every release we seem to trade one set of
> >  working sound drivers for a new set of broken ones). 
> 
> Because the ALSA project does not have access to the wide variety of
> hardware required to regression test every sound driver change.  People
> like Red Hat and OSDL do, but they don't help.  I always figured that
> this was because those entities consider audio support a low priority.

Haven't seen these heaps of audio hardware yet.  It's not an audio only
issue, it's pervasive across many device classes.  And hardware alone is
not quite sufficient.  Need ability to automate testing as well.

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Thu, Nov 17, 2005 at 03:54:11PM -0500, Lee Revell wrote:
 > On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
 > > (Although every release we seem to trade one set of
 > >  working sound drivers for a new set of broken ones). 
 > 
 > Because the ALSA project does not have access to the wide variety of
 > hardware required to regression test every sound driver change.  People
 > like Red Hat and OSDL do, but they don't help.

Maybe you could let me know where we keep all that hardware ?
I'd really like to know, and you seem more informed on what
Red Hat have/do than I am.

Perhaps you could tell the OSDL people too.

Thanks,

		Dave

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Thu, Nov 17, 2005 at 03:46:07PM -0500, Lee Revell wrote:

 > The process would work a lot faster if the Fedora project would
 > contribute anything at all to ALSA development.  It's a lot of work!  I
 > haven't seen a line of sound driver code from anyone at Red Hat since
 > the OSS->ALSA transition, years ago.

Sorry, but that's complete uninformed bullshit.
 
		Dave

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> (Although every release we seem to trade one set of
>  working sound drivers for a new set of broken ones). 

Because the ALSA project does not have access to the wide variety of
hardware required to regression test every sound driver change.  People
like Red Hat and OSDL do, but they don't help.  I always figured that
this was because those entities consider audio support a low priority.

Lee

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> You call that great?  Multiple audio streams is such a basic feature
> it should work, period.  No if, no buts, and no obligatory library.
> Which doesn't preclude having it in userspace, mind you.  But it
> should never have been the _application_'s responsability.

Um, it really belongs in HARDWARE like it used to be, but vendors are
way too cheap for that now.  Keep in mind the whole mixing discussion
amounts to "how do we deal with these broken devices".

Lee

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 15:37 -0500, Dave Jones wrote:
> I don't know about other distros, but here's how that usually goes for Fedora users..
> 
> 1. user installs new release, and sound doesn't work.
> 2. user blames ALSA, bug gets filed against kernel.
> 3. I take a look, sometimes we get to play "ping pong the bug between
>    userspace & kernel component" for a while
> 4. I throw my hands in the air and say "tell the upstream ALSA developers"
> 5. user does so
> 6. user comes back to Fedora bugzilla with the response
>    "Alsa people told me its a Fedora bug".
> 
> So, given we ship unpatched[1] ALSA, my faith in the
> possibility of ALSA working "OOTB" is somewhat lacking.
> 
> These bugs usually sit in our bugzilla, every so often
> I'll ping them after I've rebased to a new release, and
> surprise surprise, they magically get fixed.
> (Although every release we seem to trade one set of
>  working sound drivers for a new set of broken ones).

The process would work a lot faster if the Fedora project would
contribute anything at all to ALSA development.  It's a lot of work!  I
haven't seen a line of sound driver code from anyone at Red Hat since
the OSS->ALSA transition, years ago.  Meanwhile the vendors keep getting
cheaper and cheaper, which means more functionality that used to be in
hardware has to be done in the drivers.

For example the Debian people are very helpful, they have someone who
filters out the real bug reports from their users and pushes them into
the ALSA bug tracker.  Fedora just points clueless users at the ALSA bug
tracker and tells them "good luck".

Lee

Re: [linux-pm] [RFC] userland swsusp

[Dave Jones]

On Thu, Nov 17, 2005 at 03:20:55PM -0500, Lee Revell wrote:
 > On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
 > > On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
 > > > On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
 > > > > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
 > > > > > Now... if something can be
 > > > > > done in userspace, it probably should.
 > > > > 
 > > > > And that usually means it just isn't done.  Cases in point:
 > > > > multichannel audio software mixing, video pixel formats conversion.
 > > > 
 > > > What are you talking about?  ALSA does mixing in userspace, it works
 > > > great.
 > > 
 > > You have an interesting definition of "great".
 > > 
 > > 1- It doesn't work without an annoyingly complex, extremely badly
 > >    documented user configuration. To the point that it doesn't work in
 > >    either an out-of-the-box, updated Fedora Core 3 nor an
 > >    out-of-the-box gentoo.
 > 
 > File a bug report with your distro then.  This is supposed to work OOTB.

I don't know about other distros, but here's how that usually goes for Fedora users..

1. user installs new release, and sound doesn't work.
2. user blames ALSA, bug gets filed against kernel.
3. I take a look, sometimes we get to play "ping pong the bug between
   userspace & kernel component" for a while
4. I throw my hands in the air and say "tell the upstream ALSA developers"
5. user does so
6. user comes back to Fedora bugzilla with the response
   "Alsa people told me its a Fedora bug".

So, given we ship unpatched[1] ALSA, my faith in the
possibility of ALSA working "OOTB" is somewhat lacking.

These bugs usually sit in our bugzilla, every so often
I'll ping them after I've rebased to a new release, and
surprise surprise, they magically get fixed.
(Although every release we seem to trade one set of
 working sound drivers for a new set of broken ones).


Colour me jaded.

		Dave

[1] kernel sound/ is unpatched.  alsa-utils is unpatched. alsa-lib carries
one patch from alsa cvs.

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 21:12 +0100, Olivier Galibert wrote:
> On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
> > On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> > > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > > > Now... if something can be
> > > > done in userspace, it probably should.
> > > 
> > > And that usually means it just isn't done.  Cases in point:
> > > multichannel audio software mixing, video pixel formats conversion.
> > 
> > What are you talking about?  ALSA does mixing in userspace, it works
> > great.
> 
> You have an interesting definition of "great".
> 
> 1- It doesn't work without an annoyingly complex, extremely badly
>    documented user configuration. To the point that it doesn't work in
>    either an out-of-the-box, updated Fedora Core 3 nor an
>    out-of-the-box gentoo.
> 

File a bug report with your distro then.  This is supposed to work OOTB.

> 2- It doesn't work for programs that do not use the annoyingly complex
>    and horribly documented alsa library, which includes everything
>    that still uses OSS[1].
> 

There's plenty of ALSA documentation.  Anyway mixing for OSS apps does
work, they just have to use the aoss wrapper.

Lee

Re: [linux-pm] [RFC] userland swsusp

[Jacek Kawa]

Greg KH wrote:

> > > What unstable implementation? swsusp had very little regressions over past
> > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> > Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> > suspend-to-disk or both?
> Both.  -to-ram depends on your video chip, but to-disk should work just
> fine.  If not, please report bugs.

Thanks, I've just realized, that I probably forgot to CC anyone last time... 
:)

So, may I kindly ask to look on:
http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/1863.html ?

Thanks!

-- 
Jacek Kawa

Re: [linux-pm] [RFC] userland swsusp

[Olivier Galibert]

On Thu, Nov 17, 2005 at 02:57:11PM -0500, Lee Revell wrote:
> On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> > On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > > Now... if something can be
> > > done in userspace, it probably should.
> > 
> > And that usually means it just isn't done.  Cases in point:
> > multichannel audio software mixing, video pixel formats conversion.
> 
> What are you talking about?  ALSA does mixing in userspace, it works
> great.

You have an interesting definition of "great".

1- It doesn't work without an annoyingly complex, extremely badly
   documented user configuration. To the point that it doesn't work in
   either an out-of-the-box, updated Fedora Core 3 nor an
   out-of-the-box gentoo.

2- It doesn't work for programs that do not use the annoyingly complex
   and horribly documented alsa library, which includes everything
   that still uses OSS[1].

You call that great?  Multiple audio streams is such a basic feature
it should work, period.  No if, no buts, and no obligatory library.
Which doesn't preclude having it in userspace, mind you.  But it
should never have been the _application_'s responsability.

  OG.

[1] Which is so easier to use for normal programs' audio it's not
    funny.

Re: [linux-pm] [RFC] userland swsusp

[Lee Revell]

On Thu, 2005-11-17 at 18:02 +0100, Olivier Galibert wrote:
> On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> > Now... if something can be
> > done in userspace, it probably should.
> 
> And that usually means it just isn't done.  Cases in point:
> multichannel audio software mixing, video pixel formats conversion.

What are you talking about?  ALSA does mixing in userspace, it works
great.

Lee

RE: [linux-pm] [RFC] userland swsusp

[Starikovskiy, Alexey Y]

 

>-----Original Message-----
>Is the acpi problem with PWRF used over PWRC and PWRF not sending
>events (hence no wakeup) solved?
It should be, look at #1920 in bugzilla.kernel.org

Re: [linux-pm] [RFC] userland swsusp

[Olivier Galibert]

On Thu, Nov 17, 2005 at 08:44:51AM -0800, Greg KH wrote:
> Both.  -to-ram depends on your video chip,

i855GM with xorg-6.8.2 (-r6 gentoo) ?

i830CGC with xorg-6.8.2 (-r4 gentoo) ?


> but to-disk should work just fine.

Ok.

> If not, please report bugs.

I shall.

Is the acpi problem with PWRF used over PWRC and PWRF not sending
events (hence no wakeup) solved?

  OG.

Re: [linux-pm] [RFC] userland swsusp

[Patrick Mochel]

On Thu, 17 Nov 2005, Greg KH wrote:

> On Thu, Nov 17, 2005 at 05:54:37PM +0100, Olivier Galibert wrote:
> > On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> > > What unstable implementation? swsusp had very little regressions over past
> > > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> >
> > Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> > suspend-to-disk or both?
>
> Both.  -to-ram depends on your video chip, but to-disk should work just
> fine.  If not, please report bugs.

swsusp has nothing to do with suspend-to-ram. swsusp is a
platform-independent implementation of suspend-to-disk. STR is
very-platform dependent. Please see the file:

	Documentation/power/states.txt

for more info.


	Pat

Re: [linux-pm] [RFC] userland swsusp

[Olivier Galibert]

On Wed, Nov 16, 2005 at 11:05:00PM +0100, Pavel Machek wrote:
> Now... if something can be
> done in userspace, it probably should.

And that usually means it just isn't done.  Cases in point:
multichannel audio software mixing, video pixel formats conversion.

  OG.

Re: [linux-pm] [RFC] userland swsusp

[Olivier Galibert]

On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> What unstable implementation? swsusp had very little regressions over past
> year or so. Drivers were different story, but nothing changes w.r.t. drivers.

Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
suspend-to-disk or both?

  OG.

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Thu, Nov 17, 2005 at 05:54:37PM +0100, Olivier Galibert wrote:
> On Wed, Nov 16, 2005 at 07:10:52PM +0000, Pavel Machek wrote:
> > What unstable implementation? swsusp had very little regressions over past
> > year or so. Drivers were different story, but nothing changes w.r.t. drivers.
> 
> Do you mean swsusp is actually supposed to work?  Suspend-to-ram,
> suspend-to-disk or both?

Both.  -to-ram depends on your video chip, but to-disk should work just
fine.  If not, please report bugs.

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Arjan van de Ven]

On Thu, 2005-11-17 at 08:25 +1100, Nigel Cunningham wrote:
> Hi.
> 
> On Thu, 2005-11-17 at 09:10, Greg KH wrote:
> > On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
> > > 
> > > I've also split the one patch that most people see into what is
> > > currently about 225 smaller patches, each adding only one small part, am
> > > writing descriptions for them all and am preparing to build a git tree
> > > from it.
> > 
> > That's great, I didn't know you were doing this.
> > 
> > I'd recommend using quilt instead of git for something like this,
> > because the odds that you will need to change something in patch number
> > 132 out of 225 is pretty good :)
> 
> Yeah. :) I actually wrote my own 'makepatch' script long before I ever
> heard of quilt, and am still using that. It lets me do the same sort of
> thing. Unfortunately I tend to accumulate further changes at the end of
> the series and then have to shift them back into the right place. It
> would be nice to be able to automate that :)

patch-utils have a 'movepatch' option... which flips 2 patches in order,
even when they overlap.

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > > I've also split the one patch that most people see into what is
> > > currently about 225 smaller patches, each adding only one small part, am
> > > writing descriptions for them all and am preparing to build a git tree
> > > from it.
> > 
> > I'm not sure that gets suspend2 any closer to merging. 225 small
> > patches is still awful lot of code :-(. Now... if something can be
> > done in userspace, it probably should. And I'm trying to show that
> > suspend2 functionality can indeed be done in userspace.
> > 
> > So... to get 225 patches in, you'll need to explain that
> > userland-swsusp can't work. If you can do that, please be nice and do
> > it soon, so that I don't waste too much time on userland-swsusp.
> 
> I thought Dave already did that.

No, I do not think so. He did not like the user<->kernel interface;
but that can be changed (and Rafael has plans to do that). I think we
can present nicer interface to userland without much code. Or maybe
not; but we can certainly limit /dev/kmem for suspend only -- and that
should make it acceptable security-wise.

                                                                Pavel

-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Rafael J. Wysocki]

Hi,

On Wednesday, 16 of November 2005 22:13, Nigel Cunningham wrote:
> On Thu, 2005-11-17 at 09:05, Pavel Machek wrote:
}-- snip --{
> > So... to get 225 patches in, you'll need to explain that
> > userland-swsusp can't work. If you can do that, please be nice and do
> > it soon, so that I don't waste too much time on userland-swsusp.
> 
> I thought Dave already did that.

Not as far as I'm concerned.  He criticised the implementation,
which I generally agree with, but IMO the overall idea is not wrong.

BTW, you don't need to export the page flags, use /dev/kmem etc. to implement
it.  The only concern that I have wrt it is the writing of the image _after_ the
system has been snapshotted.

Greetings,
Rafael

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
> 
> I've also split the one patch that most people see into what is
> currently about 225 smaller patches, each adding only one small part, am
> writing descriptions for them all and am preparing to build a git tree
> from it.

That's great, I didn't know you were doing this.

I'd recommend using quilt instead of git for something like this,
because the odds that you will need to change something in patch number
132 out of 225 is pretty good :)

thanks,

greg k-h

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> > Please, everyone realize that Nigel's code is not going to be merged
> > into mainline as it is today.  He knows it, and everyone else involved
> > knows it.  Nigel also knows the proper procedure for getting his changes
> > into mainline, if he so desires, as we all sat in a room last July and
> > discussed this (lwn.net has a summary somewhere about it too...)
> 
> Do you mean "as it was in July"? I haven't been sitting on my hands
> since July :)  My wife will testify to that!
...
> I've also split the one patch that most people see into what is
> currently about 225 smaller patches, each adding only one small part, am
> writing descriptions for them all and am preparing to build a git tree
> from it.

I'm not sure that gets suspend2 any closer to merging. 225 small
patches is still awful lot of code :-(. Now... if something can be
done in userspace, it probably should. And I'm trying to show that
suspend2 functionality can indeed be done in userspace.

So... to get 225 patches in, you'll need to explain that
userland-swsusp can't work. If you can do that, please be nice and do
it soon, so that I don't waste too much time on userland-swsusp.

								Pavel
-- 
Thanks, Sharp!

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi.

On Thu, 2005-11-17 at 09:10, Greg KH wrote:
> On Thu, Nov 17, 2005 at 07:20:45AM +1100, Nigel Cunningham wrote:
> > 
> > I've also split the one patch that most people see into what is
> > currently about 225 smaller patches, each adding only one small part, am
> > writing descriptions for them all and am preparing to build a git tree
> > from it.
> 
> That's great, I didn't know you were doing this.
> 
> I'd recommend using quilt instead of git for something like this,
> because the odds that you will need to change something in patch number
> 132 out of 225 is pretty good :)

Yeah. :) I actually wrote my own 'makepatch' script long before I ever
heard of quilt, and am still using that. It lets me do the same sort of
thing. Unfortunately I tend to accumulate further changes at the end of
the series and then have to shift them back into the right place. It
would be nice to be able to automate that :)

Nigel

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi.

On Thu, 2005-11-17 at 09:05, Pavel Machek wrote:
> Hi!
> 
> > > Please, everyone realize that Nigel's code is not going to be merged
> > > into mainline as it is today.  He knows it, and everyone else involved
> > > knows it.  Nigel also knows the proper procedure for getting his changes
> > > into mainline, if he so desires, as we all sat in a room last July and
> > > discussed this (lwn.net has a summary somewhere about it too...)
> > 
> > Do you mean "as it was in July"? I haven't been sitting on my hands
> > since July :)  My wife will testify to that!
> ...
> > I've also split the one patch that most people see into what is
> > currently about 225 smaller patches, each adding only one small part, am
> > writing descriptions for them all and am preparing to build a git tree
> > from it.
> 
> I'm not sure that gets suspend2 any closer to merging. 225 small
> patches is still awful lot of code :-(. Now... if something can be
> done in userspace, it probably should. And I'm trying to show that
> suspend2 functionality can indeed be done in userspace.
> 
> So... to get 225 patches in, you'll need to explain that
> userland-swsusp can't work. If you can do that, please be nice and do
> it soon, so that I don't waste too much time on userland-swsusp.

I thought Dave already did that.

Regards,

Nigel

Re: [linux-pm] [RFC] userland swsusp

[Nigel Cunningham]

Hi.

On Thu, 2005-11-17 at 03:44, Greg KH wrote:
> Please, everyone realize that Nigel's code is not going to be merged
> into mainline as it is today.  He knows it, and everyone else involved
> knows it.  Nigel also knows the proper procedure for getting his changes
> into mainline, if he so desires, as we all sat in a room last July and
> discussed this (lwn.net has a summary somewhere about it too...)

Do you mean "as it was in July"? I haven't been sitting on my hands
since July :)  My wife will testify to that!

I've been working on implementing the last new features I want in,
fixing bugs and generally making it as stable and reliable as I can.
(Sorry Andrew, but I'm being a perfectionist). At the same time, many of
the parts that made Suspend2 be considered huge and ugly have been
merged. The pm_message_t stuff, for example, was adopted early by
Suspend2 and part of those stats you saw in July. The patch currently
still includes the workqueue nofreeze patch, Christoph's todo list
freezer modifications. These account for virtually all of the changes
outside of kernel/power.

I've also split the one patch that most people see into what is
currently about 225 smaller patches, each adding only one small part, am
writing descriptions for them all and am preparing to build a git tree
from it.

Hopefully that shows that I am working toward merging, just maybe not in
the way that you were imagining. You'll remember that I've argued before
that trying to patch swsusp into Suspend2 is infeasible. I'm not even
trying to do it.

Regards,

Nigel

> So, here's Pavel trying to make things better and people are complaining
> about it.  Argue that the technical points are invalid (like Dave did.)
> But don't just sit around and kvetch, that doesn't help out anyone.
> 
> thanks,
> 
> greg k-h
> -
> 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/
-- 

Re: [linux-pm] [RFC] userland swsusp

[Pavel Machek]

Hi!

> I worry that this is just adding more thrash to a historically unstable
> implementation.  How long do we users have to wait for a swsusp
> implementation where we don't have to worry about breaking from one
> kernel release to the next?

What unstable implementation? swsusp had very little regressions over past
year or so. Drivers were different story, but nothing changes w.r.t. drivers.

								Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [linux-pm] [RFC] userland swsusp

[Greg KH]

On Wed, Nov 16, 2005 at 08:10:19AM -0800, Gross, Mark wrote:
> I worry that this is just adding more thrash to a historically unstable
> implementation.  How long do we users have to wait for a swsusp
> implementation where we don't have to worry about breaking from one
> kernel release to the next?

Never, you are hereby consigned to always have a broken swsusp
implementation on your machines.

There, feel better?  Or perhaps you could join in and help with the
current effort to make things better...

> I agree with this post http://lkml.org/lkml/2005/9/15/125 and note that
> making too large of a change thrashes the users a lot and if it doesn't
> solve a real problem or enable something critical, why make the changes?

Ok, so you are happy with what we currently have in the kernel tree
today?  Great, use that, I know it works for me and I'm happy with it...

Please, everyone realize that Nigel's code is not going to be merged
into mainline as it is today.  He knows it, and everyone else involved
knows it.  Nigel also knows the proper procedure for getting his changes
into mainline, if he so desires, as we all sat in a room last July and
discussed this (lwn.net has a summary somewhere about it too...)

So, here's Pavel trying to make things better and people are complaining
about it.  Argue that the technical points are invalid (like Dave did.)
But don't just sit around and kvetch, that doesn't help out anyone.

thanks,

greg k-h

RE: [linux-pm] [RFC] userland swsusp

[Gross, Mark]

I worry that this is just adding more thrash to a historically unstable
implementation.  How long do we users have to wait for a swsusp
implementation where we don't have to worry about breaking from one
kernel release to the next?

I agree with this post http://lkml.org/lkml/2005/9/15/125 and note that
making too large of a change thrashes the users a lot and if it doesn't
solve a real problem or enable something critical, why make the changes?


--mgross

>-----Original Message-----
>From: linux-pm-bounces@lists.osdl.org
[mailto:linux-pm-bounces@lists.osdl.org]
>On Behalf Of Pavel Machek
>Sent: Wednesday, November 16, 2005 12:56 AM
>To: Dave Jones; kernel list; Rafael J. Wysocki; Linux-pm mailing list
>Subject: Re: [linux-pm] [RFC] userland swsusp
>
>Hi!
>
>>  > > Even it were not for this, the whole idea seems misconcieved to
me
>>  > > anyway.
>>  >
>>  > ...but how do you provide nice, graphical progress bar for swsusp
>>  > without this? People want that, and "esc to abort", compression,
>>  > encryption. Too much to be done in kernel space, IMNSHO.
>>
>> I'll take "rootkit doesnt work" over "bells and whistles".
>
>It moves bunch of code from kernelspace to userspace. You don't have
>to add bells and whistles at the same time. That's normally called
>good thing. If Fedora has special needs, fine.
>								Pavel
>--
>Thanks, Sharp!