Re: A signal fairy tale
Christopher Smith <[EMAIL PROTECTED]> writes: [...] > >Signals are a pretty dopey API anyway - so instead of trying to > >patch them up, why not think of something better for AIO? > > You assume that this issue only comes up when you're doing AIO. If > we do something that makes signals work better, we can have a much > broader impact that just AIO. If nothing else, the signal usage > clashing issue has nothing to do with AIO. So what. Signals are bad system already. Therefore don't try to force them to do more stuff. Just because they have already been forced to do more doesn't mean it was a good idea at all, or that we should keep on patching bits and pieces onto them, IMHO. -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Christopher Smith [EMAIL PROTECTED] writes: [...] Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? You assume that this issue only comes up when you're doing AIO. If we do something that makes signals work better, we can have a much broader impact that just AIO. If nothing else, the signal usage clashing issue has nothing to do with AIO. So what. Signals are bad system already. Therefore don't try to force them to do more stuff. Just because they have already been forced to do more doesn't mean it was a good idea at all, or that we should keep on patching bits and pieces onto them, IMHO. -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
[...] > immediate: RAM, on-chip cache, etc. > fast: Flash reads, ROMs, etc. > medium:Hard drives, CD-ROMs, 100Mb ethernet, etc. > slow: Flash writes, floppy disks, CD-WR burners > packeted: Reads/write should be in as large a packet as possible > > Embedded Case [...] > Desktop Case I'm not sure there's any point in separating the cases like this. The complex part of the VM is the caching part => to be a good cache you must take into account the speed of accesses to the cached medium, including warm up times for sleepy drives etc. It would be really cool if the VM could do that, so e.g. in the ideal world you could connect up a slow harddrive and have its contents cached as swap on your fast harddrive(!) (not a new idea btw and already implemented elsewhere). I.e. from the point of view of the VM a computer is just a group of data storage units and it's allowed to use up certain parts of each one to do stuff [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
Stefan Hoffmeister <[EMAIL PROTECTED]> writes:
[...]
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
> FILE_ATTRIBUTE_TEMPORARY
>
> FILE_FLAG_WRITE_THROUGH
> FILE_FLAG_NO_BUFFERING
> FILE_FLAG_RANDOM_ACCESS
> FILE_FLAG_SEQUENTIAL_SCAN
>
> If Linux does not have mechanism that would allow the signalling of
> specific use case, it might be helpful to implement such a hinting
> system?
madvise(2) does it on mappings IIRC
--
Seeking summer job at last minute - see http://ape.n3.net/cv.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Dan Kegel <[EMAIL PROTECTED]> writes: [...] >A signal number cannot be opened more than once concurrently; >sigopen() thus provides a way to avoid signal usage clashes >in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: A signal fairy tale
Dan Kegel [EMAIL PROTECTED] writes: [...] A signal number cannot be opened more than once concurrently; sigopen() thus provides a way to avoid signal usage clashes in large programs. Signals are a pretty dopey API anyway - so instead of trying to patch them up, why not think of something better for AIO? [...] -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
Stefan Hoffmeister [EMAIL PROTECTED] writes: [...] Windows NT/2000 has flags that can be for each CreateFile operation (open in Unix terms), for instance FILE_ATTRIBUTE_TEMPORARY FILE_FLAG_WRITE_THROUGH FILE_FLAG_NO_BUFFERING FILE_FLAG_RANDOM_ACCESS FILE_FLAG_SEQUENTIAL_SCAN If Linux does not have mechanism that would allow the signalling of specific use case, it might be helpful to implement such a hinting system? madvise(2) does it on mappings IIRC -- Seeking summer job at last minute - see http://ape.n3.net/cv.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM Requirement Document - v0.0
[...] immediate: RAM, on-chip cache, etc. fast: Flash reads, ROMs, etc. medium:Hard drives, CD-ROMs, 100Mb ethernet, etc. slow: Flash writes, floppy disks, CD-WR burners packeted: Reads/write should be in as large a packet as possible Embedded Case [...] Desktop Case I'm not sure there's any point in separating the cases like this. The complex part of the VM is the caching part = to be a good cache you must take into account the speed of accesses to the cached medium, including warm up times for sleepy drives etc. It would be really cool if the VM could do that, so e.g. in the ideal world you could connect up a slow harddrive and have its contents cached as swap on your fast harddrive(!) (not a new idea btw and already implemented elsewhere). I.e. from the point of view of the VM a computer is just a group of data storage units and it's allowed to use up certain parts of each one to do stuff [...] -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > > Event Time PID Length Description > > > Trap entry 991,299,585,597,016 678 12 TRAP: page fault; >EIP : 0x40067785 That looks like just the generic interrupt handling. It does not do what I want to do, i.e. record some more info about the fault saying where it comes from. -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, John Fremlin wrote: > > > > > Last year I had the idea of tracing the memory accesses of the system > > to improve the VM - the traces could be used to test algorithms in > > userspace. The difficulty is of course making all memory accesses > > fault without destroying system performance. [...] > Linux Trace Toolkit (http://www.opersys.com/LTT) does that. I dld the ltt-usenix paper and skim read it. It didn't seem to talk about page faults much. Where should I look? -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti [EMAIL PROTECTED] writes: On 25 Jun 2001, John Fremlin wrote: Last year I had the idea of tracing the memory accesses of the system to improve the VM - the traces could be used to test algorithms in userspace. The difficulty is of course making all memory accesses fault without destroying system performance. [...] Linux Trace Toolkit (http://www.opersys.com/LTT) does that. I dld the ltt-usenix paper and skim read it. It didn't seem to talk about page faults much. Where should I look? -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Marcelo Tosatti [EMAIL PROTECTED] writes: Event Time PID Length Description Trap entry 991,299,585,597,016 678 12 TRAP: page fault; EIP : 0x40067785 That looks like just the generic interrupt handling. It does not do what I want to do, i.e. record some more info about the fault saying where it comes from. -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Rik van Riel <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, John Fremlin wrote: > > > Last year I had the idea of tracing the memory accesses of the > > system to improve the VM - the traces could be used to test > > algorithms in userspace. The difficulty is of course making all > > memory accesses fault without destroying system performance. > > Sounds like a cool idea. One thing you should keep in mind though > is to gather traces of the WHOLE SYSTEM and not of individual > applications. In the current patch all pagefaults are recorded from all sources. I'd like to be able to catch read(2) and write(2) (buffer cache stuff) as well but I don't know how . . . . > There has to be a way to balance the eviction of pages from > applications against those of other applications. Of course! It is important not to regard each thread group as an independent entity IMHO (had a big old argument about this). [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VM tuning through fault trace gathering [with actual code]
Last year I had the idea of tracing the memory accesses of the system
to improve the VM - the traces could be used to test algorithms in
userspace. The difficulty is of course making all memory accesses
fault without destroying system performance.
The following patch (i386 only) will dump all page faults to
/dev/biglog (you need devfs for this node to appear). If you echo 1 >
/proc/sys/vm/trace then *almost all* userspace memory accesses will
take a soft fault. Note that this is a bit suicidal at the moment
because of the staggeringly inefficient way its implemented, on my box
(K6-2 300MHz) only processes which do very little (e.g. /usr/bin/yes)
running at highest priority are able to print anything to the console.
I think the best way would be to have only one valid l2 pte per
process. I'll have a go at doing that in a day or two unless someone
has a better idea?
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/Makefile linux-2.4.4-i386-pagetrace/drivers/char/Makefile
--- linux-2.4.4-orig/drivers/char/Makefile Tue May 1 14:33:51 2001
+++ linux-2.4.4-i386-pagetrace/drivers/char/Makefile Sat Jun 23 22:21:34 2001
@@ -16,7 +16,7 @@
O_TARGET := char.o
-obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o
+obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o biglog.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/biglog.c linux-2.4.4-i386-pagetrace/drivers/char/biglog.c
--- linux-2.4.4-orig/drivers/char/biglog.c Thu Jan 1 01:00:00 1970
+++ linux-2.4.4-i386-pagetrace/drivers/char/biglog.c Sun Jun 24 14:55:55 2001
@@ -0,0 +1,204 @@
+/* Implements a misc device that can output large amounts of data from
+ * the kernel to userspace
+ *
+ * (c) 2001 John Fremlin released under GPL
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BUFFER_SIZE (1024*1024*1)
+
+char buffer[BUFFER_SIZE];
+
+static DECLARE_WAIT_QUEUE_HEAD(waiters);
+static spinlock_t write_head_lock = SPIN_LOCK_UNLOCKED;
+unsigned long write_head;
+
+struct fop_priv
+{
+ unsigned long read_head;
+}
+;
+
+void biglog_log(const char*str)
+{
+ const char*i = str;
+ unsigned long head;
+ unsigned long flags;
+
+ spin_lock_irqsave(_head_lock,flags);
+ head = write_head;
+ while(*i) {
+ buffer[head++]= *i++;
+ if(head>=BUFFER_SIZE)
+ head = 0;
+ }
+ write_head = head;
+ spin_unlock_irqrestore(_head_lock,flags);
+ wake_up_all();
+}
+
+void biglog_logfault(struct mm_struct *mm, struct vm_area_struct * vma,
+ unsigned long address, int write_access)
+{
+ static unsigned long no;
+ static char faultbuf[1024];
+
+ char* process = current ? current->comm : "unknown";
+ pid_t pid = current ? current->pid : 0;
+
+ unsigned long offset = address - vma->vm_start;
+ struct file* file = vma->vm_file;
+ struct dentry* dentry = file ? file->f_dentry : 0;
+ struct inode* inode = dentry ? dentry->d_inode : 0;
+
+ unsigned long ino = inode ? inode->i_ino : 0;
+ kdev_t device = inode ? inode->i_dev : 0;
+ struct qstr* d_name = dentry ? >d_name : 0;
+
+ char name[100];
+ unsigned len = sizeof(name)-1;
+
+ if(d_name && (d_name->len < len))
+ len = d_name->len;
+
+ strncpy(name, d_name ? (const char*)d_name->name : (const char*)
+ "anon", len);
+ name[len] = 0;
+
+ sprintf(faultbuf,"%lu: %p%c (%s) %lu (%s) %p %lu:%lu+%lu\n",
+ no++,
+ (void*)address,
+ write_access?'W':'r',
+ process,
+ (unsigned long)pid,
+ (char*)name,
+ vma,
+ (unsigned long)device,
+ ino,
+ offset
+ );
+
+ biglog_log(faultbuf);
+}
+
+static int fop_open(struct inode * inode, struct file * file)
+{
+ struct fop_priv*priv;
+ priv = kmalloc(sizeof *priv,GFP_KERNEL);
+ if(!priv)
+ return -ENOMEM;
+
+ memset(priv,0,sizeof *priv);
+
+ priv->read_head = write_head;
+ file->private_data = priv;
+
+ return 0;
+}
+
+static ssize_t fop_read(struct file * file, char * buf,
+ size_t count, loff_t *ppos)
+{
+ ssize_t ret = 0;
+ unsigned long head;
+ unsigned long flags;
+ struct fop_priv *priv = (struct fop_priv *)file->private_data;
+
+ if (ppos != >f_pos)
+ return -ESPIPE;
+
+ spin_lock_irqsave(_head_lock,flags);
+ head = write_head;
+ if(head == priv->read_head) {
+ spin_unlock_irqrestore(_head_lock,flags);
+ if(file->f_flags_NONBLOCK)
+ return -EAGAIN;
+
+ if (wait_event_interruptible(waiters,
+ head != write_head)
+ == -ERESTARTSYS) {
+ return -ERESTARTSYS;
+ }
+ spin_lock_irqsave(_head_lock,flags);
+ head = write_head;
+ }
+ if(!count)
+ goto out;
+
+ if(head >= priv->read_head)
+ if(count > head - priv->read_head)
+ count = head - priv->read_head;
+
+ if(count+priv->read_head > BUFFER_SIZE)
+ count = BUFFER_SIZE - priv->read_head;
+
+ i
VM tuning through fault trace gathering [with actual code]
Last year I had the idea of tracing the memory accesses of the system
to improve the VM - the traces could be used to test algorithms in
userspace. The difficulty is of course making all memory accesses
fault without destroying system performance.
The following patch (i386 only) will dump all page faults to
/dev/biglog (you need devfs for this node to appear). If you echo 1
/proc/sys/vm/trace then *almost all* userspace memory accesses will
take a soft fault. Note that this is a bit suicidal at the moment
because of the staggeringly inefficient way its implemented, on my box
(K6-2 300MHz) only processes which do very little (e.g. /usr/bin/yes)
running at highest priority are able to print anything to the console.
I think the best way would be to have only one valid l2 pte per
process. I'll have a go at doing that in a day or two unless someone
has a better idea?
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/Makefile linux-2.4.4-i386-pagetrace/drivers/char/Makefile
--- linux-2.4.4-orig/drivers/char/Makefile Tue May 1 14:33:51 2001
+++ linux-2.4.4-i386-pagetrace/drivers/char/Makefile Sat Jun 23 22:21:34 2001
@@ -16,7 +16,7 @@
O_TARGET := char.o
-obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o
+obj-y += tty_io.o n_tty.o tty_ioctl.o mem.o raw.o pty.o misc.o random.o biglog.o
# All of the (potential) objects that export symbols.
# This list comes from 'grep -l EXPORT_SYMBOL *.[hc]'.
diff --exclude *~ --new-file -u -r linux-2.4.4-orig/drivers/char/biglog.c linux-2.4.4-i386-pagetrace/drivers/char/biglog.c
--- linux-2.4.4-orig/drivers/char/biglog.c Thu Jan 1 01:00:00 1970
+++ linux-2.4.4-i386-pagetrace/drivers/char/biglog.c Sun Jun 24 14:55:55 2001
@@ -0,0 +1,204 @@
+/* Implements a misc device that can output large amounts of data from
+ * the kernel to userspace
+ *
+ * (c) 2001 John Fremlin released under GPL
+ */
+
+#include linux/slab.h
+#include linux/init.h
+#include linux/miscdevice.h
+#include linux/spinlock.h
+#include linux/wait.h
+#include asm/uaccess.h
+#include linux/mm.h
+#include linux/module.h
+
+#define BUFFER_SIZE (1024*1024*1)
+
+char buffer[BUFFER_SIZE];
+
+static DECLARE_WAIT_QUEUE_HEAD(waiters);
+static spinlock_t write_head_lock = SPIN_LOCK_UNLOCKED;
+unsigned long write_head;
+
+struct fop_priv
+{
+ unsigned long read_head;
+}
+;
+
+void biglog_log(const char*str)
+{
+ const char*i = str;
+ unsigned long head;
+ unsigned long flags;
+
+ spin_lock_irqsave(write_head_lock,flags);
+ head = write_head;
+ while(*i) {
+ buffer[head++]= *i++;
+ if(head=BUFFER_SIZE)
+ head = 0;
+ }
+ write_head = head;
+ spin_unlock_irqrestore(write_head_lock,flags);
+ wake_up_all(waiters);
+}
+
+void biglog_logfault(struct mm_struct *mm, struct vm_area_struct * vma,
+ unsigned long address, int write_access)
+{
+ static unsigned long no;
+ static char faultbuf[1024];
+
+ char* process = current ? current-comm : unknown;
+ pid_t pid = current ? current-pid : 0;
+
+ unsigned long offset = address - vma-vm_start;
+ struct file* file = vma-vm_file;
+ struct dentry* dentry = file ? file-f_dentry : 0;
+ struct inode* inode = dentry ? dentry-d_inode : 0;
+
+ unsigned long ino = inode ? inode-i_ino : 0;
+ kdev_t device = inode ? inode-i_dev : 0;
+ struct qstr* d_name = dentry ? dentry-d_name : 0;
+
+ char name[100];
+ unsigned len = sizeof(name)-1;
+
+ if(d_name (d_name-len len))
+ len = d_name-len;
+
+ strncpy(name, d_name ? (const char*)d_name-name : (const char*)
+ anon, len);
+ name[len] = 0;
+
+ sprintf(faultbuf,%lu: %p%c (%s) %lu (%s) %p %lu:%lu+%lu\n,
+ no++,
+ (void*)address,
+ write_access?'W':'r',
+ process,
+ (unsigned long)pid,
+ (char*)name,
+ vma,
+ (unsigned long)device,
+ ino,
+ offset
+ );
+
+ biglog_log(faultbuf);
+}
+
+static int fop_open(struct inode * inode, struct file * file)
+{
+ struct fop_priv*priv;
+ priv = kmalloc(sizeof *priv,GFP_KERNEL);
+ if(!priv)
+ return -ENOMEM;
+
+ memset(priv,0,sizeof *priv);
+
+ priv-read_head = write_head;
+ file-private_data = priv;
+
+ return 0;
+}
+
+static ssize_t fop_read(struct file * file, char * buf,
+ size_t count, loff_t *ppos)
+{
+ ssize_t ret = 0;
+ unsigned long head;
+ unsigned long flags;
+ struct fop_priv *priv = (struct fop_priv *)file-private_data;
+
+ if (ppos != file-f_pos)
+ return -ESPIPE;
+
+ spin_lock_irqsave(write_head_lock,flags);
+ head = write_head;
+ if(head == priv-read_head) {
+ spin_unlock_irqrestore(write_head_lock,flags);
+ if(file-f_flagsO_NONBLOCK)
+ return -EAGAIN;
+
+ if (wait_event_interruptible(waiters,
+ head != write_head)
+ == -ERESTARTSYS) {
+ return -ERESTARTSYS;
+ }
+ spin_lock_irqsave(write_head_lock,flags);
+ head = write_head;
+ }
+ if(!count)
+ goto out;
+
+ if(head = priv-read_head)
+ if(count head - priv-read_head)
+ count = head - priv-read_head;
+
+ if(count+priv-read_head BUFFER_SIZE)
+ count = BUFFER_SIZE - priv-read_head
Re: VM tuning through fault trace gathering [with actual code]
Rik van Riel [EMAIL PROTECTED] writes: On 25 Jun 2001, John Fremlin wrote: Last year I had the idea of tracing the memory accesses of the system to improve the VM - the traces could be used to test algorithms in userspace. The difficulty is of course making all memory accesses fault without destroying system performance. Sounds like a cool idea. One thing you should keep in mind though is to gather traces of the WHOLE SYSTEM and not of individual applications. In the current patch all pagefaults are recorded from all sources. I'd like to be able to catch read(2) and write(2) (buffer cache stuff) as well but I don't know how . . . . There has to be a way to balance the eviction of pages from applications against those of other applications. Of course! It is important not to regard each thread group as an independent entity IMHO (had a big old argument about this). [...] -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [slightly OT] IDE problems ? or just a dead disk ?
"David Flynn" <[EMAIL PROTECTED]> writes: [...] > ive done the badblock test, and compiled a list of 2302 bad blocks on this > disk ... however, when running mke2fs -l badblocfile /dev/hdc1 > > i got this interesting errormessage for every one of the bad blocks : > > Bad block 1006290 out of range; ignored. That is probably because badblocks was working with badblocks of a smaller size than that of the filesystem (i.e. probably 1024 bytes instead of 4096 bytes, solution in this case is to divide all bad block numbers by 4). Well that's what happened to me today (worryingly on my newish IBM DTLA hd). -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [slightly OT] IDE problems ? or just a dead disk ?
David Flynn [EMAIL PROTECTED] writes: [...] ive done the badblock test, and compiled a list of 2302 bad blocks on this disk ... however, when running mke2fs -l badblocfile /dev/hdc1 i got this interesting errormessage for every one of the bad blocks : Bad block 1006290 out of range; ignored. That is probably because badblocks was working with badblocks of a smaller size than that of the filesystem (i.e. probably 1024 bytes instead of 4096 bytes, solution in this case is to divide all bad block numbers by 4). Well that's what happened to me today (worryingly on my newish IBM DTLA hd). -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] setuid(2) buggy or bad docs
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is returned by the syscall even if the euid of the process matches the uid passed to it. Either I am non compos or the thing is very wrong. The docs (man-pages-1.35) say ERRORS EPERM The user is not the super-user, and uid does not match the effective or saved user ID of the calling process. The following untested patch changes the kernel to match the documentated behaviour. --- linux-2.4.4-orig/kernel/sys.c Tue May 1 14:34:43 2001 +++ linux-2.4.4/kernel/sys.c Wed Jun 20 01:32:46 2001 @@ -603,7 +603,9 @@ asmlinkage long sys_setuid(uid_t uid) if (uid != old_ruid && set_user(uid, old_euid != uid) < 0) return -EAGAIN; new_suid = uid; - } else if ((uid != current->uid) && (uid != new_suid)) + } else if ((uid != current->uid) + && (uid != new_suid) + && (uid != old_euid)) return -EPERM; if (old_euid != uid) -- Summer job urgently sought due to last minute visa trouble! Please see http://ape.n3.net/cv.html
[PATCH] setuid(2) buggy or bad docs
setuid(2) differs from the OpenBSD setuid(2) in that -EPERM is returned by the syscall even if the euid of the process matches the uid passed to it. Either I am non compos or the thing is very wrong. The docs (man-pages-1.35) say ERRORS EPERM The user is not the super-user, and uid does not match the effective or saved user ID of the calling process. The following untested patch changes the kernel to match the documentated behaviour. --- linux-2.4.4-orig/kernel/sys.c Tue May 1 14:34:43 2001 +++ linux-2.4.4/kernel/sys.c Wed Jun 20 01:32:46 2001 @@ -603,7 +603,9 @@ asmlinkage long sys_setuid(uid_t uid) if (uid != old_ruid set_user(uid, old_euid != uid) 0) return -EAGAIN; new_suid = uid; - } else if ((uid != current-uid) (uid != new_suid)) + } else if ((uid != current-uid) + (uid != new_suid) + (uid != old_euid)) return -EPERM; if (old_euid != uid) -- Summer job urgently sought due to last minute visa trouble! Please see http://ape.n3.net/cv.html
Re: Problems with arch/i386/kernel/apm.c
Jeff Golds <[EMAIL PROTECTED]> writes: [...] > Please let me know if this is correct, I can provide a simple patch > if needed. What I am really desiring to know is if there are any > devices that depend on the apm::send_event(APM_NORMAL_RESUME) > happening while interrupts are disabled. Yes, USB host controllers -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with arch/i386/kernel/apm.c
Jeff Golds [EMAIL PROTECTED] writes: [...] Please let me know if this is correct, I can provide a simple patch if needed. What I am really desiring to know is if there are any devices that depend on the apm::send_event(APM_NORMAL_RESUME) happening while interrupts are disabled. Yes, USB host controllers -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.4 isapnp - wrong set of resources chosen
Hi! Robin Cull and I have OPL3-SA2 isapnp cards. Sometimes we get assigned the wrong resource set. These cards do not take kindly to Alternate resources 0:1 Priority acceptable, in fact they are completely broke, so it is important to us that they get their first choice ;-) The trouble is that isapnp auto conf does not always take the first choice, even when it is available! This happens to me everytime I unload and reload the opl3sa2 module, but can also be seen after unloading the module by doing card 0 YMH0020 dev 0 YMH0021 deactivate auto activate The second config is chosen (see attached /proc/isapnp). However, activating the first config by hand works fine - on reloading the module it plays sounds just dandy. card 0 YMH0020 dev 0 YMH0021 deactivate port 0 0x220 port 1 0x530 port 2 0x388 port 3 0x330 port 4 0x370 dma 0 0 dma 1 1 irq 0 5 activate isapnp ioports interrupts -- http://ape.n3.net
2.4.4 isapnp - wrong set of resources chosen
Hi! Robin Cull and I have OPL3-SA2 isapnp cards. Sometimes we get assigned the wrong resource set. These cards do not take kindly to Alternate resources 0:1 Priority acceptable, in fact they are completely broke, so it is important to us that they get their first choice ;-) The trouble is that isapnp auto conf does not always take the first choice, even when it is available! This happens to me everytime I unload and reload the opl3sa2 module, but can also be seen after unloading the module by doing card 0 YMH0020 dev 0 YMH0021 deactivate auto activate The second config is chosen (see attached /proc/isapnp). However, activating the first config by hand works fine - on reloading the module it plays sounds just dandy. card 0 YMH0020 dev 0 YMH0021 deactivate port 0 0x220 port 1 0x530 port 2 0x388 port 3 0x330 port 4 0x370 dma 0 0 dma 1 1 irq 0 5 activate isapnp ioports interrupts -- http://ape.n3.net
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro <[EMAIL PROTECTED]> writes: [...] > We have ~180 first-order ioctl() methods. Several (my guess would be Hehe. I suppose you already know about the way strace (@sourceforge) kind of automatically tries to figure out the args for the common ones? [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no ioctls for serial ports? [was Re: LANANA: To Pending DeviceNumberRegistrants]
Alexander Viro [EMAIL PROTECTED] writes: [...] We have ~180 first-order ioctl() methods. Several (my guess would be Hehe. I suppose you already know about the way strace (@sourceforge) kind of automatically tries to figure out the args for the common ones? [...] -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LANANA: To Pending Device Number Registrants
Linus Torvalds <[EMAIL PROTECTED]> writes: [...] > Nobody really uses it because it would require you to add a line or > two to your init scripts to pick up the major number from > /proc/devices, and that's obviously too hard. Much better to just > hardcode randome numbers, right? And thereby avoid using procfs. Hardcoding is the way the BSDs seem to be going. Clueless suggestion: I suppose you could allocate numbers on kernel build or something. [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: simple userspace pm interface
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> - It's probably easier to put the "event" file in proc, instead of
> dev. This is what the acpi interface does, and eliminates the mknod
> step.
Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)
> - perhaps rename boxevent() to event() or sys_event()?
Event is a bit generic, and sys_event is vague. I agree that boxevent
is not a pretty name, but it gives a vague suggestion of
hardwareness. hwevent looks ugly - what do people think?
> - Consider putting the subsystem/class identifier first
> - Consider hiding the source of the event. For example, we shouldn't care
> that the power button press was generated by APM or MIPS64, because we're
> going to take the same action, regardless.
The suggested action is given as the first word. The second word is
the subsystem, in order to avoid namespace collisions: you could have
two different PM systems active on your machine at different times,
(e.g. ACPI and APM) and this lets you distinguish between them. You
could think of it as the first word being the suggested action and the
rest being a description.
> I'd encourage you to take a look at the ACPI code that does
> something similar (in 2.4.4ac4 or greater, or grab the code from the
> website at
> http://developer.intel.com/technology/iapc/acpi/downloads.htm .)
> Specifically, grep -r for bm_osl_generate_event(). Modifying that
> code to be more general-purpose could possibly meet ACPI's needs as
> well as everyone else's.
ACPI_STATUS bm_osl_generate_event (
BM_HANDLE device_handle,
char*device_type,
char*device_instance,
u32 event_type,
u32 event_data)
{
The function could quickly be converted to boxevent without thinking
sprintf(buffer,"device %s instance %s says %x: %x",
device_type,device_instance,event_type,event_data);
boxevent(BOXEVENT_NOTIFY,"ACPI",buffer);
this would provide all of the current functionality available from
ACPI (ATM the code does sprintf(str, "%s %s %08x %08x\n") to the
userspace reader) but boxevent also handles poll, short reads, and
event floods, etc.
Some one who knows about ACPI could change the BOXEVENT_NOTIFY to a
better suggestion based on event_type or something.
[...]
--
http://ape.n3.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: simple userspace pm interface
Grover, Andrew [EMAIL PROTECTED] writes:
[...]
- It's probably easier to put the event file in proc, instead of
dev. This is what the acpi interface does, and eliminates the mknod
step.
Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)
- perhaps rename boxevent() to event() or sys_event()?
Event is a bit generic, and sys_event is vague. I agree that boxevent
is not a pretty name, but it gives a vague suggestion of
hardwareness. hwevent looks ugly - what do people think?
- Consider putting the subsystem/class identifier first
- Consider hiding the source of the event. For example, we shouldn't care
that the power button press was generated by APM or MIPS64, because we're
going to take the same action, regardless.
The suggested action is given as the first word. The second word is
the subsystem, in order to avoid namespace collisions: you could have
two different PM systems active on your machine at different times,
(e.g. ACPI and APM) and this lets you distinguish between them. You
could think of it as the first word being the suggested action and the
rest being a description.
I'd encourage you to take a look at the ACPI code that does
something similar (in 2.4.4ac4 or greater, or grab the code from the
website at
http://developer.intel.com/technology/iapc/acpi/downloads.htm .)
Specifically, grep -r for bm_osl_generate_event(). Modifying that
code to be more general-purpose could possibly meet ACPI's needs as
well as everyone else's.
ACPI_STATUS bm_osl_generate_event (
BM_HANDLE device_handle,
char*device_type,
char*device_instance,
u32 event_type,
u32 event_data)
{
The function could quickly be converted to boxevent without thinking
sprintf(buffer,device %s instance %s says %x: %x,
device_type,device_instance,event_type,event_data);
boxevent(BOXEVENT_NOTIFY,ACPI,buffer);
this would provide all of the current functionality available from
ACPI (ATM the code does sprintf(str, %s %s %08x %08x\n) to the
userspace reader) but boxevent also handles poll, short reads, and
event floods, etc.
Some one who knows about ACPI could change the BOXEVENT_NOTIFY to a
better suggestion based on event_type or something.
[...]
--
http://ape.n3.net
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
simple userspace pm interface
Here is a patch to deal with PM events (e.g. button presses) in a
system independent way. Could people with the applicable hardware test
out or comment on the changes?
The files affected are
arch/i386/kernel/apm.c
arch/mips/sgi/kernel/reset.c
arch/mips64/sgi-ip22/ip22-reset.c
arch/sparc64/kernel/power.c
drivers/acpi/driver.c
drivers/char/nwbutton.c
drivers/char/nwbutton.h
There are many power management and button press drivers in the
kernel. They all tend to have their own interface to distribute events
to userspace. This is bad, because it means duplicated code, and
requires arch specific userspace whatnots, which should not be
necessary.
Specifically, at the moment, the following approaches are taken by
various subsystems:
- launch /sbin/shutdown
- signal init
- do nothing
And there 3 or so different special devices that userspace can read to
see events. After this patch there are only 2 that I know of (ACPI and
/dev/boxevent, perhaps the ACPI stuff could also be removed, I didn't
look).
The patch converts the PM drivers I found to use a single
interface. (Only APM is tested because nobody has given me e.g. a
SPARC box: i.e. the patch is just a suggestion.)
The kernel interface is very simple. Each driver just does
#include
void button_interrupt() {
boxevent(BUTTONEVENT_OFF,"TurboSnail","button pressed");
}
and the event is exported to any number of userspace listeners on
/dev/boxevent. Thereby writing a new power button driver does not
involve having to deal with all the baggage of device nodes, etc.
You can create /dev/boxevent with mknod boxevent c 10 137
You can see what events occur simply by "cat"ing it to the console.
The format is very simple.
Where is one of the strings OFF,SLEEP,WAKE,EMERGENCY,NOTIFY
(if a reader does not read events quickly enough, it will get a
MSGFLOOD event), is a space character, is a word
denoting the kernel pm interface responsible for generating the event,
is an arbitrary string. is a newline character \n.
This is flexible. It means a reasonable default behaviour can be
suggested by the kernel (OFF,SLEEP,etc.) for events that userspace
doesn't know about, but userspace can choose fine grained policy and
provide helpful error messages based on the exact event name by
checking the description.
In fact, here is the "daemon" I use
#! /bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
sub do_off {
system("/sbin/shutdown -p now");
exit(0);
}
sub do_overflow {
setlogsock("unix");
openlog("boxd","cons","daemon");
syslog('err',"messages arriving too fast");
closelog();
}
while(<>){
if(/MSGFLOOD/) {
do_overflow();
next
}
if(/^SLEEP APM user suspend/){
do_off();
next
}
if(/^OFF/){
do_off();
next
}
}
The patch against 2.4.4 is attached.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-boxevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-boxevent/arch/i386/kernel/apm.c Mon May 7 15:36:53 2001
@@ -148,6 +148,9 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Move most of the /dev/apm_bios stuff to drivers/char/boxevent.c
+ * Reject all events by default
+ * (John Fremlin <[EMAIL PROTECTED]>)
*
* APM 1.1 Reference:
*
@@ -186,6 +189,7 @@
#include
#include
#include
+#include
#include
#include
@@ -301,10 +305,6 @@
int suser: 1;
int suspend_wait: 1;
int suspend_result;
- int suspends_pending;
- int standbys_pending;
- int suspends_read;
- int standbys_read;
int event_head;
int event_tail;
apm_event_t events[APM_MAX_EVENTS];
@@ -325,8 +325,7 @@
#ifdef CONFIG_APM_CPU_IDLE
static int clock_slowed;
#endif
-static int suspends_pending;
-static int standbys_pending;
+static int suspend_launched;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -352,7 +351,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = "1.14"; /* no spaces */
+static char driver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -579,56 +578,6 @@
clock_slowed = 0;
}
}
-
-#if 0
-extern int hlt_counter;
-
-/*
- * If no process has been interested in this
- * CPU for some time, we want to wake up the
- * power management thre
Re: [PATCH] zero^H^H^H^Hsingle copy pipe
[Stuff about NetBSD pipes snipped] I'm testing out Manfred's patch for zero copy pipes, and haven't crashed it yet. My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb - one quite slow 64 Mb stick and one fast 256 Mb stick. The lmbench bw_pipe showed a performance improvement of about 30% from 45 (+- 2) Mb/s to 59.5 (+-0.6) Mb/s. The lmbench (2beta3) lat_pipe showed a performance improvement of about 20% from a latency of about 27 (+- 1) usec to about 22.4 (+-.6) usec. There was one outlyer amoung the 10 non zc pipe runs - 25 usec. For zc, the first run was always about 25 usec and after that very stable around 22 usec. FWIW the system time from "time" when running (bw_pipe;lat_pipe) 10 times in a row *increased* by 50%, from sys 0m18.740s to sys 0m31.660s. Script: for i in 1 2 3 4 5 6 7 8 9 10; do ./bw_pipe; ./lat_pipe; done Non zero copy: real0m49.602s user0m10.170s sys 0m18.740s Zero copy run 1: real0m47.901s user0m10.390s sys 0m31.660s Zero copy run 2: real0m47.492s user0m10.600s sys 0m31.340s -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero^H^H^H^Hsingle copy pipe
[Stuff about NetBSD pipes snipped] I'm testing out Manfred's patch for zero copy pipes, and haven't crashed it yet. My hardware is a AMD K6-2 (stepping 1) on an ALi M1541 with 320 Mb - one quite slow 64 Mb stick and one fast 256 Mb stick. The lmbench bw_pipe showed a performance improvement of about 30% from 45 (+- 2) Mb/s to 59.5 (+-0.6) Mb/s. The lmbench (2beta3) lat_pipe showed a performance improvement of about 20% from a latency of about 27 (+- 1) usec to about 22.4 (+-.6) usec. There was one outlyer amoung the 10 non zc pipe runs - 25 usec. For zc, the first run was always about 25 usec and after that very stable around 22 usec. FWIW the system time from time when running (bw_pipe;lat_pipe) 10 times in a row *increased* by 50%, from sys 0m18.740s to sys 0m31.660s. Script: for i in 1 2 3 4 5 6 7 8 9 10; do ./bw_pipe; ./lat_pipe; done Non zero copy: real0m49.602s user0m10.170s sys 0m18.740s Zero copy run 1: real0m47.901s user0m10.390s sys 0m31.660s Zero copy run 2: real0m47.492s user0m10.600s sys 0m31.340s -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
simple userspace pm interface
Here is a patch to deal with PM events (e.g. button presses) in a
system independent way. Could people with the applicable hardware test
out or comment on the changes?
The files affected are
arch/i386/kernel/apm.c
arch/mips/sgi/kernel/reset.c
arch/mips64/sgi-ip22/ip22-reset.c
arch/sparc64/kernel/power.c
drivers/acpi/driver.c
drivers/char/nwbutton.c
drivers/char/nwbutton.h
There are many power management and button press drivers in the
kernel. They all tend to have their own interface to distribute events
to userspace. This is bad, because it means duplicated code, and
requires arch specific userspace whatnots, which should not be
necessary.
Specifically, at the moment, the following approaches are taken by
various subsystems:
- launch /sbin/shutdown
- signal init
- do nothing
And there 3 or so different special devices that userspace can read to
see events. After this patch there are only 2 that I know of (ACPI and
/dev/boxevent, perhaps the ACPI stuff could also be removed, I didn't
look).
The patch converts the PM drivers I found to use a single
interface. (Only APM is tested because nobody has given me e.g. a
SPARC box: i.e. the patch is just a suggestion.)
The kernel interface is very simple. Each driver just does
#include linux/boxevent.h
void button_interrupt() {
boxevent(BUTTONEVENT_OFF,TurboSnail,button pressed);
}
and the event is exported to any number of userspace listeners on
/dev/boxevent. Thereby writing a new power button driver does not
involve having to deal with all the baggage of device nodes, etc.
You can create /dev/boxevent with mknod boxevent c 10 137
You can see what events occur simply by cating it to the console.
The format is very simple.
event WS subsystem WS description LF
Where event is one of the strings OFF,SLEEP,WAKE,EMERGENCY,NOTIFY
(if a reader does not read events quickly enough, it will get a
MSGFLOOD event), WS is a space character, subsystem is a word
denoting the kernel pm interface responsible for generating the event,
description is an arbitrary string. LF is a newline character \n.
This is flexible. It means a reasonable default behaviour can be
suggested by the kernel (OFF,SLEEP,etc.) for events that userspace
doesn't know about, but userspace can choose fine grained policy and
provide helpful error messages based on the exact event name by
checking the description.
In fact, here is the daemon I use
#! /bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
sub do_off {
system(/sbin/shutdown -p now);
exit(0);
}
sub do_overflow {
setlogsock(unix);
openlog(boxd,cons,daemon);
syslog('err',messages arriving too fast);
closelog();
}
while(){
if(/MSGFLOOD/) {
do_overflow();
next
}
if(/^SLEEP APM user suspend/){
do_off();
next
}
if(/^OFF/){
do_off();
next
}
}
The patch against 2.4.4 is attached.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-boxevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-boxevent/arch/i386/kernel/apm.c Mon May 7 15:36:53 2001
@@ -148,6 +148,9 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Move most of the /dev/apm_bios stuff to drivers/char/boxevent.c
+ * Reject all events by default
+ * (John Fremlin [EMAIL PROTECTED])
*
* APM 1.1 Reference:
*
@@ -186,6 +189,7 @@
#include linux/pm.h
#include linux/kernel.h
#include linux/smp_lock.h
+#include linux/boxevent.h
#include asm/system.h
#include asm/uaccess.h
@@ -301,10 +305,6 @@
int suser: 1;
int suspend_wait: 1;
int suspend_result;
- int suspends_pending;
- int standbys_pending;
- int suspends_read;
- int standbys_read;
int event_head;
int event_tail;
apm_event_t events[APM_MAX_EVENTS];
@@ -325,8 +325,7 @@
#ifdef CONFIG_APM_CPU_IDLE
static int clock_slowed;
#endif
-static int suspends_pending;
-static int standbys_pending;
+static int suspend_launched;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -352,7 +351,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = 1.14; /* no spaces */
+static char driver_version[] = 1.15; /* no spaces */
static char * apm_event_name[] = {
system standby,
@@ -579,56 +578,6 @@
clock_slowed = 0;
}
}
-
-#if 0
-extern int hlt_counter;
-
-/*
- * If no process has been interested in this
- * CPU for some time, we want to wake up the
- * power management thread - we probably
Re: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: > > > > I'm wondering if that veto business is really needed. Why not reject > > > > *all* APM rejectable events, and then let the userspace event handler > > > > send the system to sleep or turn it off? Anybody au fait with the APM > > > > spec? > > > > > > Because apmd is optional > > > > The veto stuff only comes into action, iff someone has registered as > > willing to exercise this power. We would not break compatibility with > > any std kernel by instead having a apmd send a "reject all" ioctl > > instead, and so deal with events without having the pressure of having > > to reject or accept them, and let us remove all the veto code from the > > kernel driver. Or am I missing something? > > No, this looks reasonable. What do you think Stephen and Avery? Are you happy with this idea? If anybody wants to test it, my latest pmevent patch will reject *all* APM events it can. It would be easy to adapt that to turn on and off with an ioctl. I am happy to do that if Stephen would accept it. (Personally would like it if events were rejected by default but that breaks backward compatibility and there is always someone who would get bitten.) The latest pmevent patch (v3) with various APM cleanups is available at http://ape.n3.net/programs/linux/offbutton/download Note that it currently shares no code with the pmpolicy patch. For more information see http://ape.n3.net/programs/linux/offbutton/ -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Pavel Machek [EMAIL PROTECTED] writes: I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? Because apmd is optional The veto stuff only comes into action, iff someone has registered as willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a reject all ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? No, this looks reasonable. What do you think Stephen and Avery? Are you happy with this idea? If anybody wants to test it, my latest pmevent patch will reject *all* APM events it can. It would be easy to adapt that to turn on and off with an ioctl. I am happy to do that if Stephen would accept it. (Personally would like it if events were rejected by default but that breaks backward compatibility and there is always someone who would get bitten.) The latest pmevent patch (v3) with various APM cleanups is available at http://ape.n3.net/programs/linux/offbutton/download Note that it currently shares no code with the pmpolicy patch. For more information see http://ape.n3.net/programs/linux/offbutton/ -- http://ape.n3.net - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Actual patch for next gen PM interface
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox <[EMAIL PROTECTED]> writes:
> > > The entire PM layer for the embedded board I worked on was
> > > 3Kbytes. How small will yours be 8)
> >
> > The generic event interface will be under 3kB, I hope. Would you
> > accept it if so? ;-)
>
> We shall see. I've played with several ideas and never really been
> happy with them so maybe you can solve it
The fruits of today's labour are here. Unfortunately it *is* just over
3kB (but if I understand correctly under 4kB) mostly due to the
generous buffer sizes.
Note that this is prelim work. (Particularly the changes to the APM
stuff need to be looked at, and are not strictly relevant to the patch
at hand.) At the moment, APM events are printed to /dev/pmevent and
kmsg. Suspend requests are no longer acted on by the kernel. This
breaks backward compatibility.
The /dev/pmevent stuff is hopefully pretty feature complete. The
device numbers for it are 10 137. Multiple listeners are allowed etc.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-pmevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-pmevent/arch/i386/kernel/apm.c Tue May 1 23:47:18 2001
@@ -186,6 +186,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,7 +328,6 @@
#endif
static int suspends_pending;
static int standbys_pending;
-static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -886,33 +886,6 @@
#endif
}
-static int send_event(apm_event_t event)
-{
- switch (event) {
- case APM_SYS_SUSPEND:
- case APM_CRITICAL_SUSPEND:
- case APM_USER_SUSPEND:
- /* map all suspends to ACPI D3 */
- if (pm_send_all(PM_SUSPEND, (void *)3)) {
- if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" );
-return 0;
- }
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- return 0;
- }
- break;
- case APM_NORMAL_RESUME:
- case APM_CRITICAL_RESUME:
- /* map all resumes to ACPI D0 */
- (void) pm_send_all(PM_RESUME, (void *)0);
- break;
- }
-
- return 1;
-}
-
static int suspend(void)
{
int err;
@@ -927,7 +900,6 @@
err = APM_SUCCESS;
if (err != APM_SUCCESS)
apm_error("suspend", err);
- send_event(APM_NORMAL_RESUME);
sti();
queue_event(APM_NORMAL_RESUME, NULL);
for (as = user_list; as != NULL; as = as->next) {
@@ -968,6 +940,43 @@
return 0;
}
+static void announce_event(apm_event_t event)
+{
+ char*type = PME_NOTIFY;
+ char*name;
+
+ if (event <= NR_APM_EVENT_NAME)
+ name = apm_event_name[event - 1];
+ else name = "unknown event";
+
+ switch(event){
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ type = PME_SLEEP;
+ break;
+ case APM_NORMAL_RESUME:
+ case APM_CRITICAL_RESUME:
+ case APM_STANDBY_RESUME:
+ type = PME_WAKE;
+ break;
+ case APM_CAPABILITY_CHANGE:
+ type = PME_NOTIFY;
+ break;
+ case APM_LOW_BATTERY:
+ type = PME_EMERGENCY;
+ break;
+ case APM_POWER_STATUS_CHANGE:
+ type = PME_POWERCHANGE;
+ break;
+ default:
+ type = PME_NOTIFY;
+ }
+ pme_announce(type,"APM",name);
+}
+
static void check_events(void)
{
apm_event_t event;
@@ -989,56 +998,35 @@
if (ignore_normal_resume && (event != APM_NORMAL_RESUME))
ignore_normal_resume = 0;
+ announce_event(event);
+
switch (event) {
case APM_SYS_STANDBY:
case APM_USER_STANDBY:
- if (send_event(event)) {
-queue_event(event, NULL);
-if (standbys_pending <= 0)
- standby();
- }
+ queue_event(event, NULL);
+ if (standbys_pending <= 0)
+standby();
break;
case APM_USER_SUSPEND:
-#ifdef CONFIG_APM_IGNORE_USER_SUSPEND
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- break;
-#endif
case APM_SYS_SUSPEND:
- if (ignore_bounce) {
-if (apm_info.connection_version > 0x100)
- apm_set_power_state(APM_STATE_REJECT);
-break;
- }
- /*
- * If we are already processing a SUSPEND,
- * then further SUSPEND events from the BIOS
- * will be ignored. We also return here to
- * cope with the fact that the Thinkpads keep
- * sending a SUSPEND event until something else
- * happens!
+ /* Reject all suspend requests and let
+ * userspace call suspend if they want to
*/
- if (waiting_for_resume)
-return;
- if (send_event(event)) {
-queue_event(event, NULL);
-waiting_for_resume = 1;
-if (suspends_pending <= 0)
- (void) suspend();
- }
+ if (apm_info.connection_version > 0x100)
+apm_set_power_state(APM_STATE_REJECT);
+
+ queue_event(event, NULL);
break;
case APM_NORMAL_RESUME:
case
Actual patch for next gen PM interface
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox [EMAIL PROTECTED] writes:
The entire PM layer for the embedded board I worked on was
3Kbytes. How small will yours be 8)
The generic event interface will be under 3kB, I hope. Would you
accept it if so? ;-)
We shall see. I've played with several ideas and never really been
happy with them so maybe you can solve it
The fruits of today's labour are here. Unfortunately it *is* just over
3kB (but if I understand correctly under 4kB) mostly due to the
generous buffer sizes.
Note that this is prelim work. (Particularly the changes to the APM
stuff need to be looked at, and are not strictly relevant to the patch
at hand.) At the moment, APM events are printed to /dev/pmevent and
kmsg. Suspend requests are no longer acted on by the kernel. This
breaks backward compatibility.
The /dev/pmevent stuff is hopefully pretty feature complete. The
device numbers for it are 10 137. Multiple listeners are allowed etc.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-pmevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-pmevent/arch/i386/kernel/apm.c Tue May 1 23:47:18 2001
@@ -186,6 +186,7 @@
#include linux/pm.h
#include linux/kernel.h
#include linux/smp_lock.h
+#include linux/pmevent.h
#include asm/system.h
#include asm/uaccess.h
@@ -327,7 +328,6 @@
#endif
static int suspends_pending;
static int standbys_pending;
-static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -886,33 +886,6 @@
#endif
}
-static int send_event(apm_event_t event)
-{
- switch (event) {
- case APM_SYS_SUSPEND:
- case APM_CRITICAL_SUSPEND:
- case APM_USER_SUSPEND:
- /* map all suspends to ACPI D3 */
- if (pm_send_all(PM_SUSPEND, (void *)3)) {
- if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT apm: Critical suspend was vetoed, expect armageddon\n );
-return 0;
- }
- if (apm_info.connection_version 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- return 0;
- }
- break;
- case APM_NORMAL_RESUME:
- case APM_CRITICAL_RESUME:
- /* map all resumes to ACPI D0 */
- (void) pm_send_all(PM_RESUME, (void *)0);
- break;
- }
-
- return 1;
-}
-
static int suspend(void)
{
int err;
@@ -927,7 +900,6 @@
err = APM_SUCCESS;
if (err != APM_SUCCESS)
apm_error(suspend, err);
- send_event(APM_NORMAL_RESUME);
sti();
queue_event(APM_NORMAL_RESUME, NULL);
for (as = user_list; as != NULL; as = as-next) {
@@ -968,6 +940,43 @@
return 0;
}
+static void announce_event(apm_event_t event)
+{
+ char*type = PME_NOTIFY;
+ char*name;
+
+ if (event = NR_APM_EVENT_NAME)
+ name = apm_event_name[event - 1];
+ else name = unknown event;
+
+ switch(event){
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ type = PME_SLEEP;
+ break;
+ case APM_NORMAL_RESUME:
+ case APM_CRITICAL_RESUME:
+ case APM_STANDBY_RESUME:
+ type = PME_WAKE;
+ break;
+ case APM_CAPABILITY_CHANGE:
+ type = PME_NOTIFY;
+ break;
+ case APM_LOW_BATTERY:
+ type = PME_EMERGENCY;
+ break;
+ case APM_POWER_STATUS_CHANGE:
+ type = PME_POWERCHANGE;
+ break;
+ default:
+ type = PME_NOTIFY;
+ }
+ pme_announce(type,APM,name);
+}
+
static void check_events(void)
{
apm_event_t event;
@@ -989,56 +998,35 @@
if (ignore_normal_resume (event != APM_NORMAL_RESUME))
ignore_normal_resume = 0;
+ announce_event(event);
+
switch (event) {
case APM_SYS_STANDBY:
case APM_USER_STANDBY:
- if (send_event(event)) {
-queue_event(event, NULL);
-if (standbys_pending = 0)
- standby();
- }
+ queue_event(event, NULL);
+ if (standbys_pending = 0)
+standby();
break;
case APM_USER_SUSPEND:
-#ifdef CONFIG_APM_IGNORE_USER_SUSPEND
- if (apm_info.connection_version 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- break;
-#endif
case APM_SYS_SUSPEND:
- if (ignore_bounce) {
-if (apm_info.connection_version 0x100)
- apm_set_power_state(APM_STATE_REJECT);
-break;
- }
- /*
- * If we are already processing a SUSPEND,
- * then further SUSPEND events from the BIOS
- * will be ignored. We also return here to
- * cope with the fact that the Thinkpads keep
- * sending a SUSPEND event until something else
- * happens!
+ /* Reject all suspend requests and let
+ * userspace call suspend if they want to
*/
- if (waiting_for_resume)
-return;
- if (send_event(event)) {
-queue_event(event, NULL);
-waiting_for_resume = 1;
-if (suspends_pending = 0)
- (void) suspend();
- }
+ if (apm_info.connection_version 0x100)
+apm_set_power_state(APM_STATE_REJECT);
+
+ queue_event(event, NULL);
break;
Re: Let init know user wants to shutdown
Jamie Lokier <[EMAIL PROTECTED]> writes: [...] > Are you sure? A suspend takes about 5-10 seconds on my laptop. You mean when you tell the apm driver from userspace to suspend? > (It was noticably faster with 2.3 kernels, btw. Now it spends a second > or two apparently not noticing the APM event (though the BIOS is making > the speaker beep), then syncing the disk, The BIOS got the event, problem is in BIOS surely? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Jamie Lokier [EMAIL PROTECTED] writes: [...] Are you sure? A suspend takes about 5-10 seconds on my laptop. You mean when you tell the apm driver from userspace to suspend? (It was noticably faster with 2.3 kernels, btw. Now it spends a second or two apparently not noticing the APM event (though the BIOS is making the speaker beep), then syncing the disk, The BIOS got the event, problem is in BIOS surely? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: [...] > > I'm wondering if that veto business is really needed. Why not reject > > *all* APM rejectable events, and then let the userspace event handler > > send the system to sleep or turn it off? Anybody au fait with the APM > > spec? > > My thinkpad actually started blinking with some LED when you pressed > the button. LED went off when you rejected or when sleep was > completed. Does the led start blinking when the system sends an apm suspend? In that case I don't think you'd notice the brief period between the REJECT and the following suspend from userspace ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Pavel Machek [EMAIL PROTECTED] writes: [...] I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? My thinkpad actually started blinking with some LED when you pressed the button. LED went off when you rejected or when sleep was completed. Does the led start blinking when the system sends an apm suspend? In that case I don't think you'd notice the brief period between the REJECT and the following suspend from userspace ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: [...] > > > I can see at least two types of events - (forgive the lack of colorful > > > terminology) passive and active. Passive events are simply providing > > > status updates, much like the events described above. These are simply so > > > some UI can notify the user of things like a low battery or detection of > > > an AC adapter. These can be handled in much the same way as described > > > above. > > > > No they can't. They only happen once. Battery status exists all the > > time. > > Yes they can. My point was they can be handled from userspace in the > same way that battery status does - by doing a select on a file in > /proc or /dev. Once in a while (or constantly) they get data from > the kernel - battery status, AC change, etc - that can be then > translated and displayed in the UI. I think these events have a generic utility not specific to UIs. In particular, when ones battery is running out, one would quite like the event manager to be notified. As is currently the case with e.g. apmd. Polling on battery charge left or battery voltage/current is different from this, surely? Why should such programs have to be notified that the battery was low? The event itself is pretty useless if you're doing polling but there is no point throwing it away, in case you aren't. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: [...] > > Solution. Have a special procfs or dev node that any number of people > > can select(2) or read(2). Protocol text. Syntax: > > > > > > > > Where is one of the strings > > OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space character, > > is a word signifying the kernel pm interface responsible > > for generating th event, is an arbitrary string. is > > a newline character \n. > > > > This is flexible and simple. It means a reasonable default behaviour > > can be suggested by the kernel (OFF,SLEEP,etc.) for events that > > userspace doesn't know about and yet userspace can choose fine grained > > policy and provide helpful error messages based on the exact event by > > checking the description. > > First, Is there any reason why the kernel should do more text processing? Kernel does no text processing. Kernel merely gives text instead of magic numbers to the stream of bytes. > It is better left for user space. Besides, enumerated values > translated by userspace seems more efficient than copying and > parsing strings. Oh? Do you honestly believe there will be in any way a detectable difference? > Having a daemon that sits in user space and waits for system events > (denoted by enumerated values in some /proc or /dev file) seems simple > enough. Yes, but text strings are simpler. You don't have to export magic numbers in some kernel header (causing no end of woe). You can just cat /proc/pm/events to the console and understand it, and just about anybody with the rudiments of knowledge about programming in any language can write an event handler - even without having to know hardly anything about or look at the kernel source because the interface is so transparent and simple. > When it gets the request to power down, it handles calling init and > whatever else it wants to do. When it gets notification that the > laptop was plugged into the base station, it can look for new > devices and load the modules for them. Exactly. Right. Bang on target - but with text strings you can do it in a line or two of perl, and the kernel side is not made any more complex. > This can also handle the user-dictated policy, which I haven't seen > discussed yet. For instance, when you close the lid or press the power > button, the system can enter suspend or it can power off. If the kernel > simply exported the event, the userspace daemon could simply check its > config file for the proper thing to do and initiate the transition. Exactly what I was suggesting. In this case, you'd get the event SLEEP ACPI Laptop case closed and your perl script could do something vaguely like /ACPI Laptop case closed$/ && system "shutdown -p now"; to turn the machine off instead of sleeping. [...] > > sleep - writing a number n (text encoded) sends the device to > > sleep in such a way that it can be back in action in no less > > than n seconds after a wakeup call on a vague guess > > basis. Reading from it gets errno. Probably microseconds would be a more useful unit. > > off - writing to this node puts device in deepest possible > > sleep, possibly losing state. Reading gets errno. > > Sure, but does it really make sense for anything but system sleep > states? ACPI defines a mechnanism for runtime power management, > where devices will go into sleep states if they're not being > used. Given proper heuristics for controlling this, user-initiated > suspension of individual devices doesn't seem necessary. And, given > a proper abstraction in the PM layer, this should be extendable, to > some extent, to other low-level PM schemes. OK, so add another node, something like boredafter - writing a number of milliseconds tells device to go to some sort of sleep after that time has elapsed without activity. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel <[EMAIL PROTECTED]> writes: > > > IMHO the pm interface should be split up as following: > > > > Nobody has disagreed: therefore this separation must be perfect ;-) > > I once heard that patience is a virtue. :) > > > > (1) Battery status, power status, UPS status polling. It > > > should be possible for lots of processes to do this > > > simultaneously. [That does not prohibit a single process > > > querying the kernel and all the others querying it.] > > > > Solution. Have a bunch of procfs or dev nodes each giving info on a > > particular power source, like now, but vaguely standardise the output. [...] > I can see at least two types of events - (forgive the lack of colorful > terminology) passive and active. Passive events are simply providing > status updates, much like the events described above. These are simply so > some UI can notify the user of things like a low battery or detection of > an AC adapter. These can be handled in much the same way as described > above. No they can't. They only happen once. Battery status exists all the time. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel [EMAIL PROTECTED] writes: IMHO the pm interface should be split up as following: Nobody has disagreed: therefore this separation must be perfect ;-) I once heard that patience is a virtue. :) (1) Battery status, power status, UPS status polling. It should be possible for lots of processes to do this simultaneously. [That does not prohibit a single process querying the kernel and all the others querying it.] Solution. Have a bunch of procfs or dev nodes each giving info on a particular power source, like now, but vaguely standardise the output. [...] I can see at least two types of events - (forgive the lack of colorful terminology) passive and active. Passive events are simply providing status updates, much like the events described above. These are simply so some UI can notify the user of things like a low battery or detection of an AC adapter. These can be handled in much the same way as described above. No they can't. They only happen once. Battery status exists all the time. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel [EMAIL PROTECTED] writes: [...] Solution. Have a special procfs or dev node that any number of people can select(2) or read(2). Protocol text. Syntax: event WS subsystem WS description LF Where event is one of the strings OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, WS is a space character, subsystem is a word signifying the kernel pm interface responsible for generating th event, description is an arbitrary string. LF is a newline character \n. This is flexible and simple. It means a reasonable default behaviour can be suggested by the kernel (OFF,SLEEP,etc.) for events that userspace doesn't know about and yet userspace can choose fine grained policy and provide helpful error messages based on the exact event by checking the description. First, Is there any reason why the kernel should do more text processing? Kernel does no text processing. Kernel merely gives text instead of magic numbers to the stream of bytes. It is better left for user space. Besides, enumerated values translated by userspace seems more efficient than copying and parsing strings. Oh? Do you honestly believe there will be in any way a detectable difference? Having a daemon that sits in user space and waits for system events (denoted by enumerated values in some /proc or /dev file) seems simple enough. Yes, but text strings are simpler. You don't have to export magic numbers in some kernel header (causing no end of woe). You can just cat /proc/pm/events to the console and understand it, and just about anybody with the rudiments of knowledge about programming in any language can write an event handler - even without having to know hardly anything about or look at the kernel source because the interface is so transparent and simple. When it gets the request to power down, it handles calling init and whatever else it wants to do. When it gets notification that the laptop was plugged into the base station, it can look for new devices and load the modules for them. Exactly. Right. Bang on target - but with text strings you can do it in a line or two of perl, and the kernel side is not made any more complex. This can also handle the user-dictated policy, which I haven't seen discussed yet. For instance, when you close the lid or press the power button, the system can enter suspend or it can power off. If the kernel simply exported the event, the userspace daemon could simply check its config file for the proper thing to do and initiate the transition. Exactly what I was suggesting. In this case, you'd get the event SLEEP ACPI Laptop case closed and your perl script could do something vaguely like /ACPI Laptop case closed$/ system "shutdown -p now"; to turn the machine off instead of sleeping. [...] sleep - writing a number n (text encoded) sends the device to sleep in such a way that it can be back in action in no less than n seconds after a wakeup call on a vague guess basis. Reading from it gets errno. Probably microseconds would be a more useful unit. off - writing to this node puts device in deepest possible sleep, possibly losing state. Reading gets errno. Sure, but does it really make sense for anything but system sleep states? ACPI defines a mechnanism for runtime power management, where devices will go into sleep states if they're not being used. Given proper heuristics for controlling this, user-initiated suspension of individual devices doesn't seem necessary. And, given a proper abstraction in the PM layer, this should be extendable, to some extent, to other low-level PM schemes. OK, so add another node, something like boredafter - writing a number of milliseconds tells device to go to some sort of sleep after that time has elapsed without activity. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Next gen PM interface
Patrick Mochel [EMAIL PROTECTED] writes: [...] I can see at least two types of events - (forgive the lack of colorful terminology) passive and active. Passive events are simply providing status updates, much like the events described above. These are simply so some UI can notify the user of things like a low battery or detection of an AC adapter. These can be handled in much the same way as described above. No they can't. They only happen once. Battery status exists all the time. Yes they can. My point was they can be handled from userspace in the same way that battery status does - by doing a select on a file in /proc or /dev. Once in a while (or constantly) they get data from the kernel - battery status, AC change, etc - that can be then translated and displayed in the UI. I think these events have a generic utility not specific to UIs. In particular, when ones battery is running out, one would quite like the event manager to be notified. As is currently the case with e.g. apmd. Polling on battery charge left or battery voltage/current is different from this, surely? Why should such programs have to be notified that the battery was low? The event itself is pretty useless if you're doing polling but there is no point throwing it away, in case you aren't. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Next gen PM interface
John Fremlin <[EMAIL PROTECTED]> writes: [...] > IMHO the pm interface should be split up as following: Nobody has disagreed: therefore this separation must be perfect ;-) > (1) Battery status, power status, UPS status polling. It > should be possible for lots of processes to do this > simultaneously. [That does not prohibit a single process > querying the kernel and all the others querying it.] Solution. Have a bunch of procfs or dev nodes each giving info on a particular power source, like now, but vaguely standardise the output. > (2) Funky events happening to the physical machine, like a > button being pressed, the case being closed, etc. [Should this > include battery low warnings, power status changes? I don't > know.] Solution. Have a special procfs or dev node that any number of people can select(2) or read(2). Protocol text. Syntax: Where is one of the strings OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, is a space character, is a word signifying the kernel pm interface responsible for generating th event, is an arbitrary string. is a newline character \n. This is flexible and simple. It means a reasonable default behaviour can be suggested by the kernel (OFF,SLEEP,etc.) for events that userspace doesn't know about and yet userspace can choose fine grained policy and provide helpful error messages based on the exact event by checking the description. [...] > (3) Sending the machine to sleep, turning it off. It should be > possible to do this from userspace ;-) I would suggest that all pm capable objects should be able to be controlled individually. E.g. you should be able to send your monitor to sleep alone, leaving other stuff running. Fbdrivers are already capable of this on some archs. IOW I suggest a nice FS with a dir per PM capable device. In this dir would be name - descriptive text name of device class wake - writing to this node wakes device sleep - writing a number n (text encoded) sends the device to sleep in such a way that it can be back in action in no less than n seconds after a wakeup call on a vague guess basis. Reading from it gets errno. off - writing to this node puts device in deepest possible sleep, possibly losing state. Reading gets errno. Like the proc/sys/net/ipv4/neigh stuff you can have an all/ dir that'd try to whatever to everything. Hotunplug can be handled. Any objections? Would such a patch be accepted by the powers that be? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: [...] > > ACPI != PM. I don't see why ACPI details should be exposed to PM > > interface at all. > > ACPI has by far the richest set of capabilities. It is a superset of > APM. Therefore a combined APM/ACPI interface is going to look a lot > like an ACPI interface. First, lets stop being so Intel/x86 centric ;-) There are more PM interfaces than APM/ACPI as Stephen Rothwell pointed out to me: more are already supported by the kernel. PPC has one, ARM has one, etc. And that's not even touching on UPSs and miscellaneous portable whatnots with their own special PM bits and pieces like IBM laptops. ACPI might be able to handle all that but it would require a very complex interface, if what I've seen of ACPI is anything to go by. Is this correct? A much simpler interface might not lose much functionality. > IMHO an abstracted interface at this point is overengineering. Maybe > later it will make sense, though. Each PM scheme has its own daemon and suspend/sleep tools at the moment. It makes sense to have just one daemon and toolset so that advanced functionality can be shared. Should the kernel present a common interface like HID, or should the daemon be able to understand all the various protocols (like gpm for mice)? -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Avery Pennarun <[EMAIL PROTECTED]> writes: > On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote: > > > > willing to exercise this power. We would not break compatibility with > > > any std kernel by instead having a apmd send a "reject all" ioctl > > > instead, and so deal with events without having the pressure of having > > > to reject or accept them, and let us remove all the veto code from the > > > kernel driver. Or am I missing something? > > > > That sounds workable. But the same program could reply to the events just > > as well as issue the ioctl 8) > > AFAICT some APM BIOSes get impatient if you don't acknowledge/reject > the requests fast enough, and start to go bananas. By always > rejecting requests and then making user requests instead at some > time later, we might eliminate this problem (or just cause new > ones). Indeed. Neither proposal has however received wide testing as far as I know. The userspace ACCEPT/REJECT method was available as a patch from Stephen for a while though. > Also, I don't think the "critical suspend" message can be rejected > at all, so it would have to be a special case where currently I > don't think it's too bad. ATM it is a "special case" - we print a message if we try to reject a critical suspend. However the case is not so special that it requires more than a line or two ;-) I don't think there is any cause for concern on that front. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: > > willing to exercise this power. We would not break compatibility > > with any std kernel by instead having a apmd send a "reject all" > > ioctl instead, and so deal with events without having the pressure > > of having to reject or accept them, and let us remove all the veto > > code from the kernel driver. Or am I missing something? > > That sounds workable. But the same program could reply to the events > just as well as issue the ioctl 8) Having more than one program holding the veto on each event is a bit of a hassle. Keeping track of "replies" is also a bit of a hassle. It'd be simpler to let userspace handle everything in line with e.g. the ACPI power button press, and suspend or turn off the machine in the normal manner. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Simon Richter <[EMAIL PROTECTED]> writes: [...] > Yes, that will be a separate daemon that will also get the > events. But I think it's a good idea to have a simple interface that > allows the user to run arbitrary commands when ACPI events occur, > even without acpid running (think of singleuser mode, embedded > systems, ...). The pmpolicy patch presents such a simple interface. An executable (the location of which is configurable) is run from the kernel with certain arguments. The advantages of this: (1) No nasty magic number binary interface, everything is text -> (2) Any sysadmin can easily write an event handler in sh, perl, or whatever scripting language, i.e. the userspace handler is much simpler. (3) No events, no bloat. (4) Kernel code is probably shorter (tho' less standard) than having a special device or procfs node. (5) Efficiency: the alternative is to have a program like APMD decoding the nasty binary interface and then spawning a shell script to deal with it. I myself am starting to dislike the idea: it was mostly motivated by the need to exercise a veto on APM events. This is in fact not necessary, if I understand correctly. An interface allowing multiple listeners is preferable. It remains to contact all the maintainers of the various PM and UPS systems to flesh out exactly what the interface should be capable of ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: [...] > Fair enough. I don't think I would be out of line to say that our > resources are focused on enabling full ACPI functionality for Linux, > including a full-featured PM policy daemon. That said, I don't think > there's anything precluding the use of another daemon (or whatever) > from using the ACPI driver's interface. ACPI != PM. I don't see why ACPI details should be exposed to PM interface at all. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: > > I'm wondering if that veto business is really needed. Why not reject > > *all* APM rejectable events, and then let the userspace event handler > > send the system to sleep or turn it off? Anybody au fait with the APM > > spec? > > Because apmd is optional The veto stuff only comes into action, iff someone has registered as willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a "reject all" ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox [EMAIL PROTECTED] writes: I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? Because apmd is optional The veto stuff only comes into action, iff someone has registered as willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a "reject all" ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes: [...] Fair enough. I don't think I would be out of line to say that our resources are focused on enabling full ACPI functionality for Linux, including a full-featured PM policy daemon. That said, I don't think there's anything precluding the use of another daemon (or whatever) from using the ACPI driver's interface. ACPI != PM. I don't see why ACPI details should be exposed to PM interface at all. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Simon Richter [EMAIL PROTECTED] writes: [...] Yes, that will be a separate daemon that will also get the events. But I think it's a good idea to have a simple interface that allows the user to run arbitrary commands when ACPI events occur, even without acpid running (think of singleuser mode, embedded systems, ...). The pmpolicy patch presents such a simple interface. An executable (the location of which is configurable) is run from the kernel with certain arguments. The advantages of this: (1) No nasty magic number binary interface, everything is text - (2) Any sysadmin can easily write an event handler in sh, perl, or whatever scripting language, i.e. the userspace handler is much simpler. (3) No events, no bloat. (4) Kernel code is probably shorter (tho' less standard) than having a special device or procfs node. (5) Efficiency: the alternative is to have a program like APMD decoding the nasty binary interface and then spawning a shell script to deal with it. I myself am starting to dislike the idea: it was mostly motivated by the need to exercise a veto on APM events. This is in fact not necessary, if I understand correctly. An interface allowing multiple listeners is preferable. It remains to contact all the maintainers of the various PM and UPS systems to flesh out exactly what the interface should be capable of ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox [EMAIL PROTECTED] writes: willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a "reject all" ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? That sounds workable. But the same program could reply to the events just as well as issue the ioctl 8) Having more than one program holding the veto on each event is a bit of a hassle. Keeping track of "replies" is also a bit of a hassle. It'd be simpler to let userspace handle everything in line with e.g. the ACPI power button press, and suspend or turn off the machine in the normal manner. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Avery Pennarun [EMAIL PROTECTED] writes: On Wed, Apr 18, 2001 at 09:10:37PM +0100, Alan Cox wrote: willing to exercise this power. We would not break compatibility with any std kernel by instead having a apmd send a "reject all" ioctl instead, and so deal with events without having the pressure of having to reject or accept them, and let us remove all the veto code from the kernel driver. Or am I missing something? That sounds workable. But the same program could reply to the events just as well as issue the ioctl 8) AFAICT some APM BIOSes get impatient if you don't acknowledge/reject the requests fast enough, and start to go bananas. By always rejecting requests and then making user requests instead at some time later, we might eliminate this problem (or just cause new ones). Indeed. Neither proposal has however received wide testing as far as I know. The userspace ACCEPT/REJECT method was available as a patch from Stephen for a while though. Also, I don't think the "critical suspend" message can be rejected at all, so it would have to be a special case where currently I don't think it's too bad. ATM it is a "special case" - we print a message if we try to reject a critical suspend. However the case is not so special that it requires more than a line or two ;-) I don't think there is any cause for concern on that front. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes: [...] ACPI != PM. I don't see why ACPI details should be exposed to PM interface at all. ACPI has by far the richest set of capabilities. It is a superset of APM. Therefore a combined APM/ACPI interface is going to look a lot like an ACPI interface. First, lets stop being so Intel/x86 centric ;-) There are more PM interfaces than APM/ACPI as Stephen Rothwell pointed out to me: more are already supported by the kernel. PPC has one, ARM has one, etc. And that's not even touching on UPSs and miscellaneous portable whatnots with their own special PM bits and pieces like IBM laptops. ACPI might be able to handle all that but it would require a very complex interface, if what I've seen of ACPI is anything to go by. Is this correct? A much simpler interface might not lose much functionality. IMHO an abstracted interface at this point is overengineering. Maybe later it will make sense, though. Each PM scheme has its own daemon and suspend/sleep tools at the moment. It makes sense to have just one daemon and toolset so that advanced functionality can be shared. Should the kernel present a common interface like HID, or should the daemon be able to understand all the various protocols (like gpm for mice)? -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Next gen PM interface
John Fremlin [EMAIL PROTECTED] writes: [...] IMHO the pm interface should be split up as following: Nobody has disagreed: therefore this separation must be perfect ;-) (1) Battery status, power status, UPS status polling. It should be possible for lots of processes to do this simultaneously. [That does not prohibit a single process querying the kernel and all the others querying it.] Solution. Have a bunch of procfs or dev nodes each giving info on a particular power source, like now, but vaguely standardise the output. (2) Funky events happening to the physical machine, like a button being pressed, the case being closed, etc. [Should this include battery low warnings, power status changes? I don't know.] Solution. Have a special procfs or dev node that any number of people can select(2) or read(2). Protocol text. Syntax: event WS subsystem WS description LF Where event is one of the strings OFF,SLEEP,WAKE,EMERGENCY,POWERCHANGE, WS is a space character, subsystem is a word signifying the kernel pm interface responsible for generating th event, description is an arbitrary string. LF is a newline character \n. This is flexible and simple. It means a reasonable default behaviour can be suggested by the kernel (OFF,SLEEP,etc.) for events that userspace doesn't know about and yet userspace can choose fine grained policy and provide helpful error messages based on the exact event by checking the description. [...] (3) Sending the machine to sleep, turning it off. It should be possible to do this from userspace ;-) I would suggest that all pm capable objects should be able to be controlled individually. E.g. you should be able to send your monitor to sleep alone, leaving other stuff running. Fbdrivers are already capable of this on some archs. IOW I suggest a nice FS with a dir per PM capable device. In this dir would be name - descriptive text name of device class wake - writing to this node wakes device sleep - writing a number n (text encoded) sends the device to sleep in such a way that it can be back in action in no less than n seconds after a wakeup call on a vague guess basis. Reading from it gets errno. off - writing to this node puts device in deepest possible sleep, possibly losing state. Reading gets errno. Like the proc/sys/net/ipv4/neigh stuff you can have an all/ dir that'd try to whatever to everything. Hotunplug can be handled. Any objections? Would such a patch be accepted by the powers that be? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox <[EMAIL PROTECTED]> writes: [...] > I would tend to agree here. If you want to wire it to init the fine > but pm is basically message passing kernel->user and possibly > message reply to allow veto/approve. APM provides a good API for > this and there is a definite incentive to make ACPI use the same > messages, behaviour and extend it. I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? This would have the advantage that the veto stuff could be ripped out and things made simpler. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > [do we want to move this to linux-power?] I'm happy to as long as I'm cc'd. [...] IMHO the pm interface should be split up as following: (1) Battery status, power status, UPS status polling. It should be possible for lots of processes to do this simultaneously. [That does not prohibit a single process querying the kernel and all the others querying it.] (2) Funky events happening to the physical machine, like a button being pressed, the case being closed, etc. [Should this include battery low warnings, power status changes? I don't know.] (3) Sending the machine to sleep, turning it off. It should be possible to do this from userspace ;-) Am I missing anything? Of course (1) and (2) could be combined into a single daemon. ATM the area is fraught with incompatibility. There are a ridiculous number of power management systems - one per architecture almost. Each has a different kernel-userspace interface. Every UPS has its own interface too (?) ;-) > There should be only one PM policy agent on the system. Why? As far as I see it, only some people need polling capabilities - i.e. those on battery or UPS. Why should they be subjected to the bloat etc. And those on battery might want multiple policies as Alan pointed out. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > Hi Pavel, > > I think init is doing a perfect job WRT UPSs because this is a > trivial application of power management. init wasn't really meant > for this. According to its man page: > > "init...it's primary role is to create processes from a script in > the file /etc/inittab...It also controls autonomous processes > required by any particular system" > > We are going to need some software that handles button events, as > well as thermal events, battery events, polling the battery, AC > adapter status changes, sleeping the system, and more. Dealing with events should be disjoint from polling the battery or powerstatus. Many processes might reasonably simultaneously want to provide a display to the user of the current power status. However, button presses and so on should be handled by a single process. Otherwise the kernel is unreasonably complicated by having to deal with multiple processes' veto power, which could just as well and more flexibly be handled in userspace. I don't why there needs to be an additional daemon constantly running to deal with button presses and power status changes. Apparently init is already handling similar things: why should it not be extended to include button presses? Alternatively, why not forgo a daemon altogether? (This scheme is already implemented in the pmpolicy patch, i.e. it is already working.) > We need WAY more flexibility than init provides. Examples please. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes: > > From: Pavel Machek [mailto:[EMAIL PROTECTED]] > > There are 32 signals, and signals can carry more information, if > > required. I really think doing it way UPS-es are done is right > > approach. > I would think that it would make sense to keep shutdown with all the > other power management events. Perhaps it will makes more sense to > handle UPS's through the power management code. I'm happy add UPS functionality to the pmpolicy patch, if someone were willing to test it - as I have no UPS ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes: From: Pavel Machek [mailto:[EMAIL PROTECTED]] There are 32 signals, and signals can carry more information, if required. I really think doing it way UPS-es are done is right approach. I would think that it would make sense to keep shutdown with all the other power management events. Perhaps it will makes more sense to handle UPS's through the power management code. I'm happy add UPS functionality to the pmpolicy patch, if someone were willing to test it - as I have no UPS ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes: Hi Pavel, I think init is doing a perfect job WRT UPSs because this is a trivial application of power management. init wasn't really meant for this. According to its man page: "init...it's primary role is to create processes from a script in the file /etc/inittab...It also controls autonomous processes required by any particular system" We are going to need some software that handles button events, as well as thermal events, battery events, polling the battery, AC adapter status changes, sleeping the system, and more. Dealing with events should be disjoint from polling the battery or powerstatus. Many processes might reasonably simultaneously want to provide a display to the user of the current power status. However, button presses and so on should be handled by a single process. Otherwise the kernel is unreasonably complicated by having to deal with multiple processes' veto power, which could just as well and more flexibly be handled in userspace. I don't why there needs to be an additional daemon constantly running to deal with button presses and power status changes. Apparently init is already handling similar things: why should it not be extended to include button presses? Alternatively, why not forgo a daemon altogether? (This scheme is already implemented in the pmpolicy patch, i.e. it is already working.) We need WAY more flexibility than init provides. Examples please. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes: [do we want to move this to linux-power?] I'm happy to as long as I'm cc'd. [...] IMHO the pm interface should be split up as following: (1) Battery status, power status, UPS status polling. It should be possible for lots of processes to do this simultaneously. [That does not prohibit a single process querying the kernel and all the others querying it.] (2) Funky events happening to the physical machine, like a button being pressed, the case being closed, etc. [Should this include battery low warnings, power status changes? I don't know.] (3) Sending the machine to sleep, turning it off. It should be possible to do this from userspace ;-) Am I missing anything? Of course (1) and (2) could be combined into a single daemon. ATM the area is fraught with incompatibility. There are a ridiculous number of power management systems - one per architecture almost. Each has a different kernel-userspace interface. Every UPS has its own interface too (?) ;-) There should be only one PM policy agent on the system. Why? As far as I see it, only some people need polling capabilities - i.e. those on battery or UPS. Why should they be subjected to the bloat etc. And those on battery might want multiple policies as Alan pointed out. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Alan Cox [EMAIL PROTECTED] writes: [...] I would tend to agree here. If you want to wire it to init the fine but pm is basically message passing kernel-user and possibly message reply to allow veto/approve. APM provides a good API for this and there is a definite incentive to make ACPI use the same messages, behaviour and extend it. I'm wondering if that veto business is really needed. Why not reject *all* APM rejectable events, and then let the userspace event handler send the system to sleep or turn it off? Anybody au fait with the APM spec? This would have the advantage that the veto stuff could be ripped out and things made simpler. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [new PATCH] Re: 8139too: defunct threads
Andrew Morton <[EMAIL PROTECTED]> writes:
[...]
> None of these will work. The problems with globally setting
> exit_signal to SIGCHLD are that
>
> a) If the parent does waitpid(pid, status, __WCLONE), the
>waitpid will fail. request_module() does this. I don't
>know _why_ it does this. Maybe it's bogus. There is no
>explanation.
waitpid doesn't work on cloned children unless you put in __WCLONE or
__WALL, so this was necessary to catch the child at all. If you set to
use SIGCHLD this will no longer be needed (if I understand correctly).
[...]
> So it seems that we must reparent the thread to init, and
> make sure that it delivers SIGCHLD to init when it exits.
Sounds good. Why isn't SIGCHLD a stronger default anyway.
[...]
> + /* Set the exit signal to SIGCHLD so we signal init on exit */
> + if (this_task->exit_signal ! 0) {
Tyop.
> + printk(KERN_ERR "task `%s' exit_signal %d in daemonize()\n",
> + this_task->comm, this_task->exit_signal);
> + }
> + this_task->exit_signal = SIGCHLD;
> +
> + write_unlock_irq(_lock);
> }
>
> void __init init_idle(void)
>
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [new PATCH] Re: 8139too: defunct threads
Andrew Morton [EMAIL PROTECTED] writes:
[...]
None of these will work. The problems with globally setting
exit_signal to SIGCHLD are that
a) If the parent does waitpid(pid, status, __WCLONE), the
waitpid will fail. request_module() does this. I don't
know _why_ it does this. Maybe it's bogus. There is no
explanation.
waitpid doesn't work on cloned children unless you put in __WCLONE or
__WALL, so this was necessary to catch the child at all. If you set to
use SIGCHLD this will no longer be needed (if I understand correctly).
[...]
So it seems that we must reparent the thread to init, and
make sure that it delivers SIGCHLD to init when it exits.
Sounds good. Why isn't SIGCHLD a stronger default anyway.
[...]
+ /* Set the exit signal to SIGCHLD so we signal init on exit */
+ if (this_task-exit_signal ! 0) {
Tyop.
+ printk(KERN_ERR "task `%s' exit_signal %d in daemonize()\n",
+ this_task-comm, this_task-exit_signal);
+ }
+ this_task-exit_signal = SIGCHLD;
+
+ write_unlock_irq(tasklist_lock);
}
void __init init_idle(void)
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" <[EMAIL PROTECTED]> writes: > "John Fremlin" <[EMAIL PROTECTED]> writes: > > "Adam J. Richter" <[EMAIL PROTECTED]> writes: > >>Guess why you're seeing this email. That's right. Linux-2.4.3's > >> fork() does not run the child first. > > >[...] If an app wants to fork and exec, it > >should use *vfork* and exec, which is a performance win across many > >OSs because the COW mappings don't even have to be set up, IIRC. > > Even in that case, you want to run the child first because The parent is not allowed to run until the child execs, if I understand correctly. Read up on CLONE_VFORK. [...] > Of course, in the vfork case, this change is probably only a very > small win. The real advantage is with regular fork() followed by an > exec, which happens quite a lot. For example, I do not see vfork > anywhere in the bash sources. If it is a real advantage you can get a bigger advantage by changing the app to use vfork, i.e. you can solve the problem (if it exists) better without hacking the kernel. Further, your change will hurt those apps which expect the parent to be given a fair chance, so you'll need to add a fairfork(2) syscall to comply with Californian anti age discrimmination legislation (humour). In fact, if you think fork+exec is such a big performance hit why not go for spawn(2) and have Linus and Al jump on you? ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" <[EMAIL PROTECTED]> writes: [...] > It turned out that the particular unix-like system on which > these benchmarks were taken had a version of fork that did not run > the child first. As it was explained to me then, most of the time, > the child process from a fork will do just a few things and then do > an exec(), releasing its copy-on-write references to the parent's > pages, and that is the big win of copy-on-write for fork() in practice. > This oversight was considered a big embarassment for the operating > system in question, so I won't name it here. > > Guess why you're seeing this email. That's right. Linux-2.4.3's > fork() does not run the child first. Not always, if I understand correctly. Setting to always is putting policy in kernel in a small way. If an app wants to fork and exec, it should use *vfork* and exec, which is a performance win across many OSs because the COW mappings don't even have to be set up, IIRC. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" [EMAIL PROTECTED] writes: [...] It turned out that the particular unix-like system on which these benchmarks were taken had a version of fork that did not run the child first. As it was explained to me then, most of the time, the child process from a fork will do just a few things and then do an exec(), releasing its copy-on-write references to the parent's pages, and that is the big win of copy-on-write for fork() in practice. This oversight was considered a big embarassment for the operating system in question, so I won't name it here. Guess why you're seeing this email. That's right. Linux-2.4.3's fork() does not run the child first. Not always, if I understand correctly. Setting to always is putting policy in kernel in a small way. If an app wants to fork and exec, it should use *vfork* and exec, which is a performance win across many OSs because the COW mappings don't even have to be set up, IIRC. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH(?): linux-2.4.4-pre2: fork should run child first
"Adam J. Richter" [EMAIL PROTECTED] writes: "John Fremlin" [EMAIL PROTECTED] writes: "Adam J. Richter" [EMAIL PROTECTED] writes: Guess why you're seeing this email. That's right. Linux-2.4.3's fork() does not run the child first. [...] If an app wants to fork and exec, it should use *vfork* and exec, which is a performance win across many OSs because the COW mappings don't even have to be set up, IIRC. Even in that case, you want to run the child first because The parent is not allowed to run until the child execs, if I understand correctly. Read up on CLONE_VFORK. [...] Of course, in the vfork case, this change is probably only a very small win. The real advantage is with regular fork() followed by an exec, which happens quite a lot. For example, I do not see vfork anywhere in the bash sources. If it is a real advantage you can get a bigger advantage by changing the app to use vfork, i.e. you can solve the problem (if it exists) better without hacking the kernel. Further, your change will hurt those apps which expect the parent to be given a fair chance, so you'll need to add a fairfork(2) syscall to comply with Californian anti age discrimmination legislation (humour). In fact, if you think fork+exec is such a big performance hit why not go for spawn(2) and have Linus and Al jump on you? ;-) [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
[...]
> > > > + printk ("acpi: Power button pressed!\n");
> >
> > [...]
> >
> > > > + printk("acpi: Sleep button pressed!\n");
> >
> > Do you think you could keep the above part of the patch? It would be
> > nice to know how much of ACPI was actually working ;-)
> I'm hesitant to do this, since 1) You can put those printk's in
> yourself to find out if your particular system is working and 2) You
> can just cat /proc/sys/event, hit a button, and you should see
> output if it works.
Hmm. Pavel Machek could hardly be described as a newbie at hacking
stuff, and yet he says, "I hunted bug for few hours, thinking that
kernel does not get the event at all."
The printks are certainly clearer than cat'ing some binary garbage to
the console and will help out the casual user who doesn't want to
recompile kernel and reboot just to discover that the damn thing
doesn't work.
[...]
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: > Hi! > > > This is not correct, because we want the power button to be > > configurable. The user should be able to redefine the power > > button's action, perhaps to only sleep the system. We currently > > surface button events to acpid, which then can do the right thing, > > including a shutdown -h now (which I assume notifies init). > > There's no problem with configurability -- you can configure init as > well. I saw it pretty much analogic to situation with Ctrl-Alt-Del: > it also sends signal to init. Init then decides what to do. [I > believe requiring acpid for such easy stuff is not neccessary...] Using a signal to hit init with is a bit dubious because most signals are hooked up for something else already. For example, SIGTERM sent to my init (http://john.snoop.dk/programs/linux/jinit) would shutdown and start sulogin, which is probably not what you want when you press the off button. The FreeBSD init is similar FWIW (goes to single user mode). Some PM interfaces (e.g. APM) require a descision to be made by software on such an event (to turn off or to "reject"). IMHO the best way to do this is to exec a small script from kernelspace to get the user's preferred policy; this is lighter weight than a daemon, doesn't require some nasty magic number interface, and can be easily programmed by any admin knowing sh or perl or whatever. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
John R Lenton <[EMAIL PROTECTED]> writes: [...] > Just today a friend saw my box shutdown via the powerbutton and > wondered if he coudln't set his up to trigger a different event > (actually two: he wanted his sister - the guilty party - zapped, and > a webcam shot of her face to prove it)... That is in fact possible (given that you have the zapper) on certain hardware with my pmpolicy patch http://john.snoop.dk/programs/linux/offbutton It uses APM instead of ACPI because ACPI doesn't work on my computer. I have an updated version of the patch for 2.4.2, but I haven't got round to uploading it. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" <[EMAIL PROTECTED]> writes:
> This is not correct, because we want the power button to be
> configurable. The user should be able to redefine the power
> button's action, perhaps to only sleep the system. We currently
> surface button events to acpid, which then can do the right thing,
> including a shutdown -h now (which I assume notifies init).
That's just fine and dandy, but
[...]
> > + printk ("acpi: Power button pressed!\n");
[...]
> > + printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was actually working ;-)
[...]
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes:
This is not correct, because we want the power button to be
configurable. The user should be able to redefine the power
button's action, perhaps to only sleep the system. We currently
surface button events to acpid, which then can do the right thing,
including a shutdown -h now (which I assume notifies init).
That's just fine and dandy, but
[...]
+ printk ("acpi: Power button pressed!\n");
[...]
+ printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was actually working ;-)
[...]
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
John R Lenton [EMAIL PROTECTED] writes: [...] Just today a friend saw my box shutdown via the powerbutton and wondered if he coudln't set his up to trigger a different event (actually two: he wanted his sister - the guilty party - zapped, and a webcam shot of her face to prove it)... That is in fact possible (given that you have the zapper) on certain hardware with my pmpolicy patch http://john.snoop.dk/programs/linux/offbutton It uses APM instead of ACPI because ACPI doesn't work on my computer. I have an updated version of the patch for 2.4.2, but I haven't got round to uploading it. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
Pavel Machek [EMAIL PROTECTED] writes: Hi! This is not correct, because we want the power button to be configurable. The user should be able to redefine the power button's action, perhaps to only sleep the system. We currently surface button events to acpid, which then can do the right thing, including a shutdown -h now (which I assume notifies init). There's no problem with configurability -- you can configure init as well. I saw it pretty much analogic to situation with Ctrl-Alt-Del: it also sends signal to init. Init then decides what to do. [I believe requiring acpid for such easy stuff is not neccessary...] Using a signal to hit init with is a bit dubious because most signals are hooked up for something else already. For example, SIGTERM sent to my init (http://john.snoop.dk/programs/linux/jinit) would shutdown and start sulogin, which is probably not what you want when you press the off button. The FreeBSD init is similar FWIW (goes to single user mode). Some PM interfaces (e.g. APM) require a descision to be made by software on such an event (to turn off or to "reject"). IMHO the best way to do this is to exec a small script from kernelspace to get the user's preferred policy; this is lighter weight than a daemon, doesn't require some nasty magic number interface, and can be easily programmed by any admin knowing sh or perl or whatever. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Let init know user wants to shutdown
"Grover, Andrew" [EMAIL PROTECTED] writes:
[...]
+ printk ("acpi: Power button pressed!\n");
[...]
+ printk("acpi: Sleep button pressed!\n");
Do you think you could keep the above part of the patch? It would be
nice to know how much of ACPI was actually working ;-)
I'm hesitant to do this, since 1) You can put those printk's in
yourself to find out if your particular system is working and 2) You
can just cat /proc/sys/event, hit a button, and you should see
output if it works.
Hmm. Pavel Machek could hardly be described as a newbie at hacking
stuff, and yet he says, "I hunted bug for few hours, thinking that
kernel does not get the event at all."
The printks are certainly clearer than cat'ing some binary garbage to
the console and will help out the casual user who doesn't want to
recompile kernel and reboot just to discover that the damn thing
doesn't work.
[...]
--
http://www.penguinpowered.com/~vii
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: how to let all others run
"Richard B. Johnson" <[EMAIL PROTECTED]> writes: > On 4 Apr 2001, John Fremlin wrote: > > > > Hi Oliver! > > > > Oliver Neukum <[EMAIL PROTECTED]> writes: > > > > > is there a way to let all other runable tasks run until they block > > > or return to user space, before the task wishing to do so is run > > > again ? > > > > Are you trying to do this in kernel or something? From userspace you > > can use nice(2) then sched_yield(2), though I don't know if the linux > > implementations will guarrantee anything. > > > > I recommend using usleep(0) instead of sched_yield(). Last time I > checked, sched_yield() seemed to spin and eat CPU cycles, usleep(0) > always gives up the CPU. What is wrong with this? sched_yield only yields to processes with lower priority (hence suggestion to use nice(2)). Does sched_yield() fail to yield in cases when a higher priority process wants to run? usleep() wastes time if no other such process is waiting, surely? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to let all others run
"Richard B. Johnson" [EMAIL PROTECTED] writes: On 4 Apr 2001, John Fremlin wrote: Hi Oliver! Oliver Neukum [EMAIL PROTECTED] writes: is there a way to let all other runable tasks run until they block or return to user space, before the task wishing to do so is run again ? Are you trying to do this in kernel or something? From userspace you can use nice(2) then sched_yield(2), though I don't know if the linux implementations will guarrantee anything. I recommend using usleep(0) instead of sched_yield(). Last time I checked, sched_yield() seemed to spin and eat CPU cycles, usleep(0) always gives up the CPU. What is wrong with this? sched_yield only yields to processes with lower priority (hence suggestion to use nice(2)). Does sched_yield() fail to yield in cases when a higher priority process wants to run? usleep() wastes time if no other such process is waiting, surely? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to let all others run
Hi Oliver! Oliver Neukum <[EMAIL PROTECTED]> writes: > is there a way to let all other runable tasks run until they block > or return to user space, before the task wishing to do so is run > again ? Are you trying to do this in kernel or something? From userspace you can use nice(2) then sched_yield(2), though I don't know if the linux implementations will guarrantee anything. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to let all others run
Hi Oliver! Oliver Neukum [EMAIL PROTECTED] writes: is there a way to let all other runable tasks run until they block or return to user space, before the task wishing to do so is run again ? Are you trying to do this in kernel or something? From userspace you can use nice(2) then sched_yield(2), though I don't know if the linux implementations will guarrantee anything. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code (PR#128)
[EMAIL PROTECTED] writes: [...] > > AFAICS. I hacked together the following patch for it a while ago, > > which updated APM_IOC_REJECT for slightly more recent kernels (be > > warned, I think I made some mistakes) > > Thanks for this, I will review it and post a patch based on it (with > due accredition of course). Not sure that would be an altogether good idea, because I think I made a bit of a hash of it ;-) Did you get Albert Cranford's version? I would recommend it over mine (though I have not yet looked at it). [...] > I did not say the I did not "like the idea of me implementing it, as > some people at linuxcare (including Stephen) want to do it > differently themselves". I did interpolate the connection between these two clauses. If it truely did not exist, I apologise. > What I said the first time was that I preferred the idea of a user > mode daemon interacting with the kernel not the kernel forking and > execing a new process for every event. This has nothing to do with the interface presented to the APM driver. [...] > It is important when implementing an API (and that is what we are > doing) to try to get it as right and stable as possible because > other developers do not like interfaces changing ... Maybe this is true in general but in this particular case the "API" has only one user at the moment, which is APM, so it is hardly a fully fledged abstraction layer. Do you argue that the current pm_send_all interface is superior to the one in my patch? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code (PR#128)
[EMAIL PROTECTED] writes: [...] AFAICS. I hacked together the following patch for it a while ago, which updated APM_IOC_REJECT for slightly more recent kernels (be warned, I think I made some mistakes) Thanks for this, I will review it and post a patch based on it (with due accredition of course). Not sure that would be an altogether good idea, because I think I made a bit of a hash of it ;-) Did you get Albert Cranford's version? I would recommend it over mine (though I have not yet looked at it). [...] I did not say the I did not "like the idea of me implementing it, as some people at linuxcare (including Stephen) want to do it differently themselves". I did interpolate the connection between these two clauses. If it truely did not exist, I apologise. What I said the first time was that I preferred the idea of a user mode daemon interacting with the kernel not the kernel forking and execing a new process for every event. This has nothing to do with the interface presented to the APM driver. [...] It is important when implementing an API (and that is what we are doing) to try to get it as right and stable as possible because other developers do not like interfaces changing ... Maybe this is true in general but in this particular case the "API" has only one user at the moment, which is APM, so it is hardly a fully fledged abstraction layer. Do you argue that the current pm_send_all interface is superior to the one in my patch? [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes: > John Fremlin wrote: [...] > > > To implement off-button you only need the APM_IOC_REJECT ioctl and > > > > The problem on my computer with my (re)implementation of > > APM_IOC_REJECT is that the screen goes into powersaving when the user > > suspend is received, then turns it back on when APM_IOC_REJECT is sent > > by apmd. > > What is wrong with that ? > Suspend is requested -> suspend is executed > Suspend is canceled (rejected) -> suspend is canceled > > Seems perfectly OK to me. The sequence is in fact: suspend requested by BIOS -> suspend accepted by kernel -> SUSPEND -> suspend rejected by apmd which is passed on by kernel to BIOS -> REJECT=RESUME (if I understand correctly, this is what seems to happen). Sequence should be as in pmpolicy patch: suspend requested by BIOS -> /sbin/powermanger decides to reject -> REJECT [...] > > Anyway it is fixed in my pmpolicy patch, and I don't need no > > daemon so the code is a lot cleaner and simpler (no binary magic > > number interfaces). > > But there should be no policy in the kernel ! ;-) Read the patch. Read the webpage: http://john.snoop.dk/programs/linux/offbutton There is no policy in kernel. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code
David Balazic [EMAIL PROTECTED] writes: John Fremlin wrote: [...] To implement off-button you only need the APM_IOC_REJECT ioctl and The problem on my computer with my (re)implementation of APM_IOC_REJECT is that the screen goes into powersaving when the user suspend is received, then turns it back on when APM_IOC_REJECT is sent by apmd. What is wrong with that ? Suspend is requested - suspend is executed Suspend is canceled (rejected) - suspend is canceled Seems perfectly OK to me. The sequence is in fact: suspend requested by BIOS - suspend accepted by kernel - SUSPEND - suspend rejected by apmd which is passed on by kernel to BIOS - REJECT=RESUME (if I understand correctly, this is what seems to happen). Sequence should be as in pmpolicy patch: suspend requested by BIOS - /sbin/powermanger decides to reject - REJECT [...] Anyway it is fixed in my pmpolicy patch, and I don't need no daemon so the code is a lot cleaner and simpler (no binary magic number interfaces). But there should be no policy in the kernel ! ;-) Read the patch. Read the webpage: http://john.snoop.dk/programs/linux/offbutton There is no policy in kernel. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes: > John Fremlin wrote: > > > > David Balazic <[EMAIL PROTECTED]> writes: [...] > > The maintainer hasn't the time to do it. He promised me he would in > > February, when I telephone, but hasn't bothered to do anything > > AFAICS. I hacked together the following patch for it a while ago, > > which updated APM_IOC_REJECT for slightly more recent kernels (be > > warned, I think I made some mistakes) > > It uses the same version number ( 1.15 ) as the "official" apm.c ( > at linuxcare.com.au/apm ). I don't think that is a good idea. Maybe > 1.14b ? Well it's not going to go anywhere unless you want to look after it so there's not much point in worrying about that :-) [...] > > I made a (IMHO) better version called pmpolicy, based on different > > principles. More information is available at > > > > http://john.snoop.dk/programs/linux/offbutton/ > To implement off-button you only need the APM_IOC_REJECT ioctl and The problem on my computer with my (re)implementation of APM_IOC_REJECT is that the screen goes into powersaving when the user suspend is received, then turns it back on when APM_IOC_REJECT is sent by apmd. Stephen said this was something wrong with my implementation (???). Anyway it is fixed in my pmpolicy patch, and I don't need no daemon so the code is a lot cleaner and simpler (no binary magic number interfaces). [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code
David Balazic [EMAIL PROTECTED] writes: John Fremlin wrote: David Balazic [EMAIL PROTECTED] writes: [...] The maintainer hasn't the time to do it. He promised me he would in February, when I telephone, but hasn't bothered to do anything AFAICS. I hacked together the following patch for it a while ago, which updated APM_IOC_REJECT for slightly more recent kernels (be warned, I think I made some mistakes) It uses the same version number ( 1.15 ) as the "official" apm.c ( at linuxcare.com.au/apm ). I don't think that is a good idea. Maybe 1.14b ? Well it's not going to go anywhere unless you want to look after it so there's not much point in worrying about that :-) [...] I made a (IMHO) better version called pmpolicy, based on different principles. More information is available at http://john.snoop.dk/programs/linux/offbutton/ To implement off-button you only need the APM_IOC_REJECT ioctl and The problem on my computer with my (re)implementation of APM_IOC_REJECT is that the screen goes into powersaving when the user suspend is received, then turns it back on when APM_IOC_REJECT is sent by apmd. Stephen said this was something wrong with my implementation (???). Anyway it is fixed in my pmpolicy patch, and I don't need no daemon so the code is a lot cleaner and simpler (no binary magic number interfaces). [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel apm code
David Balazic <[EMAIL PROTECTED]> writes:
> The newer version has among other things support for
> the APM_IOC_REJECT ioctl which is useful for example
> when implementing "run /sbin/shutdown -h when the power
> button is pressed".
>
> While isn't this merged into the official kernel ?
The maintainer hasn't the time to do it. He promised me he would in
February, when I telephone, but hasn't bothered to do anything
AFAICS. I hacked together the following patch for it a while ago,
which updated APM_IOC_REJECT for slightly more recent kernels (be
warned, I think I made some mistakes)
diff -u linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c linux-hacked/arch/i386/kernel/apm.c
--- linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c Fri Dec 29 22:47:16 2000
+++ linux-hacked/arch/i386/kernel/apm.c Fri Dec 29 22:49:32 2000
@@ -38,6 +38,7 @@
* Jan 2000, Version 1.12
* Feb 2000, Version 1.13
* Nov 2000, Version 1.14
+ * Dec 2000, Version 1.15
*
* History:
*0.6b: first version in official kernel, Linux 1.3.46
@@ -148,6 +149,10 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * <[EMAIL PROTECTED]>.
+ * John Fremlin <[EMAIL PROTECTED]>
*
* APM 1.1 Reference:
*
@@ -301,6 +306,7 @@
int suspend_result;
int suspends_pending;
int standbys_pending;
+ int rejects_pending;
int suspends_read;
int standbys_read;
int event_head;
@@ -325,6 +331,7 @@
#endif
static int suspends_pending;
static int standbys_pending;
+static int rejects_pending;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -350,7 +357,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = "1.14"; /* no spaces */
+static char driver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -832,6 +839,15 @@
as->standbys_pending++;
standbys_pending++;
break;
+
+ case APM_SUSPEND_REJECT:
+ as->suspend_wait = 0;
+ as->suspend_result = -EAGAIN;
+ /* Fall through to */
+ case APM_STANDBY_REJECT:
+ as->rejects_pending++;
+ rejects_pending++;
+ break;
}
}
wake_up_interruptible(_waitqueue);
@@ -1211,6 +1227,41 @@
return 0;
}
+static int send_reject(struct apm_user *as, apm_event_t state)
+{
+ if (as->rejects_pending > 0) {
+ as->rejects_pending--;
+ rejects_pending--;
+ } else {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ queue_event(APM_SUSPEND_REJECT, as);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ queue_event(APM_STANDBY_REJECT, as);
+ break;
+ }
+ }
+ if ((rejects_pending <= 0) &&
+ (suspends_pending <= 0) &&
+ (standbys_pending <= 0)) {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ send_event(APM_NORMAL_RESUME);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ send_event(APM_STANDBY_RESUME);
+ break;
+ }
+ return apm_set_power_state(APM_STATE_REJECT);
+ }
+ return APM_SUCCESS;
+}
+
static int do_ioctl(struct inode * inode, struct file *filp,
u_int cmd, u_long arg)
{
@@ -1262,12 +1313,30 @@
return as->suspend_result;
}
break;
+ case APM_IOC_REJECT:
+ if (as->suspends_read > 0) {
+ as->suspends_read--;
+ as->suspends_pending--;
+ suspends_pending--;
+ if(send_reject(as, APM_SYS_SUSPEND)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else if (as->standbys_read > 0) {
+ as->standbys_read--;
+ as->standbys_pending--;
+ standbys_pending--;
+ if(send_reject(as, APM_SYS_STANDBY)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else
+ return -EINVAL;
+ break;
default:
return -EINVAL;
}
return 0;
}
+
+
static int do_release(struct inode * inode, struct file * filp)
{
struct apm_user * as;
@@ -1277,14 +1346,16 @@
return 0;
filp->private_data = NULL;
lock_kernel();
+ rejects_pending -= as->rejects_pending;
+ as->rejects_pending = 0;
if (as->standbys_pending > 0) {
standbys_pending -= as->standbys_pending;
- if (standbys_pending <= 0)
+ if (standbys_pending <= 0 && rejects_pending <= 0)
standby();
}
if (as->suspends_pending > 0) {
suspends_pending -= as->suspends_pending;
- if (suspends_pending <= 0)
+ if (suspends_pending <= 0 && rejects_pending <= 0)
(void) suspend();
}
if (user_list == as)
@@ -1318,7 +1389,7 @@
}
as->magic = APM_BIOS_MAGIC;
as->event_tail = as->event_head = 0;
- as->suspends_
Re: kernel apm code
David Balazic [EMAIL PROTECTED] writes:
The newer version has among other things support for
the APM_IOC_REJECT ioctl which is useful for example
when implementing "run /sbin/shutdown -h when the power
button is pressed".
While isn't this merged into the official kernel ?
The maintainer hasn't the time to do it. He promised me he would in
February, when I telephone, but hasn't bothered to do anything
AFAICS. I hacked together the following patch for it a while ago,
which updated APM_IOC_REJECT for slightly more recent kernels (be
warned, I think I made some mistakes)
diff -u linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c linux-hacked/arch/i386/kernel/apm.c
--- linux-2.4.0-test13-pre4/arch/i386/kernel/apm.c Fri Dec 29 22:47:16 2000
+++ linux-hacked/arch/i386/kernel/apm.c Fri Dec 29 22:49:32 2000
@@ -38,6 +38,7 @@
* Jan 2000, Version 1.12
* Feb 2000, Version 1.13
* Nov 2000, Version 1.14
+ * Dec 2000, Version 1.15
*
* History:
*0.6b: first version in official kernel, Linux 1.3.46
@@ -148,6 +149,10 @@
* 1.14: Make connection version persist across module unload/load.
* Enable and engage power management earlier.
* Disengage power management on module unload.
+ * 1.15: Add APM_IOC_REJECT ioctl, based on a patch from Stephen
+ * Rothwell but apparently written by Craig Markwardt
+ * [EMAIL PROTECTED].
+ * John Fremlin [EMAIL PROTECTED]
*
* APM 1.1 Reference:
*
@@ -301,6 +306,7 @@
int suspend_result;
int suspends_pending;
int standbys_pending;
+ int rejects_pending;
int suspends_read;
int standbys_read;
int event_head;
@@ -325,6 +331,7 @@
#endif
static int suspends_pending;
static int standbys_pending;
+static int rejects_pending;
static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -350,7 +357,7 @@
static DECLARE_WAIT_QUEUE_HEAD(apm_suspend_waitqueue);
static struct apm_user * user_list;
-static char driver_version[] = "1.14"; /* no spaces */
+static char driver_version[] = "1.15"; /* no spaces */
static char * apm_event_name[] = {
"system standby",
@@ -832,6 +839,15 @@
as-standbys_pending++;
standbys_pending++;
break;
+
+ case APM_SUSPEND_REJECT:
+ as-suspend_wait = 0;
+ as-suspend_result = -EAGAIN;
+ /* Fall through to */
+ case APM_STANDBY_REJECT:
+ as-rejects_pending++;
+ rejects_pending++;
+ break;
}
}
wake_up_interruptible(apm_waitqueue);
@@ -1211,6 +1227,41 @@
return 0;
}
+static int send_reject(struct apm_user *as, apm_event_t state)
+{
+ if (as-rejects_pending 0) {
+ as-rejects_pending--;
+ rejects_pending--;
+ } else {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ queue_event(APM_SUSPEND_REJECT, as);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ queue_event(APM_STANDBY_REJECT, as);
+ break;
+ }
+ }
+ if ((rejects_pending = 0)
+ (suspends_pending = 0)
+ (standbys_pending = 0)) {
+ switch (state) {
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ send_event(APM_NORMAL_RESUME);
+ break;
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ send_event(APM_STANDBY_RESUME);
+ break;
+ }
+ return apm_set_power_state(APM_STATE_REJECT);
+ }
+ return APM_SUCCESS;
+}
+
static int do_ioctl(struct inode * inode, struct file *filp,
u_int cmd, u_long arg)
{
@@ -1262,12 +1313,30 @@
return as-suspend_result;
}
break;
+ case APM_IOC_REJECT:
+ if (as-suspends_read 0) {
+ as-suspends_read--;
+ as-suspends_pending--;
+ suspends_pending--;
+ if(send_reject(as, APM_SYS_SUSPEND)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else if (as-standbys_read 0) {
+ as-standbys_read--;
+ as-standbys_pending--;
+ standbys_pending--;
+ if(send_reject(as, APM_SYS_STANDBY)!=APM_SUCCESS)
+return -EREMOTEIO;
+ } else
+ return -EINVAL;
+ break;
default:
return -EINVAL;
}
return 0;
}
+
+
static int do_release(struct inode * inode, struct file * filp)
{
struct apm_user * as;
@@ -1277,14 +1346,16 @@
return 0;
filp-private_data = NULL;
lock_kernel();
+ rejects_pending -= as-rejects_pending;
+ as-rejects_pending = 0;
if (as-standbys_pending 0) {
standbys_pending -= as-standbys_pending;
- if (standbys_pending = 0)
+ if (standbys_pending = 0 rejects_pending = 0)
standby();
}
if (as-suspends_pending 0) {
suspends_pending -= as-suspends_pending;
- if (suspends_pending = 0)
+ if (suspends_pending = 0 rejects_pending = 0)
(void) suspend();
}
if (user_list == as)
@@ -1318,7 +1389,7 @@
}
as-magic = APM_BIOS_MAGIC;
as-event_tail = as-event_head = 0;
- as-suspends_pending = as-standbys_pending = 0;
+ as-suspends_pending = as-standbys_pending = as-rejects_pending = 0;
as-suspends_read = as-standbys_read = 0;
/*
* XXX - this is a tiny bit broken, when we consider BSD
diff --recursive
Racing power management
Jeff Garzik <[EMAIL PROTECTED]> writes: > John Fremlin wrote: > > Why not set up the device driver to handle PM events itself. See > > Documentation/pm.txt under Driver Interface. > > For PCI drivers, you implement the ::suspend and ::remove hooks. > > > I have a race free version of pm_send_all if you want it. > > Is this the same thing that is in 2.4.3-pre3? Aarrgh. Looks like Alan Cox got his version in kernel first. (I did write mine before.) If I am not mistaken there is one (hypothetical) race still remaining in Alan's version. Last time I checked the only code doing pm_send_all was in the i386 APM driver (and so of course there is no chance of any race at all even with the old version, if I understand correctly). But suppose there were another pm_send_all caller. APM would decide to user suspend and call pm_send_all asking for a SUSPEND to check it was allowed to. While this is happening some clueless loser decides to pm_send_all RESUME for whatever reason. This loser has to wait until the APM pm_send_all finishes, but hypothetically and if I am not mistaken, his pm_send_all RESUME could get in just after the APM pm_send_all finished and just before APM made the physical BIOS call to suspend the machine. This would screw stuff up of course. You may say, this is rather improbable if not impossible, but it does suggest that it would be a good idea to have locking wrapping pm_send_all and the hardware machine suspend request. Cue: John's pmpolicy patch. Unfortunately, my patch adds another thing as well: /sbin/powermanager so it got (is getting) trampled on by a lot of people who didn't like that idea. If anybody wants the race free PM by itself, I can factor out that bit. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcible removal of modules
Thomas Hood <[EMAIL PROTECTED]> writes: > Sometimes modules need to be reloaded in order > to cause some sort of reinitialization (of the > driver or of the hardware) to occur. Why not set up the device driver to handle PM events itself. See Documentation/pm.txt under Driver Interface. I have a race free version of pm_send_all if you want it. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Forcible removal of modules
Thomas Hood [EMAIL PROTECTED] writes: Sometimes modules need to be reloaded in order to cause some sort of reinitialization (of the driver or of the hardware) to occur. Why not set up the device driver to handle PM events itself. See Documentation/pm.txt under Driver Interface. I have a race free version of pm_send_all if you want it. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Racing power management
Jeff Garzik [EMAIL PROTECTED] writes: John Fremlin wrote: Why not set up the device driver to handle PM events itself. See Documentation/pm.txt under Driver Interface. For PCI drivers, you implement the ::suspend and ::remove hooks. I have a race free version of pm_send_all if you want it. Is this the same thing that is in 2.4.3-pre3? Aarrgh. Looks like Alan Cox got his version in kernel first. (I did write mine before.) If I am not mistaken there is one (hypothetical) race still remaining in Alan's version. Last time I checked the only code doing pm_send_all was in the i386 APM driver (and so of course there is no chance of any race at all even with the old version, if I understand correctly). But suppose there were another pm_send_all caller. APM would decide to user suspend and call pm_send_all asking for a SUSPEND to check it was allowed to. While this is happening some clueless loser decides to pm_send_all RESUME for whatever reason. This loser has to wait until the APM pm_send_all finishes, but hypothetically and if I am not mistaken, his pm_send_all RESUME could get in just after the APM pm_send_all finished and just before APM made the physical BIOS call to suspend the machine. This would screw stuff up of course. You may say, this is rather improbable if not impossible, but it does suggest that it would be a good idea to have locking wrapping pm_send_all and the hardware machine suspend request. Cue: John's pmpolicy patch. Unfortunately, my patch adds another thing as well: /sbin/powermanager so it got (is getting) trampled on by a lot of people who didn't like that idea. If anybody wants the race free PM by itself, I can factor out that bit. -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APM, virtual console problem in 2.4.0
Joseph Pingenot <[EMAIL PROTECTED]> writes: > When suspending my laptop (Toshiba Satellite 1605CDS; BIOS set to > suspend to disk) with Debian 2.2r2's 'apm -s', the screen blanks and > then the system locks up hard (not even the power button works). In Go hassle Stephen Rothwell <[EMAIL PROTECTED]> about this. He loves feedback. [...] -- http://www.penguinpowered.com/~vii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
