linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Some fixes for compat ioctl
@ 2005-01-18  7:21 Andi Kleen
  2005-01-18 10:34 ` Michael S. Tsirkin
                   ` (4 more replies)
  0 siblings, 5 replies; 152+ messages in thread
From: Andi Kleen @ 2005-01-18  7:21 UTC (permalink / raw)
  To: akpm, mst, hch, linux-kernel; +Cc: chrisw, davem


While doing some compat_ioctl conversions I noticed a few issues
in compat_sys_ioctl:

- It is not completely compatible to old ->ioctl because 
the traditional common ioctls are not checked before it. I added
a check for those. The main advantage is that the handler 
now works the same as a traditional handler even when it returns
-EINVAL
- The private socket ioctl check should only apply for sockets.
- There was a security hook missing.  Drawback is that it uses
the same hook now, and the LSM module cannot distingush between
32bit and 64bit clients. But it'll have to live with that for now.

Signed-off-by: Andi Kleen <ak@muc.de>

diff -u linux-2.6.11-rc1-bk4/fs/ioctl.c-o linux-2.6.11-rc1-bk4/fs/ioctl.c
--- linux-2.6.11-rc1-bk4/fs/ioctl.c-o	2005-01-17 10:39:40.000000000 +0100
+++ linux-2.6.11-rc1-bk4/fs/ioctl.c	2005-01-17 21:57:09.000000000 +0100
@@ -78,6 +78,10 @@
 }
 
 
+/* 
+ * When you add any new common ioctls to the switches above and below
+ * please update compat_sys_ioctl() too.
+ */ 
 asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
 {
 	struct file * filp;
diff -u linux-2.6.11-rc1-bk4/fs/compat.c-o linux-2.6.11-rc1-bk4/fs/compat.c
--- linux-2.6.11-rc1-bk4/fs/compat.c-o	2005-01-17 10:39:40.000000000 +0100
+++ linux-2.6.11-rc1-bk4/fs/compat.c	2005-01-18 08:04:11.000000000 +0100
@@ -25,6 +25,7 @@
 #include <linux/file.h>
 #include <linux/vfs.h>
 #include <linux/ioctl32.h>
+#include <linux/ioctl.h>
 #include <linux/init.h>
 #include <linux/sockios.h>	/* for SIOCDEVPRIVATE */
 #include <linux/smb.h>
@@ -47,6 +48,7 @@
 
 #include <asm/uaccess.h>
 #include <asm/mmu_context.h>
+#include <asm/ioctls.h>
 
 /*
  * Not all architectures have sys_utime, so implement this in terms
@@ -437,16 +439,41 @@
 	if (!filp)
 		goto out;
 
-	if (filp->f_op && filp->f_op->compat_ioctl) {
-		error = filp->f_op->compat_ioctl(filp, cmd, arg);
-		if (error != -ENOIOCTLCMD)
-			goto out_fput;
-	}
-
-	if (!filp->f_op ||
-	    (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
-		goto do_ioctl;
+	/* 
+	 * To allow the compat_ioctl handlers to be self contained
+	 * we need to check the common ioctls here first.
+	 * Just handle them with the standard handlers below.
+	 */ 
+	switch (cmd) { 
+	case FIOCLEX:
+	case FIONCLEX:
+	case FIONBIO:
+	case FIOASYNC:
+	case FIOQSIZE:
+		break; 
+
+	case FIBMAP:
+	case FIGETBSZ:
+	case FIONREAD:
+		if (S_ISREG(filp->f_dentry->d_inode->i_mode))
+			break;
+		/*FALL THROUGH*/
 
+	default:
+		if (filp->f_op && filp->f_op->compat_ioctl) {
+			error = filp->f_op->compat_ioctl(filp, cmd, arg);
+			if (error != -ENOIOCTLCMD)
+				goto out_fput;
+		}
+		
+		if (!filp->f_op ||
+		    (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
+			goto do_ioctl;
+		break;
+	}
+		   	
+	/* When register_ioctl32_conversion is finally gone remove
+	   this lock! -AK */
 	down_read(&ioctl32_sem);
 	for (t = ioctl32_hash_table[ioctl32_hash(cmd)]; t; t = t->next) {
 		if (t->cmd == cmd)
@@ -454,7 +481,8 @@
 	}
 	up_read(&ioctl32_sem);
 
-	if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
+	if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
+	    cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
 		error = siocdevprivate_ioctl(fd, cmd, arg);
 	} else {
 		static int count;
@@ -468,6 +496,11 @@
 
  found_handler:
 	if (t->handler) {
+		/* RED-PEN how should LSM module know it's handling 32bit? */
+		error = security_file_ioctl(filp, cmd, arg);
+		if (error)
+			goto out_fput;
+
 		lock_kernel();
 		error = t->handler(fd, cmd, arg, filp);
 		unlock_kernel();

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH] Some fixes for compat ioctl
  2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
@ 2005-01-18 10:34 ` Michael S. Tsirkin
  2005-01-18 10:45   ` [PATCH 1/5] compat_ioctl call seems to miss a security hook Michael S. Tsirkin
  2005-01-18 10:48 ` [PATCH 2/5] socket ioctl fix (from Andi) Michael S. Tsirkin
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 10:34 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

Hi, Andi!

Quoting r. Andi Kleen (ak@muc.de) "[PATCH] Some fixes for compat ioctl":
> 
> While doing some compat_ioctl conversions I noticed a few issues
> in compat_sys_ioctl:
> 
> - It is not completely compatible to old ->ioctl because 
> the traditional common ioctls are not checked before it.

How is this different from what we have for compat_sys_ioctl
in 2.6.10? Or is this an old bug?

> I added
> a check for those.

Cant we just add them to fs/compat_ioctl.c instead, and be done?

> The main advantage is that the handler 
> now works the same as a traditional handler even when it returns
> -EINVAL


We still need the conversion functions in fs/compat_ioctl.c, I
think. If that is true, for some devices the handler only almost works
if it returns -EINVAL, and maybe its best not to encourage this.
I have another idea: maybe, lets move the unlocked_ioctl handler up so
that it, too, is required to return -NOIOCTLCMD?
I would argue it also may improve ioctl performance by a small margin,
since it is the unlocked_ioctl/compat_ioctl that do the "real" work.

I plan to send, separately, a patch that does this.
Please comment.

> 
> - The private socket ioctl check should only apply for sockets.

Its an old issue, isnt it? And probably better split in a separate
patch?

> - There was a security hook missing.  Drawback is that it uses
> the same hook now, and the LSM module cannot distingush between
> 32bit and 64bit clients. But it'll have to live with that for now.

It seems it is still missing for compat_ioctl. No?
I am sending a patch to fix this separately.

MST

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-18 10:34 ` Michael S. Tsirkin
@ 2005-01-18 10:45   ` Michael S. Tsirkin
  2005-01-18 19:22     ` Chris Wright
  0 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 10:45 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

Attached patch is against 2.6.11-rc1-bk5

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

Add a missing security hook for compatibility ioctl.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
 	if (!filp)
 		goto out;
 
+	/* RED-PEN how should LSM module know it's handling 32bit? */
+	error = security_file_ioctl(filp, cmd, arg);
+ 	if (error)
+ 		goto out_fput;
+
 	if (filp->f_op && filp->f_op->compat_ioctl) {
 		error = filp->f_op->compat_ioctl(filp, cmd, arg);
 		if (error != -ENOIOCTLCMD)


^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH 2/5] socket ioctl fix (from Andi)
  2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
  2005-01-18 10:34 ` Michael S. Tsirkin
@ 2005-01-18 10:48 ` Michael S. Tsirkin
  2005-01-18 10:55   ` Christoph Hellwig
  2005-01-18 10:52 ` [PATCH 3/5] make common ioctls apply for compat Michael S. Tsirkin
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 10:48 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

Attached patch is against 2.6.11-rc1-bk5.
It is split out from Andi's big patch.
It is really unchanged so I dont put a signed-off-by here.

Signed-off-by: Andi Kleen <ak@muc.de>

SIOCDEVPRIVATE ioctl command only applies to socket descriptors.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
@@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne
 	}
 	up_read(&ioctl32_sem);
 
-	if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
+	if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
+	    cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
 		error = siocdevprivate_ioctl(fd, cmd, arg);
 	} else {
 		static int count;

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH 3/5] make common ioctls apply for compat.
  2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
  2005-01-18 10:34 ` Michael S. Tsirkin
  2005-01-18 10:48 ` [PATCH 2/5] socket ioctl fix (from Andi) Michael S. Tsirkin
@ 2005-01-18 10:52 ` Michael S. Tsirkin
  2005-01-18 10:57 ` [PATCH 4/5] reminder comment about register_ioctl32_conversion Michael S. Tsirkin
  2005-01-18 11:04 ` [PATCH 5/5] symmetry between compat_ioctl and unlocked_ioctl Michael S. Tsirkin
  4 siblings, 0 replies; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 10:52 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

Attached patch is against 2.6.11-rc1-bk5
A piece is copied from Andi's patch, too. No idea if
his SOB should be here too. Here it is just in case.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Andi Kleen <ak@muc.de>

Make common ioctls apply for compat_ioctl.

diff -rup linux-2.6.10-orig/fs/compat_ioctl.c linux-2.6.10-ioctl-sym/fs/compat_ioctl.c
--- linux-2.6.10-orig/fs/compat_ioctl.c	2004-12-24 23:36:01.000000000 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat_ioctl.c	2005-01-18 10:54:31.736650344 +0200
@@ -3165,6 +3165,14 @@ static int do_ncp_setprivatedata(unsigne
 #endif
 
 #ifdef DECLARES
+HANDLE_IOCTL(FIOCLEX,NULL)
+HANDLE_IOCTL(FIONCLEX,NULL)
+HANDLE_IOCTL(FIONBIO,NULL)
+HANDLE_IOCTL(FIOASYNC,NULL)
+HANDLE_IOCTL(FIOQSIZE,NULL)
+HANDLE_IOCTL(FIBMAP,NULL)
+HANDLE_IOCTL(FIGETBSZ,NULL)
+HANDLE_IOCTL(FIONREAD,NULL)
 HANDLE_IOCTL(MEMREADOOB32, mtd_rw_oob)
 HANDLE_IOCTL(MEMWRITEOOB32, mtd_rw_oob)
 #ifdef CONFIG_NET
diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c	2005-01-18 10:51:55.690372984 +0200
@@ -77,7 +72,10 @@ static int file_ioctl(struct file *filp,
 	return do_ioctl(filp, cmd, arg);
 }
 
-
+/*
+ * When you add any new common ioctls to the switches above and below
+ * please update compat_ioctl.c too.
+ */
 asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
 {
 	struct file * filp;

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 2/5] socket ioctl fix (from Andi)
  2005-01-18 10:48 ` [PATCH 2/5] socket ioctl fix (from Andi) Michael S. Tsirkin
@ 2005-01-18 10:55   ` Christoph Hellwig
  2005-01-18 11:01     ` Andi Kleen
  0 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-18 10:55 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Andi Kleen, akpm, hch, linux-kernel, chrisw, davem

On Tue, Jan 18, 2005 at 12:48:16PM +0200, Michael S. Tsirkin wrote:
> Attached patch is against 2.6.11-rc1-bk5.
> It is split out from Andi's big patch.
> It is really unchanged so I dont put a signed-off-by here.
> 
> Signed-off-by: Andi Kleen <ak@muc.de>
> 
> SIOCDEVPRIVATE ioctl command only applies to socket descriptors.
> 
> diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
> --- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
> +++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
> @@ -454,7 +460,8 @@ asmlinkage long compat_sys_ioctl(unsigne
>  	}
>  	up_read(&ioctl32_sem);
>  
> -	if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> +	if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
> +	    cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
>  		error = siocdevprivate_ioctl(fd, cmd, arg);

Maybe this should move into a new sock_compat_ioctl() instead?


^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH 4/5] reminder comment about register_ioctl32_conversion
  2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
                   ` (2 preceding siblings ...)
  2005-01-18 10:52 ` [PATCH 3/5] make common ioctls apply for compat Michael S. Tsirkin
@ 2005-01-18 10:57 ` Michael S. Tsirkin
  2005-01-18 11:04 ` [PATCH 5/5] symmetry between compat_ioctl and unlocked_ioctl Michael S. Tsirkin
  4 siblings, 0 replies; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 10:57 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

This is just a split off from Andi's patch, so I didnt add my SOB here.

Signed-off-by: Andi Kleen <ak@muc.de>

Since its too early to deprecate (un)register_ioctl32_conversion,
add a comment for that time when we do.

diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
--- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
@@ -447,6 +452,7 @@ asmlinkage long compat_sys_ioctl(unsigne
 	    (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
 		goto do_ioctl;
 
+	/* When register_ioctl32_conversion is gone remove this lock! -AK */
 	down_read(&ioctl32_sem);
 	for (t = ioctl32_hash_table[ioctl32_hash(cmd)]; t; t = t->next) {
 		if (t->cmd == cmd)

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 2/5] socket ioctl fix (from Andi)
  2005-01-18 10:55   ` Christoph Hellwig
@ 2005-01-18 11:01     ` Andi Kleen
  0 siblings, 0 replies; 152+ messages in thread
From: Andi Kleen @ 2005-01-18 11:01 UTC (permalink / raw)
  To: Christoph Hellwig, Michael S. Tsirkin, akpm, linux-kernel, chrisw, davem

> > -	if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> > +	if (S_ISSOCK(filp->f_dentry->d_inode->i_mode) &&
> > +	    cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
> >  		error = siocdevprivate_ioctl(fd, cmd, arg);
> 
> Maybe this should move into a new sock_compat_ioctl() instead?
> 

Seems like overkill for 3 lines of code.

-Andi

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH 5/5] symmetry between compat_ioctl and unlocked_ioctl
  2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
                   ` (3 preceding siblings ...)
  2005-01-18 10:57 ` [PATCH 4/5] reminder comment about register_ioctl32_conversion Michael S. Tsirkin
@ 2005-01-18 11:04 ` Michael S. Tsirkin
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
  4 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-18 11:04 UTC (permalink / raw)
  To: Andi Kleen; +Cc: akpm, hch, linux-kernel, chrisw, davem

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

Make unlocked_ioctl and compat_ioctl behave symmetrically -
check them first thing, and always require returning ENOIOCTLCMD
on error from unlocked_ioctl, same as we do for compat_ioctl.
This also makes it possible to override *all* ioctl commands, and
hopefully may enable some speed ups on the data path.

diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c	2005-01-18 10:51:55.690372984 +0200
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp, 
 	if (!filp->f_op)
 		goto out;
 
-	if (filp->f_op->unlocked_ioctl) {
-		error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
-		if (error == -ENOIOCTLCMD)
-			error = -EINVAL;
-		goto out;
-	} else if (filp->f_op->ioctl) {
+	if (filp->f_op->ioctl) {
 		lock_kernel();
 		error = filp->f_op->ioctl(filp->f_dentry->d_inode,
 					  filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int f
  	if (error)
  		goto out_fput;
 
+	if (filp->f_op && filp->f_op->unlocked_ioctl) {
+		error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
+		if (error != -ENOIOCTLCMD)
+			goto out_fput;
+	}
+
 	switch (cmd) {
 		case FIOCLEX:
 			set_close_on_exec(fd, 1);

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-18 10:45   ` [PATCH 1/5] compat_ioctl call seems to miss a security hook Michael S. Tsirkin
@ 2005-01-18 19:22     ` Chris Wright
  2005-01-20  0:28       ` Michael S. Tsirkin
  0 siblings, 1 reply; 152+ messages in thread
From: Chris Wright @ 2005-01-18 19:22 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Andi Kleen, akpm, hch, linux-kernel, chrisw, davem

* Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
> --- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
> +++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
> @@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
>  	if (!filp)
>  		goto out;
>  
> +	/* RED-PEN how should LSM module know it's handling 32bit? */
> +	error = security_file_ioctl(filp, cmd, arg);
> + 	if (error)
> + 		goto out_fput;
> +

This is now called twice in the plain do_ioctl: case.  A generic vfs handler
could alleviate that.

===== fs/ioctl.c 1.15 vs edited =====
--- 1.15/fs/ioctl.c	2005-01-15 14:31:01 -08:00
+++ edited/fs/ioctl.c	2005-01-18 11:18:33 -08:00
@@ -77,21 +77,10 @@ static int file_ioctl(struct file *filp,
 	return do_ioctl(filp, cmd, arg);
 }
 
-
-asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
+int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned long arg)
 {
-	struct file * filp;
 	unsigned int flag;
-	int on, error = -EBADF;
-	int fput_needed;
-
-	filp = fget_light(fd, &fput_needed);
-	if (!filp)
-		goto out;
-
-	error = security_file_ioctl(filp, cmd, arg);
-	if (error)
-		goto out_fput;
+	int on, error = 0;
 
 	switch (cmd) {
 		case FIOCLEX:
@@ -157,6 +146,24 @@ asmlinkage long sys_ioctl(unsigned int f
 				error = do_ioctl(filp, cmd, arg);
 			break;
 	}
+	return error;
+}
+
+asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
+{
+	struct file * filp;
+	int error = -EBADF;
+	int fput_needed;
+
+	filp = fget_light(fd, &fput_needed);
+	if (!filp)
+		goto out;
+
+	error = security_file_ioctl(filp, cmd, arg);
+	if (error)
+		goto out_fput;
+
+	error = vfs_ioctl(filp, fd, cmd, arg);
  out_fput:
 	fput_light(filp, fput_needed);
  out:
===== fs/compat.c 1.48 vs edited =====
--- 1.48/fs/compat.c	2005-01-15 14:31:01 -08:00
+++ edited/fs/compat.c	2005-01-18 11:07:56 -08:00
@@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
 	if (!filp)
 		goto out;
 
+	/* RED-PEN how should LSM module know it's handling 32bit? */
+	error = security_file_ioctl(filp, cmd, arg);
+	if (error)
+		goto out_fput;
+
 	if (filp->f_op && filp->f_op->compat_ioctl) {
 		error = filp->f_op->compat_ioctl(filp, cmd, arg);
 		if (error != -ENOIOCTLCMD)
@@ -477,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne
 
 	up_read(&ioctl32_sem);
  do_ioctl:
-	error = sys_ioctl(fd, cmd, arg);
+	error = vfs_ioctl(filp, fd, cmd, arg);
  out_fput:
 	fput_light(filp, fput_needed);
  out:
===== include/linux/fs.h 1.373 vs edited =====
--- 1.373/include/linux/fs.h	2005-01-15 14:31:01 -08:00
+++ edited/include/linux/fs.h	2005-01-18 11:10:54 -08:00
@@ -1564,6 +1564,8 @@ extern int vfs_stat(char __user *, struc
 extern int vfs_lstat(char __user *, struct kstat *);
 extern int vfs_fstat(unsigned int, struct kstat *);
 
+extern int vfs_ioctl(struct file *, unsigned int, unsigned int, unsigned long);
+
 extern struct file_system_type *get_fs_type(const char *name);
 extern struct super_block *get_super(struct block_device *);
 extern struct super_block *user_get_super(dev_t);

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-18 19:22     ` Chris Wright
@ 2005-01-20  0:28       ` Michael S. Tsirkin
  2005-01-20  0:43         ` Chris Wright
  0 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-20  0:28 UTC (permalink / raw)
  To: Chris Wright; +Cc: Andi Kleen, akpm, hch, linux-kernel, davem

Hello!
Quoting r. Chris Wright (chrisw@osdl.org) "Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook":
> * Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> > diff -rup linux-2.6.10-orig/fs/compat.c linux-2.6.10-ioctl-sym/fs/compat.c
> > --- linux-2.6.10-orig/fs/compat.c	2005-01-18 10:58:33.609880024 +0200
> > +++ linux-2.6.10-ioctl-sym/fs/compat.c	2005-01-18 10:54:26.289478440 +0200
> > @@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
> >  	if (!filp)
> >  		goto out;
> >  
> > +	/* RED-PEN how should LSM module know it's handling 32bit? */
> > +	error = security_file_ioctl(filp, cmd, arg);
> > + 	if (error)
> > + 		goto out_fput;
> > +
> 
> This is now called twice in the plain do_ioctl: case.  A generic vfs handler
> could alleviate that.

I'm all for it, but the way the patch below works, we could end up
calling ->ioctl or ->unlocked_ioctl from the compat 
syscall, and we dont want that.

MST



> ===== fs/ioctl.c 1.15 vs edited =====
> --- 1.15/fs/ioctl.c	2005-01-15 14:31:01 -08:00
> +++ edited/fs/ioctl.c	2005-01-18 11:18:33 -08:00
> @@ -77,21 +77,10 @@ static int file_ioctl(struct file *filp,
>  	return do_ioctl(filp, cmd, arg);
>  }
>  
> -
> -asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
> +int vfs_ioctl(struct file *filp, unsigned int fd, unsigned int cmd, unsigned long arg)
>  {
> -	struct file * filp;
>  	unsigned int flag;
> -	int on, error = -EBADF;
> -	int fput_needed;
> -
> -	filp = fget_light(fd, &fput_needed);
> -	if (!filp)
> -		goto out;
> -
> -	error = security_file_ioctl(filp, cmd, arg);
> -	if (error)
> -		goto out_fput;
> +	int on, error = 0;
>  
>  	switch (cmd) {
>  		case FIOCLEX:
> @@ -157,6 +146,24 @@ asmlinkage long sys_ioctl(unsigned int f
>  				error = do_ioctl(filp, cmd, arg);
>  			break;
>  	}
> +	return error;
> +}
> +
> +asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
> +{
> +	struct file * filp;
> +	int error = -EBADF;
> +	int fput_needed;
> +
> +	filp = fget_light(fd, &fput_needed);
> +	if (!filp)
> +		goto out;
> +
> +	error = security_file_ioctl(filp, cmd, arg);
> +	if (error)
> +		goto out_fput;
> +
> +	error = vfs_ioctl(filp, fd, cmd, arg);
>   out_fput:
>  	fput_light(filp, fput_needed);
>   out:
> ===== fs/compat.c 1.48 vs edited =====
> --- 1.48/fs/compat.c	2005-01-15 14:31:01 -08:00
> +++ edited/fs/compat.c	2005-01-18 11:07:56 -08:00
> @@ -437,6 +437,11 @@ asmlinkage long compat_sys_ioctl(unsigne
>  	if (!filp)
>  		goto out;
>  
> +	/* RED-PEN how should LSM module know it's handling 32bit? */
> +	error = security_file_ioctl(filp, cmd, arg);
> +	if (error)
> +		goto out_fput;
> +
>  	if (filp->f_op && filp->f_op->compat_ioctl) {
>  		error = filp->f_op->compat_ioctl(filp, cmd, arg);
>  		if (error != -ENOIOCTLCMD)
> @@ -477,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne
>  
>  	up_read(&ioctl32_sem);
>   do_ioctl:
> -	error = sys_ioctl(fd, cmd, arg);
> +	error = vfs_ioctl(filp, fd, cmd, arg);
>   out_fput:
>  	fput_light(filp, fput_needed);
>   out:
> ===== include/linux/fs.h 1.373 vs edited =====
> --- 1.373/include/linux/fs.h	2005-01-15 14:31:01 -08:00
> +++ edited/include/linux/fs.h	2005-01-18 11:10:54 -08:00
> @@ -1564,6 +1564,8 @@ extern int vfs_stat(char __user *, struc
>  extern int vfs_lstat(char __user *, struct kstat *);
>  extern int vfs_fstat(unsigned int, struct kstat *);
>  
> +extern int vfs_ioctl(struct file *, unsigned int, unsigned int, unsigned long);
> +
>  extern struct file_system_type *get_fs_type(const char *name);
>  extern struct super_block *get_super(struct block_device *);
>  extern struct super_block *user_get_super(dev_t);

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-20  0:28       ` Michael S. Tsirkin
@ 2005-01-20  0:43         ` Chris Wright
  2005-01-20  1:06           ` Michael S. Tsirkin
  0 siblings, 1 reply; 152+ messages in thread
From: Chris Wright @ 2005-01-20  0:43 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Chris Wright, Andi Kleen, akpm, hch, linux-kernel, davem

* Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> I'm all for it, but the way the patch below works, we could end up
> calling ->ioctl or ->unlocked_ioctl from the compat 
> syscall, and we dont want that.

Hmm, I didn't actually change how those are called.  So if it's an issue,
then I don't think this patch introduces it.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-20  0:43         ` Chris Wright
@ 2005-01-20  1:06           ` Michael S. Tsirkin
  2005-01-20  1:16             ` Chris Wright
  0 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-20  1:06 UTC (permalink / raw)
  To: Chris Wright; +Cc: Andi Kleen, akpm, hch, linux-kernel, davem

Quoting r. Chris Wright (chrisw@osdl.org) "Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook":
> * Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> > I'm all for it, but the way the patch below works, we could end up
> > calling ->ioctl or ->unlocked_ioctl from the compat 
> > syscall, and we dont want that.
> 
> Hmm, I didn't actually change how those are called.  So if it's an issue,
> then I don't think this patch introduces it.
> 
> thanks,
> -chris

Sorry, you are right, we go to do_ioctl only if there are no
callbacks.
Patch looks good to go to me.
mst

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-20  1:06           ` Michael S. Tsirkin
@ 2005-01-20  1:16             ` Chris Wright
  2005-01-20  1:42               ` Michael S. Tsirkin
  0 siblings, 1 reply; 152+ messages in thread
From: Chris Wright @ 2005-01-20  1:16 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Chris Wright, Andi Kleen, akpm, hch, linux-kernel, davem

* Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> Quoting r. Chris Wright (chrisw@osdl.org) "Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook":
> > * Michael S. Tsirkin (mst@mellanox.co.il) wrote:
> > > I'm all for it, but the way the patch below works, we could end up
> > > calling ->ioctl or ->unlocked_ioctl from the compat 
> > > syscall, and we dont want that.
> > 
> > Hmm, I didn't actually change how those are called.  So if it's an issue,
> > then I don't think this patch introduces it.
> 
> Sorry, you are right, we go to do_ioctl only if there are no
> callbacks.

I suppose there is one case (not introduced by the patch).  Not sure if
it's even a problem though:

t->cmd matches, yet NULL t->handler.  This will fall-thru to
the do_ioctl: case.  I assume NULL handler is for case where no
conversion is needed, so it's not a problem?  At least some callers of
register_ioctl32_conversion() pass NULL handler.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH 1/5] compat_ioctl call seems to miss a security hook
  2005-01-20  1:16             ` Chris Wright
@ 2005-01-20  1:42               ` Michael S. Tsirkin
  0 siblings, 0 replies; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-20  1:42 UTC (permalink / raw)
  To: Chris Wright; +Cc: Andi Kleen, akpm, hch, linux-kernel, davem

Quoting r. Chris Wright (chrisw@osdl.org)
> > > > I'm all for it, but the way the patch below works, we could end up
> > > > calling ->ioctl or ->unlocked_ioctl from the compat 
> > > > syscall, and we dont want that.
> > > 
> > > Hmm, I didn't actually change how those are called.  So if it's an issue,
> > > then I don't think this patch introduces it.
> > 
> > Sorry, you are right, we go to do_ioctl only if there are no
> > callbacks.
> 
> I suppose there is one case (not introduced by the patch).  Not sure if
> it's even a problem though:
> 
> t->cmd matches, yet NULL t->handler.  This will fall-thru to
> the do_ioctl: case.  I assume NULL handler is for case where no
> conversion is needed, so it's not a problem?  At least some callers of
> register_ioctl32_conversion() pass NULL handler.

Yes, this is an by design, you put in a NULL handler to say: I dont need
conversions, call my regular handlers. Some in-tree drivers do this.

MST

^ permalink raw reply	[flat|nested] 152+ messages in thread

* 2.6.11-rc2-mm1
@ 2005-01-24 10:15   ` Andrew Morton
  2005-01-24 10:36     ` 2.6.11-rc2-mm1 Adrian Bunk
                       ` (22 more replies)
  0 siblings, 23 replies; 152+ messages in thread
From: Andrew Morton @ 2005-01-24 10:15 UTC (permalink / raw)
  To: linux-kernel


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/


- Lots of updates and fixes all over the place.

- On my test box there is no flashing cursor on the vga console.  Known bug,
  please don't report it.

  Binary searching shows that the bug was introduced by
  cleanup-vc-array-access.patch but that patch is, unfortunately, huge.



Changes since 2.6.11-rc1-mm2:


 linus.patch
 bk-acpi.patch
 bk-agpgart.patch
 bk-alsa.patch
 bk-arm.patch
 bk-cifs.patch
 bk-driver-core.patch
 bk-drm.patch
 bk-drm-via.patch
 bk-i2c.patch
 bk-ide-dev.patch
 bk-input.patch
 bk-dtor-input.patch
 bk-netdev.patch
 bk-ntfs.patch
 bk-scsi-rc-fixes.patch
 bk-usb.patch
 bk-xfs.patch

 Latest versions of various bk trees

-acpi-build-fix-99.patch
-mips-default-mlock-limit-fix.patch
-shared_policy_replace-fix.patch
-generic_file_buffered_write-handle-partial-dio.patch
-cputimeh-seems-to-assume-hz==1000.patch
-ppc32-fix-pmac-kernel-build-with-oprofile.patch
-spinlocking-fixes.patch
-fix-config_agp-depencies.patch
-ioctl-compatibility-for-tiocmiwait-and-tiocgicount.patch
-cls_api-build-fix.patch
-alsa-conversion-to-compat_ioctl-kconfig.patch
-alsa-conversion-to-compat_ioctl-alsa-pcm-api.patch
-alsa-conversion-to-compat_ioctl-alsa-apis.patch
-ac97-audio-support-for-intel-ich7-2611-rc1.patch
-alps-touchpad-detection-fix.patch
-scsi-ncr53c9x-fixes.patch
-uninline-mod_page_state.patch
-fix-audit-control-message-checks.patch
-fix-audit-control-message-checks-tidy.patch
-selinux-add-netlink-message-types-for-the-tc-action-code.patch
-ppc32-update-cpu-state-save-restore.patch
-ppc32-add-missing-prototype.patch
-ppc32-system-platform_device-description-discovery-and-management.patch
-ppc32-infrastructure-changes-to-mpc85xx-sub-arch-from-ocp-to-platform_device.patch
-ppc32-convert-boards-from-using-ocp-to-platform_device.patch
-ppc32-convert-gianfar-ethernet-driver-from-using-an-ocp-to-platform_device.patch
-ppc32-remove-cli-sti-in-arch-ppc-4xx_io-serial_siccc.patch
-ppc32-remove-cli-sti-in-arch-ppc-8xx_io-cs4218_tdmc.patch
-ppc32-remove-cli-sti-in-arch-ppc-8xx_io-fecc.patch
-ppc32-remove-cli-sti-in-arch-ppc-platforms-apus_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-platforms-pal4_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-syslib-m8xx_setupc.patch
-ppc32-remove-cli-sti-in-arch-ppc-syslib-qspan_pcic.patch
-ppc32-mpc8xx-tlb-miss-vs-tlb-error-fix.patch
-ppc32-update_process_times-simplification.patch
-ppc32-add-defconfigs-for-85xx-boards.patch
-ppc64-remove-config_irq_all_cpus.patch
-ppc64-pci-eeh-documentation.patch
-ppc64-ppc-cleanup-pci-skipping.patch
-ppc64-minimum-hashtable-size.patch
-ppc64-remove-some-unused-iseries-functions.patch
-fix-xenu-kernel-crash-in-dmi_iterate.patch
-x86-use-cpumask_t-instead-of-unsigned-long.patch
-i386-init_intel_cacheinfo-can-be-__init.patch
-arch-i386-kernel-signalc-fix-err-test-twice.patch
-fix-num_online_nodes-warning-on-numa-q.patch
-x86_64-fix-cmp-with-interleaving.patch
-x86_64-fix-flush-race-on-context-switch.patch
-i386-x86-64-fix-smp-nmi-watchdog-race.patch
-x86-64-fix-pud-typo-in-ioremap.patch
-x86-64-fix-do_suspend_lowlevel.patch
-x86-64-clean-up-cpuid-level-detection.patch
-kprobes-x86_64-memory-allocation-changes.patch
-h8-300-defconfig-update.patch
-h8-300-mm-update.patch
-swsusp-remove-on2-algorithm-in-page-relocation.patch
-driver-model-pass-pm_message_t-down-to-pci-drivers.patch
-uml-provide-an-arch-specific-define-for-register-file-size.patch
-uml-provide-some-initcall-definitions-for-userspace-code.patch
-uml-provide-a-release-method-for-the-ubd-driver.patch
-uml-allow-ubd-devices-to-provide-partial-end-blocks.patch
-uml-change-for_each_cpu-to-for_each_online_cpu.patch
-uml-eliminate-unhandled-sigprof-on-halt.patch
-uml-fix-__pud_alloc-definition-to-match-the-declaration.patch
-uml-fix-a-stack-corruption-crash.patch
-uml-define-__have_arch_cmpxchg-on-x86.patch
-file_tableexpand_files-code-cleanup.patch
-file_tableexpand_files-code-cleanup-remove-debug.patch
-minor-ext3-speedup.patch
-move-read-only-and-immutable-checks-into-permission.patch
-factor-out-common-code-around-follow_link-invocation.patch
-radio-typhoon-use-correct-module_param-data-type.patch
-avoid-sparse-warning-due-to-time-interpolator.patch
-allow-all-architectures-to-set-config_debug_preempt.patch
-binfmt_elf-allow-mips-to-overrid-e_flags.patch
-remove-bogus-softirq_pending-usage-in-cris.patch
-switch-frw-to-use-local_soft_irq_pending.patch
-scripts-referencepl-treat-built-ino-as-conglomerate.patch
-vgacon-fixes-to-help-font-restauration-in-x11.patch
-use-official-unicodes-for-dec-vt-characters.patch
-ext3-commit-superblock-before-panicking.patch
-consolidate-arch-specific-resourceh-headers.patch
-use-wno-pointer-sign-for-gcc-40.patch
-fix-init_sighand-warning-on-mips.patch
-add-page_offset-to-mmh.patch
-minor-ipmi-driver-updates.patch
-completion-api-additions.patch
-convert-xfs-to-unlocked_ioctl-and-compat_ioctl.patch
-some-fixes-for-compat-ioctl.patch
-convert-infiniband-mad-driver-to-compat-unlocked_ioctl.patch
-support-compat_ioctl-for-block-devices.patch
-convert-cciss-to-compat_ioctl.patch
-add-compat_ioctl-to-frame-buffer-layer.patch
-convert-sis-fb-driver-to-compat_ioctl.patch
-convert-dv1394-driver-to-compat_ioctl.patch
-convert-video1394-driver-to-compat_ioctl.patch
-convert-amdtp-driver-to-compat_ioctl.patch
-fat-kill-fatfs_symsc.patch
-fat-merge-msdos_fs_isbh-into-msdos_fsh.patch
-fat-is_badchar-is_replacechr-is_skipchar-cleanup.patch
-fat-is_badchar-is_replacechr-is_skipchar-cleanup-cleanup.patch
-fat-return-better-error-codes-from.patch
-fat-manually-inline-shortname_info_to_lcase.patch
-fat-use-vprintk-instead-of-snprintf-with-static.patch
-fat-kill-unnecessary-kmap.patch
-fat-fs-fat-cachec-make-__fat_access-static.patch
-fat-lindent-fs-msdos-nameic.patch
-fat-lindent-fs-vfat-nameic.patch
-fat-lindent-fs-vfat-nameic-fix.patch
-fat-fs-fat-cleanup.patch
-fat-reserved-clusters-cleanup.patch
-fat-show-current-nls-config-even-if-its-default.patch
-lock-initializer-cleanup-ppc.patch
-lock-initializer-cleanup-m32r.patch
-lock-initializer-cleanup-video.patch
-lock-initializer-cleanup-ide.patch
-lock-initializer-cleanup-sound.patch
-lock-initializer-cleanup-sh.patch
-lock-initializer-cleanup-ppc64.patch
-lock-initializer-cleanup-security.patch
-lock-initializer-cleanup-core.patch
-lock-initializer-cleanup-media-drivers.patch
-lock-initializer-cleanup-block-devices.patch
-lock-initializer-cleanup-s390.patch
-lock-initializer-cleanup-usermode.patch
-lock-initializer-cleanup-scsi.patch
-lock-initializer-cleanup-sparc.patch
-lock-initializer-cleanup-v850.patch
-lock-initializer-cleanup-i386.patch
-lock-initializer-cleanup-drm.patch
-lock-initializer-cleanup-firewire.patch
-lock-initializer-cleanup-arm26.patch
-lock-initializer-cleanup-m68k.patch
-lock-initializer-cleanup-network-drivers.patch
-lock-initializer-cleanup-mtd.patch
-lock-initializer-cleanup-x86_64.patch
-lock-initializer-cleanup-filesystems.patch
-lock-initializer-cleanup-ia64.patch
-lock-initializer-cleanup-raid.patch
-lock-initializer-cleanup-isdn.patch
-lock-initializer-cleanup-parisc.patch
-lock-initializer-cleanup-sparc64.patch
-lock-initializer-cleanup-arm.patch
-lock-initializer-cleanup-misc-drivers.patch
-lock-initializer-cleanup-alpha.patch
-lock-initializer-cleanup-character-devices.patch
-lock-initializer-cleanup-drivers-serial.patch
-lock-initializer-cleanup-frv.patch
-typo-in-arch-x86_64-kconfig.patch

 Merged

+dib3000mc-build-fix.patch

 compile fix

+fbdev-screen-corruption-fix.patch

 fbdev screen corruption fix

+mips-fixed-conflicting-types.patch

 MIPS build fix

+bug-in-io_destroy-fs-aioc1248.patch

 AIO fix

+oprofile-falling-back-on-timer-interrupt-mode.patch

 opofile timer-mode fallback fix

+compat-ioctl-security-hook-fixup.patch

 Restore missing security hook

-bk-acpi-revert-20041210.patch

 Hopefully this is no longer needed

+hda_intel-fix.patch

 ALSA build fix

+tpm_msc-build-fix.patch
+tpm_atmel-build-fix.patch

 Fix Greg's stuff

+driver-model-more-pm_message_t-conversion.patch
+driver-model-more-pci_choose_states-are-needed.patch

 power management/driver model updates

+kbuild-no-redundant-srctree-in-tags-file.patch

 `make tags' fix

+mm-oom-killer-tunable.patch
+mm-keep-balance-between-different-classzones.patch
+mm-fix-several-oom-killer-bugs.patch
+mm-convert-memdie-to-an-atomic-thread-bitflag.patch
+make-used_math-smp-safe.patch
+mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
+mm-truncate-smp-race-fix.patch

 Various page allocator and oom killer fixes/updates

+simpler-topdown-mmap-layout-allocator.patch

 Simplify the virtual address layout logic

+alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch

 Fix clear_user_highpage on architectures with funky caches

+smc91x-power-down-phy-on-suspend.patch
+e100-locking-up-netconsole.patch

 net driver fixes

+ppc32-add-defconfigs-for-85xx-boards-updated.patch

 ppc32 defconfig updates

+ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
+ppc32-missing-call-to-ioremap-in-pci_iomap.patch
+ppc32-fix-pci2-io-space-mapping-on-cds.patch
+ppc32-add-support-for-pegasos-machines.patch

 ppc32 updates

+ppc64-limit-segment-tables-on-up-kernels.patch
+ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
+ppc64-fix-in_be64-definition.patch
+ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
+ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
+ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
+ppc64-replace-schedule_timeout-in-__cpu_up.patch
+ppc64-replace-schedule_timeout-in-die.patch
+ppc64-trivial-cleanup-eeh_region.patch
+ppc64-sparse-fixes-for-cpu-feature-constants.patch
+ppc64-use-kref-for-device_node-refcounting.patch
+ppc64-allow-eeh-to-be-disabled.patch
+ppc64-disable-some-boot-wrapper-debug.patch
+ppc64-problem-disabling-sysvipc.patch
+ppc64-enable-virtual-ethernet-and-virtual-scsi.patch

 ppc64 updates

+x86-remove-unused-function.patch

 cleanup

+x86_64-remove-centaur-mtrr-support.patch
+x86_64-remove-duplicated-includes.patch
+x86_64-enlarge-northbridge-numa-scan-mask.patch
+x86_64-remove-earlyprintk-help.patch
+x86_64-speed-up-suspend.patch

 x86_64 update

+h8300-fix-warning.patch
+h8300-makefile-update.patch

 H8/300 updates

+swsusp-comment-fix.patch

 Fix a comment

+kill-softirq_pending-fix.patch

 Remove softirq_pending()

+ext2-ext3-block-allocator-startup-fix.patch

 Fix ext2/ext3 block allocator buglet

+ext3-quota-leak-fix.patch

 Fix error-path quota leak

+ext3-fix-ea-in-inode-default-acl-creation.patch
+ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch

 EA/ACL fixes

+jbd-journal-overflow-fix.patch
+jbd-journal-overflow-fix-fixes.patch
+jbd-fix-against-journal-overflow.patch
+jbd-fix-against-journal-overflow-tidies.patch
+jbd-log-space-management-optimization.patch

 Various JBD corner-case fixes

+i4l-new-hfc_usb-driver-version.patch
+i4l-hfc-4s-and-hfc-8s-driver.patch

 i4l updates

+i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch

 Audio driver fix

+configurable-delay-before-mounting-root-device.patch

 Add `delay=' boot option

+fs-mbcachec-remove-an-unused-wait-queue-variable.patch

 Dead code

+device-mapper-fix-mirror-log-type-module-ref-count.patch
+device-mapper-remove-unused-bs_bio_init.patch
+device-mapper-add-presuspend-hook.patch
+device-mapper-optionally-bypass-a-bdget.patch
+device-mapper-fix-tb-stripe-data-corruption.patch

 DM updates

+arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch

 MAINTAINERS update

+problems-disabling-sysctl.patch

 Add sys32_sysctl stub

+genhd-rename-device_init.patch

 Namespace cleanup

+fix-race-between-the-nmi-code-and-the-cmos-clock.patch

 Fix race between concurrent accesses to the x86 CMOS chip

+infiniband-core-compat_ioctl-conversion-minor-fixes.patch
+infiniband-mthca-more-arbel-mem-free-support.patch
+infiniband-mthca-implement-modifying-port-attributes.patch
+infiniband-core-fix-port-capability-enums-bit-order.patch
+infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
+infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
+infiniband-mthca-optimize-event-queue-handling.patch
+infiniband-mthca-test-irq-routing-during-initialization.patch
+infiniband-ipoib-remove-uses-of-yield.patch
+infiniband-core-add-issm-userspace-support.patch
+infiniband-mthca-clean-up-ioremap-request_region-usage.patch
+infiniband-mthca-remove-x86-sse-pessimization.patch

 infiniband updates

+random-pt4-create-new-rol32-ror32-bitops.patch
+random-pt4-use-them-throughout-the-tree.patch
+random-pt4-kill-the-sha-variants.patch
+random-pt4-cleanup-sha-interface.patch
+random-pt4-move-sha-code-to-lib.patch
+random-pt4-replace-sha-with-faster-version.patch
+random-pt4-replace-sha-with-faster-version-fix.patch
+random-pt4-update-cryptolib-to-use-sha-fro-lib.patch
+random-pt4-move-halfmd4-to-lib.patch
+random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch
+random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch
+random-pt4-simplify-and-shrink-syncookie-code.patch
+random-pt4-move-syncookies-to-net.patch
+random-pt4-move-other-tcp-ip-bits-to-net.patch

 More random driver slash-and-burn

+posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
+posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch
+posix-timers-fix-posix-timers-signals-lock-order.patch
+posix-timers-cpu-clock-support-for-posix-timers.patch
+make-itimer_real-per-process.patch
+make-itimer_prof-itimer_virtual-per-process.patch
+make-rlimit_cpu-sigxcpu-per-process.patch

 Bunch of timekeeping updates, including per-thread cpu clocks.  Needs a
 patched glibc to test it.

+mips-fixed-ltt-build-errors.patch
+ltt-doesnt-build-on-x86_64.patch

 Fix ltt-induced MIPS build errors

+nfsacl-protocol-extension-for-nfsv3.patch
+nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
+nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch
+nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch
+nfsacl-allow-multiple-programs-to-share-the-same-transport.patch
+nfsacl-lazy-rpc-receive-buffer-allocation.patch
+nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch
+nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch
+nfsacl-add-noacl-nfs-mount-option.patch
+nfsacl-infrastructure-and-server-side-of-nfsacl.patch
+nfsacl-solaris-nfsacl-workaround.patch
+nfsacl-client-side-of-nfsacl.patch
+nfsacl-acl-umask-handling-workaround-in-nfs-client.patch
+nfsacl-cache-acls-on-the-nfs-client-side.patch

 ACLs for ther NFS client.

-jbd-remove-livelock-avoidance.patch

 Dropped - this optimisation was never right and I lost interest in it.

+sched-account-rt_tasks-as-iso_ticks.patch

 SCHED_ISO fix

+videotext-ioctls-changed-to-use-_io-macros.patch
+video-arv-remove-casts.patch
+video-w9966-remove-casts.patch
+video-zr36120-remove-casts.patch
+v4l-video-buf-update.patch
+v4l2-tuner-api-update.patch
+v4l-tuner-update.patch
+v4l-add-tveeprom-module.patch
+v4l-tvaudio-update.patch
+v4l-bttv-ir-input-driver-update.patch
+v4l-bttv-update.patch
+v4l-saa7134-module.patch

 v4l updates.

+crashdump-reserving-backup-region-for-kexec-based.patch

 crashdump-via-kexec update

+fix-architecture-names-in-hugetlbpagetxt.patch

 Documentation fix

+fuse-fix-llseek-on-device.patch

 FUSE fix

+kernel-configsc-make-a-variable-static.patch
+kernel-forkc-make-mm_cachep-static.patch
+kernel-kallsymsc-make-some-code-static.patch
+mm-page-writebackc-remove-an-unused-function.patch
+mm-shmemc-make-a-struct-static.patch
+make-loglevels-in-init-mainc-a-little-more-sane.patch
+isicom-use-null-for-pointer.patch
+remove-bouncing-email-address-of-hennus-bergman.patch
+cirrusfbc-make-some-code-static.patch
+matroxfb_basec-make-some-code-static.patch
+asiliantfbc-make-some-code-static.patch
+i386-apic-kconfig-cleanups.patch
+security-seclvlc-make-some-code-static.patch
+drivers-block-elevatorc-make-two-functions-static.patch
+drivers-block-rdc-make-two-variables-static.patch
+loopc-make-two-functions-static.patch
+remove-bouncing-email-address-of-thomas-hood.patch
+fs-adfs-dir_fc-remove-an-unused-function.patch
+drivers-char-moxac-if-0-an-unused-function.patch

 Little fixes.



number of patches in -mm: 534
number of changesets in external trees: 386
number of patches in -mm only: 517
total patches: 903




All 534 patches:


linus.patch

dib3000mc-build-fix.patch
  dib3000mc build fix

fbdev-screen-corruption-fix.patch
  fbdev: screen corruption fix

mips-fixed-conflicting-types.patch
  mips: fixed conflicting types

bug-in-io_destroy-fs-aioc1248.patch
  Fix BUG in io_destroy

oprofile-falling-back-on-timer-interrupt-mode.patch
  oprofile: falling back on timer interrupt mode

compat-ioctl-security-hook-fixup.patch
  compat ioctl security hook fixup

ia64-acpi-build-fix.patch
  ia64 acpi build fix

ia64-config_apci_numa-fix.patch
  ia64 CONFIG_APCI_NUMA fix

bk-acpi.patch

acpi-sleep-while-atomic-during-s3-resume-from-ram.patch
  acpi: sleep-while-atomic during S3 resume from ram

acpi-report-errors-in-fanc.patch
  ACPI: report errors in fan.c

acpi-flush-tlb-when-pagetable-changed.patch
  acpi: flush TLB when pagetable changed

acpi-kfree-fix.patch
  a

bk-agpgart.patch

bk-alsa.patch

hda_intel-fix.patch
  hda_intel macro expansion fix

bk-arm.patch

bk-cifs.patch

bk-driver-core.patch

tpm_msc-build-fix.patch
  tpm_msc-build-fix

tpm_atmel-build-fix.patch
  tpm_atmel build fix

driver-model-more-pm_message_t-conversion.patch
  driver model: more pm_message_t conversion

driver-model-more-pci_choose_states-are-needed.patch
  driver model: more pci_choose_state()s are needed

bk-drm.patch

bk-drm-via.patch

bk-i2c.patch

bk-ide-dev.patch

ide-dev-build-fix.patch
  ide-dev-build-fix

bk-input.patch

disable-sidewinder-debug-messages.patch
  Disable Sidewinder debug messages

bk-dtor-input.patch

kbuild-no-redundant-srctree-in-tags-file.patch
  kbuild: no redundant srctree in tags file

seagate-st3200822as-sata-disk-needs-to-be-in-sil_blacklist-as-well.patch
  Seagate ST3200822AS SATA disk needs to be in sil_blacklist as well

bk-netdev.patch

bk-ntfs.patch

prevent-pci_name_bus-buffer-overflows.patch
  prevent pci_name_bus() buffer overflows

maintainers-add-entry-for-qla2xxx-driver.patch
  MAINTAINERS: add entry for qla2xxx driver.

bk-scsi-rc-fixes.patch

bk-usb.patch

bk-xfs.patch

mm.patch
  add -mmN to EXTRAVERSION

fix-smm-failures-on-e750x-systems.patch
  fix SMM failures on E750x systems

mm-oom-killer-tunable.patch
  mm: oom-killer tunable

mm-keep-balance-between-different-classzones.patch
  mm: rework lower-zone protection initialisation

mm-fix-several-oom-killer-bugs.patch
  mm: fix several oom killer bugs

mm-convert-memdie-to-an-atomic-thread-bitflag.patch
  mm: convert memdie to an atomic thread bitflag

make-used_math-smp-safe.patch
  make used_math SMP-safe

mm-adjust-dirty-threshold-for-lowmem-only-mappings.patch
  mm: adjust dirty threshold for lowmem-only mappings

mm-truncate-smp-race-fix.patch
  mm: truncate SMP race fix

vm-pageout-throttling.patch
  vm: pageout throttling

orphaned-pagecache-memleak-fix.patch
  orphaned pagecache memleak fix

swapspace-layout-improvements.patch
  swapspace-layout-improvements

simpler-topdown-mmap-layout-allocator.patch
  simpler topdown mmap layout allocator

alloc_zeroed_user_highpage-to-fix-the-clear_user_highpage-issue.patch
  alloc_zeroed_user_highpage() to fix the clear_user_highpage issue

make-tree_lock-an-rwlock.patch
  make mapping->tree_lock an rwlock

must-fix.patch
  must fix lists update
  must fix list update
  mustfix update
  must-fix update
  mustfix lists

pcnet32-79c976-with-fiber-optic.patch
  pcnet32: 79c976 with fiber optic fix

add-omap-support-to-smc91x-ethernet-driver.patch
  Add OMAP support to smc91x Ethernet driver

b44-bounce-buffer-fix.patch
  b44 bounce buffering fix

netpoll-fix-napi-polling-race-on-smp.patch
  netpoll: fix NAPI polling race on SMP

tun-tan-arp-monitor-support.patch
  tun/tap ARP monitor support

atmel_cs-add-support-lg-lw2100n-wlan-pcmcia-card.patch
  atmel_cs: Add support LG LW2100N WLAN PCMCIA card

smc91x-power-down-phy-on-suspend.patch
  smc91x: power down PHY on suspend

e100-locking-up-netconsole.patch
  e100 locking up netconsole.

ppc32-add-defconfigs-for-85xx-boards-updated.patch
  ppc32: Add defconfigs for 85xx boards -- updated

ppc32-pmac-sleep-support-update.patch
  ppc32: pmac sleep support update

add-try_acquire_console_sem.patch
  Add try_acquire_console_sem

update-aty128fb-sleep-wakeup-code-for-new-powermac-changes.patch
  update aty128fb sleep/wakeup code for new powermac changes

radeonfb-massive-update-of-pm-code.patch
  radeonfb: massive update of PM code

radeonfb-build-fix.patch
  radeonfb-build-fix

ppc32-allow-usage-of-gen550-on-platforms-that-do-not-define.patch
  ppc32: allow usage of gen550 on platforms that do not define SERIAL_PORT_DFNS

ppc32-missing-call-to-ioremap-in-pci_iomap.patch
  ppc32: missing call to ioremap in pci_iomap()

ppc32-fix-pci2-io-space-mapping-on-cds.patch
  ppc32: fix PCI2 IO space mapping on CDS

ppc32-add-support-for-pegasos-machines.patch
  ppc32: Add support for Pegasos machines

ppc64-limit-segment-tables-on-up-kernels.patch
  ppc64: limit segment tables on UP kernels

ppc64-xmon-data-breakpoints-on-partitioned-systems.patch
  ppc64: xmon data breakpoints on partitioned systems

ppc64-fix-in_be64-definition.patch
  ppc64: fix in_be64 definition

ppc64-clear-msr_ri-earlier-in-syscall-exit-path.patch
  ppc64: clear MSR_RI earlier in syscall exit path

ppc64-replace-schedule_timeout-in-iseries_pci_reset.patch
  ppc64: replace schedule_timeout in iSeries_pci_reset

ppc64-replace-schedule_timeout-in-pseries_cpu_die.patch
  ppc64: replace schedule_timeout in pSeries_cpu_die

ppc64-replace-schedule_timeout-in-__cpu_up.patch
  ppc64: replace schedule_timeout in __cpu_up

ppc64-replace-schedule_timeout-in-die.patch
  ppc64: replace schedule_timeout in die

ppc64-trivial-cleanup-eeh_region.patch
  ppc64: trivial cleanup: EEH_REGION

ppc64-sparse-fixes-for-cpu-feature-constants.patch
  ppc64: sparse fixes for cpu feature constants

ppc64-use-kref-for-device_node-refcounting.patch
  ppc64: use kref for device_node refcounting

ppc64-allow-eeh-to-be-disabled.patch
  ppc64: allow EEH to be disabled

ppc64-disable-some-boot-wrapper-debug.patch
  ppc64: disable some boot wrapper debug

ppc64-problem-disabling-sysvipc.patch
  ppc64: problem disabling SYSVIPC

ppc64-enable-virtual-ethernet-and-virtual-scsi.patch
  ppc64: enable virtual ethernet and virtual scsi

ppc64-reloc_hide.patch

agpgart-allow-multiple-backends-to-be-initialized.patch
  agpgart: allow multiple backends to be initialized
  agpgart-allow-multiple-backends-to-be-initialized fix
  agpgart: add bridge assignment missed in agp_allocate_memory
  x86_64 agp failure fix

agpgart-add-agp_find_bridge-function.patch
  agpgart: add agp_find_bridge function

agpgart-allow-drivers-to-allocate-memory-local-to.patch
  agpgart: allow drivers to allocate memory local to the bridge

drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
  drm: add support for new multiple agp bridge agpgart api

fb-add-support-for-new-multiple-agp-bridge-agpgart-api.patch
  fb: add support for new multiple agp bridge agpgart api

agpgart-add-bridge-parameter-to-driver-functions.patch
  agpgart: add bridge parameter to driver functions

superhyway-bus-support.patch
  SuperHyway bus support

x86-no-interrupts-from-secondary-cpus-until-officially-online.patch
  x86: no interrupts from secondary CPUs until officially online

x86-remove-unused-function.patch
  x86: Remove unused function

x86_64-remove-centaur-mtrr-support.patch
  x86_64: remove centaur mtrr support

x86_64-remove-duplicated-includes.patch
  x86_64: remove duplicated includes

x86_64-enlarge-northbridge-numa-scan-mask.patch
  x86_64: Enlarge northbridge numa scan mask

x86_64-remove-earlyprintk-help.patch
  x86_64: Remove earlyprintk help

x86_64-speed-up-suspend.patch
  x86_64: Speed up suspend

xen-vmm-4-add-ptep_establish_new-to-make-va-available.patch
  Xen VMM #4: add ptep_establish_new to make va available

xen-vmm-4-return-code-for-arch_free_page.patch
  Xen VMM #4: return code for arch_free_page

xen-vmm-4-return-code-for-arch_free_page-fix.patch
  Get rid of arch_free_page() warning

xen-vmm-4-runtime-disable-of-vt-console.patch
  Xen VMM #4: runtime disable of VT console

xen-vmm-4-has_arch_dev_mem.patch
  Xen VMM #4: HAS_ARCH_DEV_MEM

xen-vmm-4-split-free_irq-into-teardown_irq.patch
  Xen VMM #4: split free_irq into teardown_irq

h8300-fix-warning.patch
  h8300: fix warning

h8300-makefile-update.patch
  h8300: makefile update

swsusp-comment-fix.patch
  swsusp: fix buggy comment

wacom-tablet-driver.patch
  wacom tablet driver

force-feedback-support-for-uinput.patch
  Force feedback support for uinput

kmap_atomic-takes-char.patch
  kmap_atomic takes char*

kmap_atomic-takes-char-fix.patch
  kmap_atomic-takes-char-fix

kmap_atomic-fallout.patch
  kmap_atomic fallout

kunmap-fallout-more-fixes.patch
  kunmap-fallout-more-fixes

make-sysrq-f-call-oom_kill.patch
  make sysrq-F call oom_kill()

allow-admin-to-enable-only-some-of-the-magic-sysrq-functions.patch
  Allow admin to enable only some of the Magic-Sysrq functions

sort-out-pci_rom_address_enable-vs-ioresource_rom_enable.patch
  Sort out PCI_ROM_ADDRESS_ENABLE vs IORESOURCE_ROM_ENABLE

irqpoll.patch
  irqpoll

poll-mini-optimisations.patch
  poll: mini optimisations

mtrr-size-and-base-debug.patch
  mtrr size-and-base debugging

cleanup-vc-array-access.patch
  cleanup vc array access

remove-console_macrosh.patch
  remove console_macros.h

merge-vt_struct-into-vc_data.patch
  merge vt_struct into vc_data

kill-softirq_pending.patch
  kill softirq_pending()

kill-softirq_pending-fix.patch
  kill-softirq_pending fix

clean-up-uts_release-usage.patch
  clean up UTS_RELEASE usage

3c59x-ethtool-provide-nic-specific-stats.patch
  3c59x ethtool: provide NIC-specific stats

ext2-ext3-block-allocator-startup-fix.patch
  ext2/ext3: block allocator startup fix

ext3-quota-leak-fix.patch
  ext3: fix error-path quota leak

ext3-ea-no-lock-needed-when-freeing-inode.patch
  ext3/ea: no lock needed when freeing inode

ext3-ea-set-the-ext3_feature_compat_ext_attr-for-in-inode-xattrs.patch
  ext3/ea: set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs

ext3-ea-documentation-fix.patch
  ext3/ea: documentation fix

ext3-ea-fix-i_extra_isize-check.patch
  ext3/ea: ix i_extra_isize check

ext3-ea-disallow-in-inode-attributes-for-reserved-inodes.patch
  ext3/ea: disallow in-inode attributes for reserved inodes

ext3-fix-ea-in-inode-default-acl-creation.patch
  ext3: fix ea-in-inode default ACL creation

ext2-ext3-acls-remove-the-number-of-acl-entries-limit.patch
  ext2/ext3 ACLs: remove the number of acl entries limit

jbd-journal-overflow-fix.patch
  JBD: journal overflow fix

jbd-journal-overflow-fix-fixes.patch
  jbd-journal-overflow-fix-fixes

jbd-fix-against-journal-overflow.patch
  JBD: fix against journal overflow

jbd-fix-against-journal-overflow-tidies.patch
  jbd-fix-against-journal-overflow-tidies

jbd-log-space-management-optimization.patch
  JBD: log space management optimization

i4l-new-hfc_usb-driver-version.patch
  i4l: new hfc_usb driver version

i4l-hfc-4s-and-hfc-8s-driver.patch
  i4l: HFC-4S and HFC-8S driver

i810_audio-offset-lvi-from-civ-to-avoid-stalled-start.patch
  i810_audio: offset LVI from CIV to avoid stalled start

configurable-delay-before-mounting-root-device.patch
  Configurable delay before mounting root device

fs-mbcachec-remove-an-unused-wait-queue-variable.patch
  fs/mbcache.c: Remove an unused wait queue variable

device-mapper-fix-mirror-log-type-module-ref-count.patch
  device-mapper: fix mirror log type module ref count

device-mapper-remove-unused-bs_bio_init.patch
  device-mapper: remove unused bs_bio_init()

device-mapper-add-presuspend-hook.patch
  device-mapper: Add presuspend hook

device-mapper-optionally-bypass-a-bdget.patch
  device-mapper: optionally bypass a bdget

device-mapper-fix-tb-stripe-data-corruption.patch
  device-mapper: fix TB stripe data corruption

arm26-new-maintainer-of-archimedes-floppy-and-hard-disk-drivers.patch
  arm26: new maintainer of Archimedes floppy and hard disk drivers

problems-disabling-sysctl.patch
  Problems disabling SYSCTL

genhd-rename-device_init.patch
  genhd: rename device_init

fix-race-between-the-nmi-code-and-the-cmos-clock.patch
  Fix race between the NMI code and the CMOS clock

infiniband-core-compat_ioctl-conversion-minor-fixes.patch
  InfiniBand/core: compat_ioctl conversion minor fixes

infiniband-mthca-more-arbel-mem-free-support.patch
  InfiniBand/mthca: more Arbel Mem-Free support

infiniband-mthca-implement-modifying-port-attributes.patch
  InfiniBand/mthca: implement modifying port attributes

infiniband-core-fix-port-capability-enums-bit-order.patch
  InfiniBand/core: fix port capability enums bit order

infiniband-mthca-dont-write-ecr-in-msi-x-mode.patch
  InfiniBand/mthca: don't write ECR in MSI-X mode

infiniband-mthca-pass-full-process_mad-info-to-firmware.patch
  InfiniBand/mthca: pass full process_mad info to firmware

infiniband-mthca-optimize-event-queue-handling.patch
  InfiniBand/mthca: optimize event queue handling

infiniband-mthca-test-irq-routing-during-initialization.patch
  InfiniBand/mthca: test IRQ routing during initialization

infiniband-ipoib-remove-uses-of-yield.patch
  InfiniBand/ipoib: remove uses of yield()

infiniband-core-add-issm-userspace-support.patch
  InfiniBand/core: add IsSM userspace support

infiniband-mthca-clean-up-ioremap-request_region-usage.patch
  InfiniBand/mthca: clean up ioremap()/request_region() usage

infiniband-mthca-remove-x86-sse-pessimization.patch
  InfiniBand/mthca: remove x86 SSE pessimization

random-pt2-cleanup-waitqueue-logic-fix-missed-wakeup.patch
  random: cleanup waitqueue logic, fix missed wakeup

random-pt2-kill-pool-clearing.patch
  random: kill pool clearing

random-pt2-combine-legacy-ioctls.patch
  random: combine legacy ioctls

random-pt2-re-init-all-pools-on-zero.patch
  random: re-init all pools on zero

random-pt2-simplify-initialization.patch
  random: simplify initialization

random-pt2-kill-memsets-of-static-data.patch
  random: kill memsets of static data

random-pt2-kill-dead-extract_state-struct.patch
  random: kill dead extract_state struct

random-pt2-kill-22-compat-waitqueue-defs.patch
  random: kill 2.2 compat waitqueue defs

random-pt2-kill-redundant-rotate_left-definitions.patch
  random: kill redundant rotate_left definitions

random-pt2-kill-misnamed-log2.patch
  random: kill misnamed log2

random-pt3-more-meaningful-pool-names.patch
  random: More meaningful pool names

random-pt3-static-allocation-of-pools.patch
  random: Static allocation of pools

random-pt3-static-sysctl-bits.patch
  random: Static sysctl bits

random-pt3-catastrophic-reseed-checks.patch
  random: Catastrophic reseed checks

random-pt3-entropy-reservation-accounting.patch
  random: Entropy reservation accounting

random-pt3-reservation-flag-in-pool-struct.patch
  random: Reservation flag in pool struct

random-pt3-reseed-pointer-in-pool-struct.patch
  random: Reseed pointer in pool struct

random-pt3-break-up-extract_user.patch
  random: Break up extract_user

random-pt3-remove-dead-md5-copy.patch
  random: Remove dead MD5 copy

random-pt3-simplify-hash-folding.patch
  random: Simplify hash folding

random-pt3-clean-up-hash-buffering.patch
  random: Clean up hash buffering

random-pt3-remove-entropy-batching.patch
  random: Remove entropy batching

random-pt4-create-new-rol32-ror32-bitops.patch
  random: Create new rol32/ror32 bitops

random-pt4-use-them-throughout-the-tree.patch
  random: Use them throughout the tree

random-pt4-kill-the-sha-variants.patch
  random: Kill the SHA variants

random-pt4-cleanup-sha-interface.patch
  random: Cleanup SHA interface

random-pt4-move-sha-code-to-lib.patch
  random: Move SHA code to lib/

random-pt4-replace-sha-with-faster-version.patch
  random: Replace SHA with faster version

random-pt4-replace-sha-with-faster-version-fix.patch
  random-pt4-replace-sha-with-faster-version-fix

random-pt4-update-cryptolib-to-use-sha-fro-lib.patch
  random: Update cryptolib to use SHA fro lib

random-pt4-move-halfmd4-to-lib.patch
  random: Move halfmd4 to lib

random-pt4-kill-duplicate-halfmd4-in-ext3-htree.patch
  random: Kill duplicate halfmd4 in ext3 htree

random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix.patch
  random-pt4-kill-duplicate-halfmd4-in-ext3-htree-fix

random-pt4-simplify-and-shrink-syncookie-code.patch
  random: Simplify and shrink syncookie code

random-pt4-move-syncookies-to-net.patch
  random: Move syncookies to net/

random-pt4-move-other-tcp-ip-bits-to-net.patch
  random: Move other tcp/ip bits to net/

speedup-proc-pid-maps.patch
  Speed up /proc/pid/maps

speedup-proc-pid-maps-fix.patch
  Speed up /proc/pid/maps fix

speedup-proc-pid-maps-fix-fix.patch
  speedup-proc-pid-maps fix fix

speedup-proc-pid-maps-fix-fix-fix.patch
  speedup /proc/<pid>/maps(4th version)

fix-loss-of-records-on-size-4096-in-proc-pid-maps.patch
  fix loss of records on size > 4096 in proc/<pid>/maps

speedup-proc-pid-maps-fix-fix-fix-fix.patch
  speedup-proc-pid-maps-fix-fix-fix fix

inotify.patch
  inotify

posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
  posix-timers: tidy up clock interfaces and consolidate dispatch logic

posix-timers-high-resolution-cpu-clocks-for-posix-clock_-syscalls.patch
  posix-timers: high-resolution CPU clocks for POSIX clock_* syscalls

posix-timers-fix-posix-timers-signals-lock-order.patch
  posix-timers: fix posix-timers signals lock order

posix-timers-cpu-clock-support-for-posix-timers.patch
  posix-timers: CPU clock support for POSIX timers

make-itimer_real-per-process.patch
  make ITIMER_REAL per-process

make-itimer_prof-itimer_virtual-per-process.patch
  make ITIMER_PROF, ITIMER_VIRTUAL per-process

make-rlimit_cpu-sigxcpu-per-process.patch
  make RLIMIT_CPU/SIGXCPU per-process

relayfs-doc.patch
  relayfs: doc

relayfs-common-files.patch
  relayfs: common files

relayfs-remove-klog-debugging-channel.patch
  relayfs - remove klog debugging channel

relayfs-locking-lockless-implementation.patch
  relayfs: locking/lockless implementation

relayfs-headers.patch
  relayfs: headers

relayfs-remove-klog-debugging-channel-headers.patch
  relayfs - remove klog debugging channel

ltt-core-implementation.patch
  ltt: core implementation

ltt-core-headers.patch
  ltt: core headers

mips-fixed-ltt-build-errors.patch
  mips: fixed LTT build errors

ltt-kconfig-fix.patch
  ltt kconfig fix

ltt-doesnt-build-on-x86_64.patch
  ltt doesn't build on x86_64

ltt-kernel-events.patch
  ltt: kernel/ events

ltt-kernel-events-tidy.patch
  ltt-kernel-events tidy

ltt-kernel-events-build-fix.patch
  ltt-kernel-events-build-fix

ltt-fs-events.patch
  ltt: fs/ events

ltt-fs-events-tidy.patch
  ltt-fs-events tidy

ltt-ipc-events.patch
  ltt: ipc/ events

ltt-mm-events.patch
  ltt: mm/ events

ltt-net-events.patch
  ltt: net/ events

ltt-architecture-events.patch
  ltt: architecture events

pcmcia-tcic-eleminate-deprecated-check_region.patch
  pcmcia: tcic: eleminate deprecated check_region()

pcmcia-i82365-use-config_pnp-instead-of-__isapnp__.patch
  pcmcia: i82365: use CONFIG_PNP instead of __ISAPNP__

pcmcia-i82092-fix-checking-of-return-value-from-request_region.patch
  pcmcia: i82092: fix checking of return value from request_region

pcmcia-socket-acregion-are-unused.patch
  pcmcia: socket->{a,c}region are unused

pcmcia-use-unsigned-long-for-io-port-address.patch
  pcmcia: use unsigned long for IO port address

nfs-fix_vfsflock.patch
  VFS: Fix structure initialization in locks_remove_flock()

nfs-flock.patch
  NFS: Add emulation of BSD flock() in terms of POSIX locks on the server

nfsacl-protocol-extension-for-nfsv3.patch
  NFSACL protocol extension for NFSv3: generalise qsort()

nfsacl-return-enosys-for-rpc-programs-that-are-unavailable.patch
  nfsacl: return -ENOSYS for RPC programs that are unavailable

nfsacl-add-missing-eopnotsupp-=-nfs3err_notsupp-mapping-in-nfsd.patch
  nfsacl: add missing -EOPNOTSUPP => NFS3ERR_NOTSUPP mapping in nfsd

nfsacl-allow-multiple-programs-to-listen-on-the-same-port.patch
  nfsacl: allow multiple programs to listen on the same port

nfsacl-allow-multiple-programs-to-share-the-same-transport.patch
  nfsacl: allow multiple programs to share the same transport

nfsacl-lazy-rpc-receive-buffer-allocation.patch
  nfsacl: lazy RPC receive buffer allocation

nfsacl-encode-and-decode-arbitrary-xdr-arrays.patch
  nfsacl: encode and decode arbitrary XDR arrays

nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix.patch
  nfsacl-encode-and-decode-arbitrary-xdr-arrays-fix

nfsacl-add-noacl-nfs-mount-option.patch
  nfsacl: add noacl nfs mount option

nfsacl-infrastructure-and-server-side-of-nfsacl.patch
  nfsacl: infrastructure and server side of nfsacl

nfsacl-solaris-nfsacl-workaround.patch
  nfsacl: solaris nfsacl workaround

nfsacl-client-side-of-nfsacl.patch
  nfsacl: client side of nfsacl

nfsacl-acl-umask-handling-workaround-in-nfs-client.patch
  nfsacl: aCL umask handling workaround in nfs client

nfsacl-cache-acls-on-the-nfs-client-side.patch
  nfsacl: cache acls on the nfs client side

kgdb-ga.patch
  kgdb stub for ia32 (George Anzinger's one)
  kgdbL warning fix
  kgdb buffer overflow fix
  kgdbL warning fix
  kgdb: CONFIG_DEBUG_INFO fix
  x86_64 fixes
  correct kgdb.txt Documentation link (against  2.6.1-rc1-mm2)
  kgdb: fix for recent gcc
  kgdb warning fixes
  THREAD_SIZE fixes for kgdb
  Fix stack overflow test for non-8k stacks
  kgdb-ga.patch fix for i386 single-step into sysenter
  fix TRAP_BAD_SYSCALL_EXITS on i386
  add TRAP_BAD_SYSCALL_EXITS config for i386
  kgdb-is-incompatible-with-kprobes
  kgdb-ga-build-fix
  kgdb-ga-fixes

kgdb-kill-off-highmem_start_page.patch
  kgdb: kill off highmem_start_page

kgdboe-netpoll.patch
  kgdb-over-ethernet via netpoll
  kgdboe: fix configuration of MAC address

kgdb-x86_64-support.patch
  kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
  kgdb-x86_64-warning-fixes
  kgdb-x86_64-fix
  kgdb-x86_64-serial-fix
  kprobes exception notifier fix

dev-mem-restriction-patch.patch
  /dev/mem restriction patch

dev-mem-restriction-patch-allow-reads.patch
  dev-mem-restriction-patch: allow reads

journal_add_journal_head-debug.patch
  journal_add_journal_head-debug

list_del-debug.patch
  list_del debug check

unplug-can-sleep.patch
  unplug functions can sleep

firestream-warnings.patch
  firestream warnings

perfctr-core.patch
  perfctr: core
  perfctr: remove bogus perfctr_sample_thread() calls

perfctr-i386.patch
  perfctr: i386

perfctr-x86-core-updates.patch
  perfctr x86 core updates

perfctr-x86-driver-updates.patch
  perfctr x86 driver updates

perfctr-x86-driver-cleanup.patch
  perfctr: x86 driver cleanup

perfctr-prescott-fix.patch
  Prescott fix for perfctr

perfctr-x86-update-2.patch
  perfctr x86 update 2

perfctr-x86_64.patch
  perfctr: x86_64

perfctr-x86_64-core-updates.patch
  perfctr x86_64 core updates

perfctr-ppc.patch
  perfctr: PowerPC

perfctr-ppc32-driver-update.patch
  perfctr: ppc32 driver update

perfctr-ppc32-mmcr0-handling-fixes.patch
  perfctr ppc32 MMCR0 handling fixes

perfctr-ppc32-update.patch
  perfctr ppc32 update

perfctr-ppc32-update-2.patch
  perfctr ppc32 update

perfctr-virtualised-counters.patch
  perfctr: virtualised counters

perfctr-remap_page_range-fix.patch

virtual-perfctr-illegal-sleep.patch
  virtual perfctr illegal sleep

make-perfctr_virtual-default-in-kconfig-match-recommendation.patch
  Make PERFCTR_VIRTUAL default in Kconfig match recommendation  in help text

perfctr-ifdef-cleanup.patch
  perfctr ifdef cleanup

perfctr-update-2-6-kconfig-related-updates.patch
  perfctr: Kconfig-related updates

perfctr-virtual-updates.patch
  perfctr virtual updates

perfctr-virtual-cleanup.patch
  perfctr: virtual cleanup

perfctr-ppc32-preliminary-interrupt-support.patch
  perfctr ppc32 preliminary interrupt support

perfctr-update-5-6-reduce-stack-usage.patch
  perfctr: reduce stack usage

perfctr-interrupt-support-kconfig-fix.patch
  perfctr interrupt_support Kconfig fix

perfctr-low-level-documentation.patch
  perfctr low-level documentation

perfctr-inheritance-1-3-driver-updates.patch
  perfctr inheritance: driver updates

perfctr-inheritance-2-3-kernel-updates.patch
  perfctr inheritance: kernel updates

perfctr-inheritance-3-3-documentation-updates.patch
  perfctr inheritance: documentation updates

perfctr-inheritance-locking-fix.patch
  perfctr inheritance locking fix

perfctr-api-changes-first-step.patch
  perfctr API changes: first step

perfctr-virtual-update.patch
  perfctr virtual update

perfctr-x86-64-ia32-emulation-fix.patch
  perfctr x86-64 ia32 emulation fix

perfctr-sysfs-update-1-4-core.patch
  perfctr sysfs update: core

perfctr-sysfs-update.patch
  Perfctr sysfs update

perfctr-sysfs-update-2-4-x86.patch
  perfctr sysfs update: x86

perfctr-sysfs-update-3-4-x86-64.patch
  perfctr sysfs update: x86-64
  perfctr: syscall numbers in x86-64 ia32-emulation
  perfctr x86_64 native syscall numbers fix

perfctr-sysfs-update-4-4-ppc32.patch
  perfctr sysfs update: ppc32

sched-fix-preemption-race-core-i386.patch
  sched: fix preemption race (Core/i386)

sched-make-use-of-preempt_schedule_irq-ppc.patch
  sched: make use of preempt_schedule_irq() (PPC)

sched-make-use-of-preempt_schedule_irq-arm.patch
  sched: make use of preempt_schedule_irq (ARM)

sched-isochronous-class-for-unprivileged-soft-rt-scheduling.patch
  sched: Isochronous class for unprivileged soft rt scheduling

sched-account-rt_tasks-as-iso_ticks.patch
  sched: account rt_tasks as iso_ticks

add-do_proc_doulonglongvec_minmax-to-sysctl-functions.patch
  Add do_proc_doulonglongvec_minmax to sysctl functions
  add-do_proc_doulonglongvec_minmax-to-sysctl-functions-fix
  add-do_proc_doulonglongvec_minmax-to-sysctl-functions fix 2

add-sysctl-interface-to-sched_domain-parameters.patch
  Add sysctl interface to sched_domain parameters

videotext-ioctls-changed-to-use-_io-macros.patch
  videotext: ioctls changed to use _IO macros

video-arv-remove-casts.patch
  video/arv: remove casts

video-w9966-remove-casts.patch
  video/w9966: remove casts

video-zr36120-remove-casts.patch
  video/zr36120: remove casts

v4l-video-buf-update.patch
  v4l: video-buf update

v4l2-tuner-api-update.patch
  v4l2 tuner api update

v4l-tuner-update.patch
  v4l: tuner update

v4l-add-tveeprom-module.patch
  v4l: add tveeprom module.

v4l-tvaudio-update.patch
  v4l: tvaudio update

v4l-bttv-ir-input-driver-update.patch
  v4l: bttv IR input driver update

v4l-bttv-update.patch
  v4l: bttv update

v4l-saa7134-module.patch
  v4l: saa7134 module

allow-modular-ide-pnp.patch
  allow modular ide-pnp

allow-x86_64-to-reenable-interrupts-on-contention.patch
  Allow x86_64 to reenable interrupts on contention

i386-cpu-hotplug-updated-for-mm.patch
  i386 CPU hotplug updated for -mm

ppc64-fix-cpu-hotplug.patch
  ppc64: fix hotplug cpu

serialize-access-to-ide-devices.patch
  serialize access to ide devices

disable-atykb-warning.patch
  disable atykb "too many keys pressed" warning

export-file_ra_state_init-again.patch
  Export file_ra_state_init() again

cachefs-filesystem.patch
  CacheFS filesystem

numa-policies-for-file-mappings-mpol_mf_move-cachefs.patch
  numa-policies-for-file-mappings-mpol_mf_move for cachefs

cachefs-release-search-records-lest-they-return-to-haunt-us.patch
  CacheFS: release search records lest they return to haunt us

fix-64-bit-problems-in-cachefs.patch
  Fix 64-bit problems in cachefs

cachefs-fixed-typos-that-cause-wrong-pointer-to-be-kunmapped.patch
  cachefs: fixed typos that cause wrong pointer to be kunmapped

cachefs-return-the-right-error-upon-invalid-mount.patch
  CacheFS: return the right error upon invalid mount

fix-cachefs-barrier-handling-and-other-kernel-discrepancies.patch
  Fix CacheFS barrier handling and other kernel discrepancies

remove-error-from-linux-cachefsh.patch
  Remove #error from linux/cachefs.h

cachefs-warning-fix-2.patch
  cachefs warning fix 2

cachefs-linkage-fix-2.patch
  cachefs linkage fix

cachefs-build-fix.patch
  cachefs build fix

cachefs-documentation.patch
  CacheFS documentation

add-page-becoming-writable-notification.patch
  Add page becoming writable notification

add-page-becoming-writable-notification-fix.patch
  do_wp_page_mk_pte_writable() fix

add-page-becoming-writable-notification-build-fix.patch
  add-page-becoming-writable-notification build fix

provide-a-filesystem-specific-syncable-page-bit.patch
  Provide a filesystem-specific sync'able page bit

provide-a-filesystem-specific-syncable-page-bit-fix.patch
  provide-a-filesystem-specific-syncable-page-bit-fix

provide-a-filesystem-specific-syncable-page-bit-fix-2.patch
  provide-a-filesystem-specific-syncable-page-bit-fix-2

make-afs-use-cachefs.patch
  Make AFS use CacheFS

afs-cachefs-dependency-fix.patch
  afs-cachefs-dependency-fix

split-general-cache-manager-from-cachefs.patch
  Split general cache manager from CacheFS

turn-cachefs-into-a-cache-backend.patch
  Turn CacheFS into a cache backend

rework-the-cachefs-documentation-to-reflect-fs-cache-split.patch
  Rework the CacheFS documentation to reflect FS-Cache split

update-afs-client-to-reflect-cachefs-split.patch
  Update AFS client to reflect CacheFS split

x86-rename-apic_mode_exint.patch
  kexec: x86: rename APIC_MODE_EXINT

x86-local-apic-fix.patch
  kexec: x86: local apic fix

x86_64-e820-64bit.patch
  kexec: x86_64: e820 64bit fix

x86-i8259-shutdown.patch
  kexec: x86: i8259 shutdown: disable interrupts

x86_64-i8259-shutdown.patch
  kexec: x86_64: add i8259 shutdown method

x86-apic-virtwire-on-shutdown.patch
  kexec: x86: resture apic virtual wire mode on shutdown

x86_64-apic-virtwire-on-shutdown.patch
  kexec: x86_64: restore apic virtual wire mode on shutdown

vmlinux-fix-physical-addrs.patch
  kexec: vmlinux: fix physical addresses

x86-vmlinux-fix-physical-addrs.patch
  kexec: x86: vmlinux: fix physical addresses

x86_64-vmlinux-fix-physical-addrs.patch
  kexec: x86_64: vmlinux: fix physical addresses

x86_64-entry64.patch
  kexec: x86_64: add 64-bit entry

x86-config-kernel-start.patch
  kexec: x86: add CONFIG_PYSICAL_START

x86_64-config-kernel-start.patch
  kexec: x86_64: add CONFIG_PHYSICAL_START

kexec-kexec-generic.patch
  kexec: add kexec syscalls

x86-machine_shutdown.patch
  kexec: x86: factor out apic shutdown code

x86-kexec.patch
  kexec: x86 kexec core

x86-crashkernel.patch
  crashdump: x86 crashkernel option

x86_64-machine_shutdown.patch
  kexec: x86_64: factor out apic shutdown code

x86_64-kexec.patch
  kexec: x86_64 kexec implementation

x86_64-crashkernel.patch
  crashdump: x86_64: crashkernel option

kexec-ppc-support.patch
  kexec: kexec ppc support

x86-crash_shutdown-nmi-shootdown.patch
  crashdump: x86: add NMI handler to capture other CPUs

x86-crash_shutdown-snapshot-registers.patch
  kexec: x86: snapshot registers during crash shutdown

x86-crash_shutdown-apic-shutdown.patch
  kexec: x86 shutdown APICs during crash_shutdown

crashdump-documentation.patch
  crashdump: documentation

crashdump-memory-preserving-reboot-using-kexec.patch
  crashdump: memory preserving reboot using kexec

crashdump-routines-for-copying-dump-pages.patch
  crashdump: routines for copying dump pages

crashdump-elf-format-dump-file-access.patch
  crashdump: elf format dump file access

crashdump-linear-raw-format-dump-file-access.patch
  crashdump: linear raw format dump file access

crashdump-reserving-backup-region-for-kexec-based.patch
  crashdump: reserving backup region for kexec based crashdumps.

new-bitmap-list-format-for-cpusets.patch
  new bitmap list format (for cpusets)

cpusets-big-numa-cpu-and-memory-placement.patch
  cpusets - big numa cpu and memory placement

cpusets-config_cpusets-depends-on-smp.patch
  Cpusets: CONFIG_CPUSETS depends on SMP

cpusets-move-cpusets-above-embedded.patch
  move CPUSETS above EMBEDDED

cpusets-fix-cpuset_get_dentry.patch
  cpusets : fix cpuset_get_dentry()

cpusets-fix-race-in-cpuset_add_file.patch
  cpusets: fix race in cpuset_add_file()

cpusets-remove-more-casts.patch
  cpusets: remove more casts

cpusets-make-config_cpusets-the-default-in-sn2_defconfig.patch
  cpusets: make CONFIG_CPUSETS the default in sn2_defconfig

cpusets-document-proc-status-allowed-fields.patch
  cpusets: document proc status allowed fields

cpusets-dont-export-proc_cpuset_operations.patch
  Cpusets - Dont export proc_cpuset_operations

cpusets-display-allowed-masks-in-proc-status.patch
  cpusets: display allowed masks in proc status

cpusets-simplify-cpus_allowed-setting-in-attach.patch
  cpusets: simplify cpus_allowed setting in attach

cpusets-remove-useless-validation-check.patch
  cpusets: remove useless validation check

cpusets-tasks-file-simplify-format-fixes.patch
  Cpusets tasks file: simplify format, fixes

cpusets-simplify-memory-generation.patch
  Cpusets: simplify memory generation

cpusets-interoperate-with-hotplug-online-maps.patch
  cpusets: interoperate with hotplug online maps

cpusets-alternative-fix-for-possible-race-in.patch
  cpusets: alternative fix for possible race in  cpuset_tasks_read()

cpusets-remove-casts.patch
  cpusets: remove void* typecasts

reiser4-sb_sync_inodes.patch
  reiser4: vfs: add super_operations.sync_inodes()

reiser4-allow-drop_inode-implementation.patch
  reiser4: export vfs inode.c symbols

reiser4-truncate_inode_pages_range.patch
  reiser4: vfs: add truncate_inode_pages_range()

reiser4-export-remove_from_page_cache.patch
  reiser4: export pagecache add/remove functions to modules

reiser4-export-page_cache_readahead.patch
  reiser4: export page_cache_readahead to modules

reiser4-reget-page-mapping.patch
  reiser4: vfs: re-check page->mapping after calling try_to_release_page()

reiser4-rcu-barrier.patch
  reiser4: add rcu_barrier() synchronization point

reiser4-export-inode_lock.patch
  reiser4: export inode_lock to modules

reiser4-export-pagevec-funcs.patch
  reiser4: export pagevec functions to modules

reiser4-export-radix_tree_preload.patch
  reiser4: export radix_tree_preload() to modules

reiser4-export-find_get_pages.patch

reiser4-radix-tree-tag.patch
  reiser4: add new radix tree tag

reiser4-radix_tree_lookup_slot.patch
  reiser4: add radix_tree_lookup_slot()

reiser4-perthread-pages.patch
  reiser4: per-thread page pools

reiser4-include-reiser4.patch
  reiser4: add to build system

reiser4-doc.patch
  reiser4: documentation

reiser4-only.patch
  reiser4: main fs

reiser4-recover-read-performance.patch
  reiser4: recover read performance

reiser4-export-find_get_pages_tag.patch
  reiser4-export-find_get_pages_tag

reiser4-add-missing-context.patch

add-acpi-based-floppy-controller-enumeration.patch
  Add ACPI-based floppy controller enumeration.

possible-dcache-bug-debugging-patch.patch
  Possible dcache BUG: debugging patch

serial-add-support-for-non-standard-xtals-to-16c950-driver.patch
  serial: add support for non-standard XTALs to 16c950 driver

add-support-for-possio-gcc-aka-pcmcia-siemens-mc45.patch
  Add support for Possio GCC AKA PCMCIA Siemens MC45

generic-serial-cli-conversion.patch
  generic-serial cli() conversion

specialix-io8-cli-conversion.patch
  Specialix/IO8 cli() conversion

sx-cli-conversion.patch
  SX cli() conversion

revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions.patch
  revert "allow OEM written modules to make calls to ia64 OEM SAL functions"

md-add-interface-for-userspace-monitoring-of-events.patch
  md: add interface for userspace monitoring of events.

make-acpi_bus_register_driver-consistent-with-pci_register_driver-again.patch
  make acpi_bus_register_driver() consistent with pci_register_driver()

remove-lock_section-from-x86_64-spin_lock-asm.patch
  remove LOCK_SECTION from x86_64 spin_lock asm

kfree_skb-dump_stack.patch
  kfree_skb-dump_stack

cancel_rearming_delayed_work.patch
  cancel_rearming_delayed_work()
  make cancel_rearming_delayed_workqueue static

ipvs-deadlock-fix.patch
  ipvs deadlock fix

minimal-ide-disk-updates.patch
  Minimal ide-disk updates

use-find_trylock_page-in-free_swap_and_cache-instead-of-hand-coding.patch
  use find_trylock_page in free_swap_and_cache instead of hand coding

radeonfb-set-accelerator-id.patch
  radeonfb: Set accelerator id

vesafb-change-return-error-id.patch
  vesafb: Change return error id

intelfb-workaround-for-830m.patch
  intelfb: Workaround for 830M

fbcon-save-blank-state-last.patch
  fbcon: Save blank state last

backlight-fix-compile-error-if-config_fb-is-unset.patch
  backlight: Fix compile error if CONFIG_FB is unset

matroxfb-fb_matrox_g-kconfig-changes.patch
  matroxfb: FB_MATROX_G Kconfig changes

raid5-overlapping-read-hack.patch
  raid5 overlapping read hack

include-type-information-as-module-info-where-possible.patch
  Include type information as module info where possible

figure-out-who-is-inserting-bogus-modules.patch
  Figure out who is inserting bogus modules

detect-atomic-counter-underflows.patch
  detect atomic counter underflows

post-halloween-doc.patch
  post halloween doc

fix-architecture-names-in-hugetlbpagetxt.patch
  fix architecture names in hugetlbpage.txt

periodically-scan-redzone-entries-and-slab-control-structures.patch
  periodically scan redzone entries and slab control structures

fuse-maintainers-kconfig-and-makefile-changes.patch
  Subject: [PATCH 1/11] FUSE - MAINTAINERS, Kconfig and Makefile changes

fuse-core.patch
  Subject: [PATCH 2/11] FUSE - core

fuse-device-functions.patch
  Subject: [PATCH 3/11] FUSE - device functions

fuse-fix-llseek-on-device.patch
  FUSE: fix llseek on device

fuse-make-two-functions-static.patch
  fuse: make two functions static

fuse-fix-variable-with-confusing-name.patch
  fuse: fix variable with confusing name

fuse-read-only-operations.patch
  Subject: [PATCH 4/11] FUSE - read-only operations

fuse-read-write-operations.patch
  Subject: [PATCH 5/11] FUSE - read-write operations

fuse-file-operations.patch
  Subject: [PATCH 6/11] FUSE - file operations

fuse-mount-options.patch
  Subject: [PATCH 7/11] FUSE - mount options

fuse-dont-check-against-zero-fsuid.patch
  fuse: don't check against zero fsuid

fuse-remove-mount_max-and-user_allow_other-module-parameters.patch
  fuse: remove mount_max and user_allow_other module parameters

fuse-extended-attribute-operations.patch
  Subject: [PATCH 8/11] FUSE - extended attribute operations

fuse-readpages-operation.patch
  Subject: [PATCH 9/11] FUSE - readpages operation

fuse-nfs-export.patch
  Subject: [PATCH 10/11] FUSE - NFS export

fuse-direct-i-o.patch
  Subject: [PATCH 11/11] FUSE - direct I/O

fuse-transfer-readdir-data-through-device.patch
  fuse: transfer readdir data through device

ieee1394-adds-a-disable_irm-option-to-ieee1394ko.patch
  ieee1394: add a disable_irm option to ieee1394.ko

cryptoapi-prepare-for-processing-multiple-buffers-at.patch
  CryptoAPI: prepare for processing multiple buffers at a time

cryptoapi-update-padlock-to-process-multiple-blocks-at.patch
  CryptoAPI: Update PadLock to process multiple blocks at  once

update-email-address-of-andrea-arcangeli.patch
  update email address of Andrea Arcangeli

compile-error-blackbird_load_firmware.patch
  blackbird_load_firmware compile fix

i386-x86_64-apicc-make-two-functions-static.patch
  i386/x86_64 apic.c: make two functions static

i386-cyrixc-make-a-function-static.patch
  i386 cyrix.c: make a function static

mtrr-some-cleanups.patch
  mtrr: some cleanups

i386-cpu-commonc-some-cleanups.patch
  i386 cpu/common.c: some cleanups

i386-cpuidc-make-two-functions-static.patch
  i386 cpuid.c: make two functions static

i386-efic-make-some-code-static.patch
  i386 efi.c: make some code static

i386-x86_64-io_apicc-misc-cleanups.patch
  i386/x86_64 io_apic.c: misc cleanups

i386-mpparsec-make-mp_processor_info-static.patch
  i386 mpparse.c: make MP_processor_info static

i386-x86_64-msrc-make-two-functions-static.patch
  i386/x86_64 msr.c: make two functions static

3w-abcdh-tw_device_extension-remove-an-unused-filed.patch
  3w-abcd.h: TW_Device_Extension: remove an unused field

hpet-make-some-code-static.patch
  hpet: make some code static

26-patch-i386-trapsc-make-a-function-static.patch
  i386 traps.c: make a function static

i386-semaphorec-make-4-functions-static.patch
  i386 semaphore.c: make 4 functions static

i386-rebootc-cleanups.patch
  i386: reboot.c cleanups

kill-aux_device_present.patch
  kill aux_device_present

i386-setupc-make-4-variables-static.patch
  i386 setup.c: make 4 variables static

mostly-i386-mm-cleanup.patch
  (mostly i386) mm cleanup

scsi-megaraid_mmc-make-some-code-static.patch
  SCSI megaraid_mm.c: make some code static

update-email-address-of-benjamin-lahaise.patch
  Update email address of Benjamin LaHaise

add-map_populate-sys_remap_file_pages-support-to-xfs.patch
  add MAP_POPULATE/sys_remap_file_pages support to XFS

update-email-address-of-philip-blundell.patch
  Update email address of Philip Blundell

mm-filemapc-make-a-function-static.patch
  mm/filemap.c: make a function static

kernel-acctc-make-a-function-static.patch
  kernel/acct.c: make a function static

kernel-auditc-make-some-functions-static.patch
  kernel/audit.c: make some functions static

kernel-capabilityc-make-a-spinlock-static.patch
  kernel/capability.c: make a spinlock static

mm-thrashc-make-a-variable-static.patch
  mm/thrash.c: make a variable static

lib-kernel_lockc-make-kernel_sem-static.patch
  lib/kernel_lock.c: make kernel_sem static

saa7146_vv_ksymsc-remove-two-unused-export_symbol_gpls.patch
  saa7146_vv_ksyms.c: remove two unused EXPORT_SYMBOL_GPL's

fix-placement-of-static-inline-in-nfsdh.patch
  fix placement of static inline in nfsd.h

drivers-block-umemc-make-two-functions-static.patch
  drivers/block/umem.c: make two functions static

drivers-block-xdc-make-a-variable-static.patch
  drivers/block/xd.c: make a variable static

kernel-configsc-make-a-variable-static.patch
  kernel/configs.c: make a variable static

kernel-forkc-make-mm_cachep-static.patch
  kernel/fork.c: make mm_cachep static

kernel-kallsymsc-make-some-code-static.patch
  kernel/kallsyms.c: make some code static

mm-page-writebackc-remove-an-unused-function.patch
  mm/page-writeback.c: remove an unused function

mm-shmemc-make-a-struct-static.patch
  mm/shmem.c: make a struct static

misc-isapnp-cleanups.patch
  misc ISAPNP cleanups

some-pnp-cleanups.patch
  some PNP cleanups

if-0-cx88_risc_disasm.patch
  #if 0 cx88_risc_disasm

make-loglevels-in-init-mainc-a-little-more-sane.patch
  Make loglevels in init/main.c a little more sane.

isicom-use-null-for-pointer.patch
  sparse: use NULL for pointer

remove-bouncing-email-address-of-hennus-bergman.patch
  remove bouncing email address of Hennus Bergman

cirrusfbc-make-some-code-static.patch
  cirrusfb.c: make some code static

matroxfb_basec-make-some-code-static.patch
  matroxfb_base.c: make some code static

asiliantfbc-make-some-code-static.patch
  asiliantfb.c: make some code static

i386-apic-kconfig-cleanups.patch
  i386 APIC Kconfig cleanups

security-seclvlc-make-some-code-static.patch
  security/seclvl.c: make some code static

drivers-block-elevatorc-make-two-functions-static.patch
  drivers/block/elevator.c: make two functions static

drivers-block-rdc-make-two-variables-static.patch
  drivers/block/rd.c: make two variables static

loopc-make-two-functions-static.patch
  loop.c: make two functions static

remove-bouncing-email-address-of-thomas-hood.patch
  remove bouncing email address of Thomas Hood

fs-adfs-dir_fc-remove-an-unused-function.patch
  fs/adfs/dir_f.c: remove an unused function

drivers-char-moxac-if-0-an-unused-function.patch
  drivers/char/moxa.c: #if 0 an unused function




^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
@ 2005-01-24 10:36     ` Adrian Bunk
  2005-01-24 11:17     ` 2.6.11-rc2-mm1: v4l-saa7134-module compile error Adrian Bunk
                       ` (21 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 10:36 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
>...

Before people start complaining it wouldn't apply:
  s/rc1/rc2/g

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* 2.6.11-rc2-mm1: v4l-saa7134-module compile error
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
  2005-01-24 10:36     ` 2.6.11-rc2-mm1 Adrian Bunk
@ 2005-01-24 11:17     ` Adrian Bunk
  2005-01-24 13:57       ` Gerd Knorr
  2005-01-24 11:56     ` 2.6.11-rc2-mm1 Brice Goglin
                       ` (20 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 11:17 UTC (permalink / raw)
  To: Andrew Morton, Gerd Knorr; +Cc: linux-kernel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
> +v4l-saa7134-module.patch
> 
>  v4l updates.
>...

This patch broke compilation with CONFIG_MODULES=n:

<--  snip  -->

...
  CC      drivers/media/video/saa7134/saa7134-core.o
drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:234: error: (Each undeclared identifier is reported only once
drivers/media/video/saa7134/saa7134-core.c:234: error: for each function it appears in.)
drivers/media/video/saa7134/saa7134-core.c: In function `request_module_depend':
drivers/media/video/saa7134/saa7134-core.c:251: error: dereferencing pointer to incomplete type
drivers/media/video/saa7134/saa7134-core.c:252: error: `MODULE_STATE_COMING' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:259: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1

<--  snip  -->

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
  2005-01-24 10:36     ` 2.6.11-rc2-mm1 Adrian Bunk
  2005-01-24 11:17     ` 2.6.11-rc2-mm1: v4l-saa7134-module compile error Adrian Bunk
@ 2005-01-24 11:56     ` Brice Goglin
  2005-01-24 13:41       ` 2.6.11-rc2-mm1 Brice Goglin
  2005-01-24 18:52       ` 2.6.11-rc2-mm1 Dave Jones
  2005-01-24 12:12     ` 2.6.11-rc2-mm1 Christoph Hellwig
                       ` (19 subsequent siblings)
  22 siblings, 2 replies; 152+ messages in thread
From: Brice Goglin @ 2005-01-24 11:56 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.

Hi Andrew,

X does not work anymore when using DRI on my Compaq Evo N600c (Radeon Mobility M6 LY).
My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel modules.

Instead of the usual gdm window, I get a black or noisy screen (remaining image parts of
last working session). The mouse pointer works. Sysrq works. But Caps-lock doesn't work.
The machine pings but I can't ssh.

I don't know exactly what's happening. I don't see anything interesting in dmesg.
Removing DRI from Xfree config (even if drm/radeon modules are loaded) makes X work again.
Linus' 2.6.11-rc2 works fine.

.config and lspci attached.

Regards,
Brice

[-- Attachment #2: config.gz --]
[-- Type: application/x-gunzip, Size: 8684 bytes --]

[-- Attachment #3: lspci.gz --]
[-- Type: application/x-gunzip, Size: 1834 bytes --]

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (2 preceding siblings ...)
  2005-01-24 11:56     ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-24 12:12     ` Christoph Hellwig
  2005-01-24 20:36       ` 2.6.11-rc2-mm1 Karsten Keil
  2005-01-24 21:03       ` 2.6.11-rc2-mm1 Andrew Morton
  2005-01-24 12:17     ` 2.6.11-rc2-mm1 Christoph Hellwig
                       ` (18 subsequent siblings)
  22 siblings, 2 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 12:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

> +i4l-new-hfc_usb-driver-version.patch

this drivers wants:

 - update for Documentation/CodingStyle
 - conversion to proper pci API

> +posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch

umm, this adds extreme obsfucation.  Roland, please try to follow normal
Linux style, thanks.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (3 preceding siblings ...)
  2005-01-24 12:12     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-24 12:17     ` Christoph Hellwig
  2005-01-31 22:42       ` [patch] generic notification layer Robert Love
  2005-02-07 11:57       ` 2.6.11-rc2-mm1 Ingo Molnar
  2005-01-24 12:25     ` [-mm patch] fix SuperIO compilation Adrian Bunk
                       ` (17 subsequent siblings)
  22 siblings, 2 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 12:17 UTC (permalink / raw)
  To: Andrew Morton, rml; +Cc: linux-kernel

> inotify.patch
>   inotify

Haven't had time to look at the current implementation, but the in-kernel
interface is still horrible as it duplicates the dnotify calls all over the
place, using IN_FOO instead of DN_FOO.  Please add a layer of notify_foo
wrappers that calls into both.

Also ioctl is not an acceptable interface for adding new core functionality.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [-mm patch] fix SuperIO compilation
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (4 preceding siblings ...)
  2005-01-24 12:17     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-24 12:25     ` Adrian Bunk
  2005-01-24 12:34       ` Christoph Hellwig
  2005-01-24 12:48     ` 2.6.11-rc2-mm1: DVB compile error Adrian Bunk
                       ` (16 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 12:25 UTC (permalink / raw)
  To: Andrew Morton, Greg Kroah-Hartman, Evgeniy Polyakov; +Cc: linux-kernel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
>  bk-i2c.patch
>...
>  Latest versions of various bk trees
>...

This causes the following compile error:

<--  snip  -->

...
  LD      drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of `sc_write_reg'
drivers/superio/sc_gpio.o(.text+0x0): first defined here
drivers/superio/sc_acb.o(.text+0x30): In function `sc_read_reg':
: multiple definition of `sc_read_reg'
drivers/superio/sc_gpio.o(.text+0x30): first defined here
make[2]: *** [drivers/superio/built-in.o] Error 1

<--  snip  -->

The trivial fix for these needlessly global functions is below.

BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
      Is usage for them expected very soon or shall I send a patch to 
      remove them?


<--  snip  -->


This patch makes needlessly global functions static fixing a compile 
error if both sc_acb.c and sc_gpio.c are compiled statically into the 
kernel.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/superio/sc_acb.c  |    4 ++--
 drivers/superio/sc_gpio.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.11-rc2-mm1-full/drivers/superio/sc_acb.c.old	2005-01-24 12:28:22.000000000 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/superio/sc_acb.c	2005-01-24 12:29:23.000000000 +0100
@@ -48,13 +48,13 @@
 	.orig_ldev = NULL,
 };
 
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
 {
 	outb(reg, dev->base_index);
 	outb(val, dev->base_data);
 }
 
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
 {
 	u8 val;
 
--- linux-2.6.11-rc2-mm1-full/drivers/superio/sc_gpio.c.old	2005-01-24 12:29:48.000000000 +0100
+++ linux-2.6.11-rc2-mm1-full/drivers/superio/sc_gpio.c	2005-01-24 12:29:58.000000000 +0100
@@ -50,13 +50,13 @@
 
 static void sc_gpio_write_event(void *data, int pin_number, u8 byte);
 
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
 {
 	outb(reg, dev->base_index);
 	outb(val, dev->base_data);
 }
 
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
 {
 	u8 val;
 


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [-mm patch] fix SuperIO compilation
  2005-01-24 12:25     ` [-mm patch] fix SuperIO compilation Adrian Bunk
@ 2005-01-24 12:34       ` Christoph Hellwig
  2005-01-24 13:04         ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 12:34 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Andrew Morton, Greg Kroah-Hartman, Evgeniy Polyakov, linux-kernel

On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.11-rc1-mm2:
> >...
> >  bk-i2c.patch
> >...
> >  Latest versions of various bk trees
> >...
> 
> This causes the following compile error:

Where's that code coming from anyone?  Greg seems to be adding tons of not fully
reviewed stuff lately..


^ permalink raw reply	[flat|nested] 152+ messages in thread

* 2.6.11-rc2-mm1: DVB compile error
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (5 preceding siblings ...)
  2005-01-24 12:25     ` [-mm patch] fix SuperIO compilation Adrian Bunk
@ 2005-01-24 12:48     ` Adrian Bunk
  2005-01-24 23:56       ` [linux-dvb-maintainer] " Johannes Stezenbach
  2005-01-24 13:52     ` 2.6.11-rc2-mm1 Roman Zippel
                       ` (15 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 12:48 UTC (permalink / raw)
  To: Andrew Morton, patrick.boettcher, linux-dvb-maintainer; +Cc: linux-kernel

The following compile error comes from Linus' tree:

<--  snip  -->

...
  LD      .tmp_vmlinux1
drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug'
arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
make: *** [.tmp_vmlinux1] Error 1

<--  snip  -->


The offender is in drivers/media/dvb/dibusb/dvb-dibusb-core.c:

"debug" is not a good name for a global variable...


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [-mm patch] fix SuperIO compilation
  2005-01-24 12:34       ` Christoph Hellwig
@ 2005-01-24 13:04         ` Evgeniy Polyakov
  2005-01-24 13:56           ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 13:04 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

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

On Mon, 2005-01-24 at 12:34 +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.11-rc1-mm2:
> > >...
> > >  bk-i2c.patch
> > >...
> > >  Latest versions of various bk trees
> > >...
> > 
> > This causes the following compile error:
> 
> Where's that code coming from anyone?  Greg seems to be adding tons of not fully
> reviewed stuff lately..

That code was written by me.
Please provide full error output, since it is compiled successfully
here.

Thank you.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 11:56     ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-24 13:41       ` Brice Goglin
  2005-01-24 14:35         ` 2.6.11-rc2-mm1 Florian Bohrer
  2005-01-24 18:52       ` 2.6.11-rc2-mm1 Dave Jones
  1 sibling, 1 reply; 152+ messages in thread
From: Brice Goglin @ 2005-01-24 13:41 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Benoit Boissinot, linux-kernel

Brice Goglin a écrit :
> Andrew Morton a écrit :
> 
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/ 
>>
>>
>>
>> - Lots of updates and fixes all over the place.
> 
> 
> Hi Andrew,
> 
> X does not work anymore when using DRI on my Compaq Evo N600c (Radeon 
> Mobility M6 LY).
> My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel 
> modules.
> 
> Instead of the usual gdm window, I get a black or noisy screen 
> (remaining image parts of
> last working session). The mouse pointer works. Sysrq works. But 
> Caps-lock doesn't work.
> The machine pings but I can't ssh.
> 
> I don't know exactly what's happening. I don't see anything interesting 
> in dmesg.

Thanks to Benoit who found this at the end of dmesg:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Couldn't find an AGP VGA controller.

while Linus' 2.6.11-rc2 says:
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode

Regards,
Brice

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (6 preceding siblings ...)
  2005-01-24 12:48     ` 2.6.11-rc2-mm1: DVB compile error Adrian Bunk
@ 2005-01-24 13:52     ` Roman Zippel
  2005-01-24 14:24     ` 2.6.11-rc2-mm1 Christoph Hellwig
                       ` (14 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Roman Zippel @ 2005-01-24 13:52 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Hi,

On Mon, 24 Jan 2005, Andrew Morton wrote:

> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

I introduced a stupid typo. The patch below should fix.
After completing rechecking and testing the patch I'll send you a rediffed 
version.

bye, Roman

diff -ur -X /home/devel/roman/nodiff linux-2.6.11-rc2-mm1.org/drivers/char/vt.c linux-2.6.11-rc2-mm1/drivers/char/vt.c
--- linux-2.6.11-rc2-mm1.org/drivers/char/vt.c	2005-01-24 14:16:18.000000000 +0100
+++ linux-2.6.11-rc2-mm1/drivers/char/vt.c	2005-01-24 14:18:25.000000000 +0100
@@ -212,6 +212,8 @@
  *	Low-Level Functions
  */
 
+#define IS_FG(vc)	((vc)->vc_num == fg_console)
+
 #ifdef VT_BUF_VRAM_ONLY
 #define DO_UPDATE(vc)	0
 #else
@@ -544,7 +546,7 @@
 
 static void set_cursor(struct vc_data *vc)
 {
-	if (!vc->vc_num != fg_console || console_blanked ||
+	if (!IS_FG(vc) || console_blanked ||
 	    vc->vc_mode == KD_GRAPHICS)
 		return;
 	if (vc->vc_deccm) {
@@ -1953,7 +1955,7 @@
 	charmask = himask ? 0x1ff : 0xff;
 
 	/* undraw cursor first */
-	if (currcons == fg_console)
+	if (IS_FG(vc))
 		hide_cursor(vc);
 
 	while (!tty->stopped && count) {
@@ -2166,7 +2168,7 @@
 		goto quit;
 
 	/* undraw cursor first */
-	if (vc->vc_num == fg_console)
+	if (IS_FG(vc))
 		hide_cursor(vc);
 
 	start = (ushort *)vc->vc_pos;

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [-mm patch] fix SuperIO compilation
  2005-01-24 13:04         ` Evgeniy Polyakov
@ 2005-01-24 13:56           ` Evgeniy Polyakov
  2005-01-24 14:14             ` [1/1] superio: remove unneded exports and make some functions static Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 13:56 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

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

On Mon, 2005-01-24 at 16:04 +0300, Evgeniy Polyakov wrote:
> On Mon, 2005-01-24 at 12:34 +0000, Christoph Hellwig wrote:
> > On Mon, Jan 24, 2005 at 01:25:41PM +0100, Adrian Bunk wrote:
> > > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.11-rc1-mm2:
> > > >...
> > > >  bk-i2c.patch
> > > >...
> > > >  Latest versions of various bk trees
> > > >...
> > > 
> > > This causes the following compile error:
> > 
> > Where's that code coming from anyone?  Greg seems to be adding tons of not fully
> > reviewed stuff lately..
> 
> That code was written by me.
> Please provide full error output, since it is compiled successfully
> here.
> 
> Thank you.

Ok, I found following in the archive:
******************************************
On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-rc1-mm2:
>...
>  bk-i2c.patch
>...
>  Latest versions of various bk trees
>...

This causes the following compile error:

<--  snip  -->

...
  LD      drivers/superio/built-in.o
drivers/superio/sc_acb.o(.text+0x0): In function `sc_write_reg':
: multiple definition of `sc_write_reg'
drivers/superio/sc_gpio.o(.text+0x0): first defined here
drivers/superio/sc_acb.o(.text+0x30): In function `sc_read_reg':
: multiple definition of `sc_read_reg'
drivers/superio/sc_gpio.o(.text+0x30): first defined here
make[2]: *** [drivers/superio/built-in.o] Error 1

<--  snip  -->

The trivial fix for these needlessly global functions is below.

BTW1: pin_test.c is added but completely unused.
BTW2: bk-i2c adds a whole bunch of unused SuperIO EXPORT_SYMBOL's.
      Is usage for them expected very soon or shall I send a patch to 
      remove them?


<--  snip  -->


This patch makes needlessly global functions static fixing a compile 
error if both sc_acb.c and sc_gpio.c are compiled statically into the 
kernel.

*********************************

It is not Greg, but completely my fault and I agree with your changes.
pin_test.c was added as example of how to use SuperIO subsystem, 
it is not supposed to be compiled, it is an example, probably it should 
live in Documentation/superio/example.c

Tahnk you for review.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
  2005-01-24 11:17     ` 2.6.11-rc2-mm1: v4l-saa7134-module compile error Adrian Bunk
@ 2005-01-24 13:57       ` Gerd Knorr
  2005-01-24 17:45         ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Gerd Knorr @ 2005-01-24 13:57 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 12:17:13PM +0100, Adrian Bunk wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> >...
> > +v4l-saa7134-module.patch
> 
> This patch broke compilation with CONFIG_MODULES=n:
> 
> drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
> drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)

The patch below should fix this.

  Gerd

Index: linux-2.6.11-rc2/drivers/media/video/saa7134/saa7134-core.c
===================================================================
--- linux-2.6.11-rc2.orig/drivers/media/video/saa7134/saa7134-core.c	2005-01-24 11:05:45.000000000 +0100
+++ linux-2.6.11-rc2/drivers/media/video/saa7134/saa7134-core.c	2005-01-24 14:54:29.000000000 +0100
@@ -21,6 +21,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include <linux/config.h>
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71
 /* ----------------------------------------------------------- */
 /* delayed request_module                                      */
 
+#ifdef CONFIG_MODULES
+
 static int need_empress;
 static int need_dvb;
 
@@ -265,6 +268,12 @@ static void request_module_depend(char *
 	}
 }
 
+#else
+
+static inline void request_module_depend(char *name, int *flag) {}
+
+#endif /* CONFIG_MODULES */
+
 /* ------------------------------------------------------------------ */
 
 /* nr of (saa7134-)pages for the given buffer size */

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [1/1] superio: remove unneded exports and make some functions static.
  2005-01-24 13:56           ` Evgeniy Polyakov
@ 2005-01-24 14:14             ` Evgeniy Polyakov
  2005-01-25  6:19               ` Greg KH
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 14:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Greg Kroah-Hartman, linux-kernel

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

Remove unneded exports and make some functions static.

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>

diff -ru linux-2.6/drivers/superio.orig/sc_acb.c
linux-2.6/drivers/superio/sc_acb.c
--- linux-2.6/drivers/superio.orig/sc_acb.c	2005-01-24
17:07:28.295779728 +0300
+++ linux-2.6/drivers/superio/sc_acb.c	2005-01-24 17:09:35.377460376
+0300
@@ -29,10 +29,10 @@
 #include "sc.h"
 #include "sc_acb.h"
 
-int sc_acb_activate(void *data);
-u8 sc_acb_read(void *data, int reg);
-void sc_acb_write(void *data, int reg, u8 byte);
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl);
+static int sc_acb_activate(void *data);
+static u8 sc_acb_read(void *data, int reg);
+static void sc_acb_write(void *data, int reg, u8 byte);
+static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl);
 
 static struct logical_dev ldev_acb = {
 	.name = "ACB",
@@ -48,13 +48,13 @@
 	.orig_ldev = NULL,
 };
 
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
 {
 	outb(reg, dev->base_index);
 	outb(val, dev->base_data);
 }
 
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
 {
 	u8 val;
 
@@ -64,7 +64,7 @@
 	return val;
 }
 
-int sc_acb_activate(void *data)
+static int sc_acb_activate(void *data)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	u8 val;
@@ -111,7 +111,7 @@
 	return 0;
 }
 
-u8 sc_acb_read(void *data, int reg)
+static u8 sc_acb_read(void *data, int reg)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	u8 val;
@@ -123,7 +123,7 @@
 	return val;
 }
 
-void sc_acb_write(void *data, int reg, u8 byte)
+static void sc_acb_write(void *data, int reg, u8 byte)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 
@@ -132,7 +132,7 @@
 	outb(byte, ldev->base_addr + reg);
 }
 
-void sc_acb_control(void *data, int pin, u8 mask, u8 ctl)
+static void sc_acb_control(void *data, int pin, u8 mask, u8 ctl)
 {
 }
 
@@ -156,8 +156,3 @@
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
 MODULE_DESCRIPTION("Driver for Access Bus logical device.");
-
-EXPORT_SYMBOL(sc_acb_activate);
-EXPORT_SYMBOL(sc_acb_read);
-EXPORT_SYMBOL(sc_acb_write);
-EXPORT_SYMBOL(sc_acb_control);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.c
linux-2.6/drivers/superio/sc_gpio.c
--- linux-2.6/drivers/superio.orig/sc_gpio.c	2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.c	2005-01-24 17:10:44.808905192
+0300
@@ -31,6 +31,14 @@
 
 static struct gpio_pin gpin[SIO_GPIO_NPINS];
 
+static int sc_gpio_activate(void *);
+static u8 sc_gpio_read(void *, int);
+static void sc_gpio_write(void *, int, u8);
+static void sc_gpio_control(void *, int, u8, u8);
+static void sc_gpio_pin_select(void *, int);
+static irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *);
+
+
 static struct logical_dev ldev_gpio = {
 	.name = "GPIO",
 	.index = SIO_LDN_GPIO,
@@ -50,13 +58,13 @@
 
 static void sc_gpio_write_event(void *data, int pin_number, u8 byte);
 
-void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
+static void sc_write_reg(struct sc_dev *dev, u8 reg, u8 val)
 {
 	outb(reg, dev->base_index);
 	outb(val, dev->base_data);
 }
 
-u8 sc_read_reg(struct sc_dev *dev, u8 reg)
+static u8 sc_read_reg(struct sc_dev *dev, u8 reg)
 {
 	u8 val;
 
@@ -66,7 +74,7 @@
 	return val;
 }
 
-irqreturn_t sc_gpio_interrupt(int irq, void *data, struct pt_regs *
regs)
+static irqreturn_t sc_gpio_interrupt(int irq, void *data, struct
pt_regs * regs)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	static u8 r[4], e[2], s[2];
@@ -122,7 +130,7 @@
 }
 
 
-void sc_gpio_pin_select(void *data, int pin_number)
+static void sc_gpio_pin_select(void *data, int pin_number)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	int port, pin;
@@ -136,7 +144,7 @@
 	sc_write_reg(ldev->pdev, SIO_GPIO_PINSEL, val);
 }
 
-int sc_gpio_activate(void *data)
+static int sc_gpio_activate(void *data)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	int i;
@@ -161,7 +169,7 @@
 	return 0;
 }
 
-u8 sc_gpio_read(void *data, int pin_number)
+static u8 sc_gpio_read(void *data, int pin_number)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	int port, pin;
@@ -222,7 +230,7 @@
 	outb(1<<pin, ldev->base_addr + reg+1);
 }
 
-void sc_gpio_write(void *data, int pin_number, u8 byte)
+static void sc_gpio_write(void *data, int pin_number, u8 byte)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	int port, pin;
@@ -263,7 +271,7 @@
 	outb(val, ldev->base_addr + reg);
 }
 
-void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl)
+static void sc_gpio_control(void *data, int pin, u8 mask, u8 ctl)
 {
 	struct logical_dev *ldev = (struct logical_dev *)data;
 	u8 cfg, ev;
@@ -302,9 +310,3 @@
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Evgeniy Polyakov <johnpol@2ka.mipt.ru>");
 MODULE_DESCRIPTION("Driver for GPIO logical device.");
-
-EXPORT_SYMBOL(sc_gpio_activate);
-EXPORT_SYMBOL(sc_gpio_read);
-EXPORT_SYMBOL(sc_gpio_write);
-EXPORT_SYMBOL(sc_gpio_control);
-EXPORT_SYMBOL(sc_gpio_pin_select);
diff -ru linux-2.6/drivers/superio.orig/sc_gpio.h
linux-2.6/drivers/superio/sc_gpio.h
--- linux-2.6/drivers/superio.orig/sc_gpio.h	2005-01-24
17:07:28.305778208 +0300
+++ linux-2.6/drivers/superio/sc_gpio.h	2005-01-24 17:10:26.750650464
+0300
@@ -40,13 +40,6 @@
 #define SIO_GPIO_CONF_EVENT_POLAR_RIS	(1 << 5)
 #define SIO_GPIO_CONF_DEBOUNCE		(1 << 6)
 
-int sc_gpio_activate(void *);
-u8 sc_gpio_read(void *, int);
-void sc_gpio_write(void *, int, u8);
-void sc_gpio_control(void *, int, u8, u8);
-void sc_gpio_pin_select(void *, int);
-irqreturn_t sc_gpio_interrupt(int, void *, struct pt_regs *);
-
 struct gpio_pin
 {
 	u8			state;


-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (7 preceding siblings ...)
  2005-01-24 13:52     ` 2.6.11-rc2-mm1 Roman Zippel
@ 2005-01-24 14:24     ` Christoph Hellwig
  2005-01-24 14:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
                       ` (13 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 14:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

>  bk-i2c.patch

This contains two new subsystems, both aren't exactly the nicest code
on earth and one isn't even explained what it is.  And both aren't
really i2c-related.

Greg, any chance you could stop funneling new tasteless code in through
the backdoor?


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 13:41       ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-24 14:35         ` Florian Bohrer
  0 siblings, 0 replies; 152+ messages in thread
From: Florian Bohrer @ 2005-01-24 14:35 UTC (permalink / raw)
  To: linux-kernel

On Mon, 24 Jan 2005 14:41:49 +0100
Brice Goglin <Brice.Goglin@ens-lyon.fr> wrote:

> Brice Goglin a écrit :
> > Andrew Morton a écrit :
> > 
> >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/ 
> >>
> >>
> >>
> >> - Lots of updates and fixes all over the place.
> > 
> > 
> > Hi Andrew,
> > 
> > X does not work anymore when using DRI on my Compaq Evo N600c (Radeon 
> > Mobility M6 LY).
> > My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel 
> > modules.
> > 
> > Instead of the usual gdm window, I get a black or noisy screen 
> > (remaining image parts of
> > last working session). The mouse pointer works. Sysrq works. But 
> > Caps-lock doesn't work.
> > The machine pings but I can't ssh.
> > 
> > I don't know exactly what's happening. I don't see anything interesting 
> > in dmesg.
> 
> Thanks to Benoit who found this at the end of dmesg:
> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Couldn't find an AGP VGA controller.
> 
> while Linus' 2.6.11-rc2 says:
> agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode
> 
> Regards,
> Brice
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

the same problem here.... with the nvidia-driver .....seems that AGP is totally brocken.

Jan 24 13:50:09 hal9000 agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
Jan 24 13:50:09 hal9000 agpgart: Couldn't find an AGP VGA controller.
-- 


-----------------------------------------------------------------------------
"Real Programmers consider "what you see is what you get" to 
be just as bad a concept in Text Editors as it is in women. 
No, the Real Programmer wants a "you asked for it, you got 
it" text editor -- complicated, cryptic, powerful, 
unforgiving, dangerous."
-----------------------------------------------------------------------------


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (8 preceding siblings ...)
  2005-01-24 14:24     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-24 14:58     ` Benoit Boissinot
  2005-01-24 15:11     ` 2.6.11-rc2-mm1 [compile fix] Benoit Boissinot
                       ` (12 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Benoit Boissinot @ 2005-01-24 14:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, netdev

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> 
> 
> 
> Changes since 2.6.11-rc1-mm2:
> 
> 
>  bk-netdev.patch

Without the following patch, it doesn't compile with ip_conntrack and
without ip_nat.

In file included from net/ipv4/netfilter/ip_conntrack_standalone.c:34:
include/linux/netfilter_ipv4/ip_conntrack.h:306: error: parameter `manip' has incomplete type
include/linux/netfilter_ipv4/ip_conntrack.h: In function `ip_nat_initialized':
include/linux/netfilter_ipv4/ip_conntrack.h:307: error: `IP_NAT_MANIP_SRC' undeclared (first use in this function)

regards,

Benoit

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>


--- linux-clean/include/linux/netfilter_ipv4/ip_conntrack.h	2005-01-24 12:44:29.000000000 +0100
+++ linux/include/linux/netfilter_ipv4/ip_conntrack.h	2005-01-24 13:05:44.000000000 +0100
@@ -301,6 +301,7 @@ struct ip_conntrack_stat
 
 #define CONNTRACK_STAT_INC(count) (__get_cpu_var(ip_conntrack_stat).count++)
 
+#ifdef CONFIG_IP_NF_NAT_NEEDED
 static inline int ip_nat_initialized(struct ip_conntrack *conntrack,
 				     enum ip_nat_manip_type manip)
 {
@@ -308,5 +309,6 @@ static inline int ip_nat_initialized(str
 		return test_bit(IPS_SRC_NAT_DONE_BIT, &conntrack->status);
 	return test_bit(IPS_DST_NAT_DONE_BIT, &conntrack->status);
 }
+#endif /* CONFIG_IP_NF_NAT_NEEDED */
 #endif /* __KERNEL__ */
 #endif /* _IP_CONNTRACK_H */


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1 [compile fix]
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (9 preceding siblings ...)
  2005-01-24 14:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
@ 2005-01-24 15:11     ` Benoit Boissinot
  2005-01-24 17:25       ` Adrian Bunk
  2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
                       ` (11 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Benoit Boissinot @ 2005-01-24 15:11 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Adrian Bunk

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> 
> Changes since 2.6.11-rc1-mm2:
> 
> [snip]
> 
> +kernel-forkc-make-mm_cachep-static.patch
> 
>  Little fixes.
> 
>
It breaks compilation with gcc-4.0

kernel/fork.c:1249: error: static declaration of ‘mm_cachep’ follows non-static declaration
include/linux/slab.h:117: error: previous declaration of ‘mm_cachep’ was here
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>


--- linux/include/linux/slab.h	2005-01-24 11:36:33.000000000 +0100
+++ linux/include/linux/slab.h.new	2005-01-24 12:24:46.000000000 +0100
@@ -114,7 +114,6 @@ extern int FASTCALL(kmem_ptr_validate(km
 
 /* System wide caches */
 extern kmem_cache_t	*vm_area_cachep;
-extern kmem_cache_t	*mm_cachep;
 extern kmem_cache_t	*names_cachep;
 extern kmem_cache_t	*files_cachep;
 extern kmem_cache_t	*filp_cachep;
--- linux-clean/kernel/fork.c	2005-01-24 12:44:48.000000000 +0100
+++ linux/kernel/fork.c	2005-01-24 12:38:27.000000000 +0100
@@ -81,6 +81,24 @@ int nr_processes(void)
 static kmem_cache_t *task_struct_cachep;
 #endif
 
+/* SLAB cache for signal_struct structures (tsk->signal) */
+kmem_cache_t *signal_cachep;
+
+/* SLAB cache for sighand_struct structures (tsk->sighand) */
+kmem_cache_t *sighand_cachep;
+
+/* SLAB cache for files_struct structures (tsk->files) */
+kmem_cache_t *files_cachep;
+
+/* SLAB cache for fs_struct structures (tsk->fs) */
+kmem_cache_t *fs_cachep;
+
+/* SLAB cache for vm_area_struct structures */
+kmem_cache_t *vm_area_cachep;
+
+/* SLAB cache for mm_struct structures (tsk->mm) */
+static kmem_cache_t *mm_cachep;
+
 void free_task(struct task_struct *tsk)
 {
 	free_thread_info(tsk->thread_info);
@@ -1230,24 +1248,6 @@ long do_fork(unsigned long clone_flags,
 	return pid;
 }
 
-/* SLAB cache for signal_struct structures (tsk->signal) */
-kmem_cache_t *signal_cachep;
-
-/* SLAB cache for sighand_struct structures (tsk->sighand) */
-kmem_cache_t *sighand_cachep;
-
-/* SLAB cache for files_struct structures (tsk->files) */
-kmem_cache_t *files_cachep;
-
-/* SLAB cache for fs_struct structures (tsk->fs) */
-kmem_cache_t *fs_cachep;
-
-/* SLAB cache for vm_area_struct structures */
-kmem_cache_t *vm_area_cachep;
-
-/* SLAB cache for mm_struct structures (tsk->mm) */
-static kmem_cache_t *mm_cachep;
-
 void __init proc_caches_init(void)
 {
 	sighand_cachep = kmem_cache_create("sighand_cache",


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1 [compile fix]
  2005-01-24 15:11     ` 2.6.11-rc2-mm1 [compile fix] Benoit Boissinot
@ 2005-01-24 17:25       ` Adrian Bunk
  0 siblings, 0 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 17:25 UTC (permalink / raw)
  To: Benoit Boissinot; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 04:11:13PM +0100, Benoit Boissinot wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> > 
> > 
> > - Lots of updates and fixes all over the place.
> > 
> > 
> > Changes since 2.6.11-rc1-mm2:
> > 
> > [snip]
> > 
> > +kernel-forkc-make-mm_cachep-static.patch
> > 
> >  Little fixes.
> > 
> >
> It breaks compilation with gcc-4.0
> 
> kernel/fork.c:1249: error: static declaration of ???mm_cachep??? follows non-static declaration
> include/linux/slab.h:117: error: previous declaration of ???mm_cachep??? was here
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
>...

Ups, yes, thanks. This was my fault.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
  2005-01-24 13:57       ` Gerd Knorr
@ 2005-01-24 17:45         ` Adrian Bunk
  2005-01-25 10:15           ` Gerd Knorr
  0 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 17:45 UTC (permalink / raw)
  To: Gerd Knorr; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 02:57:17PM +0100, Gerd Knorr wrote:
> On Mon, Jan 24, 2005 at 12:17:13PM +0100, Adrian Bunk wrote:
> > On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > >...
> > > +v4l-saa7134-module.patch
> > 
> > This patch broke compilation with CONFIG_MODULES=n:
> > 
> > drivers/media/video/saa7134/saa7134-core.c: In function `pending_call':
> > drivers/media/video/saa7134/saa7134-core.c:234: error: `MODULE_STATE_LIVE' undeclared (first use in this function)
> 
> The patch below should fix this.

Not completely:

<--  snip  -->

...
  CC      drivers/media/video/saa7134/saa7134-core.o
drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
drivers/media/video/saa7134/saa7134-core.c:997: error: (Each undeclared identifier is reported only once
drivers/media/video/saa7134/saa7134-core.c:997: error: for each function it appears in.)
drivers/media/video/saa7134/saa7134-core.c:1000: error: `need_dvb' undeclared (first use in this function)
make[4]: *** [drivers/media/video/saa7134/saa7134-core.o] Error 1

<--  snip  -->

>   Gerd
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (10 preceding siblings ...)
  2005-01-24 15:11     ` 2.6.11-rc2-mm1 [compile fix] Benoit Boissinot
@ 2005-01-24 17:54     ` Adrian Bunk
  2005-01-24 18:43       ` Evgeniy Polyakov
                         ` (2 more replies)
  2005-01-24 18:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
                       ` (10 subsequent siblings)
  22 siblings, 3 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 17:54 UTC (permalink / raw)
  To: Andrew Morton, Greg Kroah-Hartman, Evgeniy Polyakov; +Cc: linux-kernel

It seems noone who reviewed the SuperIO patches noticed that there are 
now two modules "scx200" in the kernel...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 18:43       ` Evgeniy Polyakov
@ 2005-01-24 18:29         ` Adrian Bunk
  2005-01-24 19:19           ` Evgeniy Polyakov
  2005-01-24 18:41         ` Jurriaan
  2005-01-27 15:19         ` Bill Davidsen
  2 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 18:29 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > It seems noone who reviewed the SuperIO patches noticed that there are 
> > now two modules "scx200" in the kernel...
> 
> They are almost mutually exlusive(SuperIO contains more advanced), 
> so I do not see any problem here.

The Kconfig files allow building both modular at the same time.

> Only one of them can be loaded in a time.

You are assuming the module support was in able to correctly handle two 
modules with the same name...

> So what does exactly bother you?

if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.11-rc2-mm1; fi
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 18:43       ` Evgeniy Polyakov
  2005-01-24 18:29         ` Adrian Bunk
@ 2005-01-24 18:41         ` Jurriaan
  2005-01-24 19:23           ` Evgeniy Polyakov
  2005-01-27 15:19         ` Bill Davidsen
  2 siblings, 1 reply; 152+ messages in thread
From: Jurriaan @ 2005-01-24 18:41 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > It seems noone who reviewed the SuperIO patches noticed that there are 
> > now two modules "scx200" in the kernel...
> 
> They are almost mutually exlusive(SuperIO contains more advanced), 
> so I do not see any problem here.
> Only one of them can be loaded in a time.
> 
> So what does exactly bother you?
> 
lsmod in bugreports giving unspecific results, for example.

Kind regards,
Jurriaan
-- 
"So you believe."
Jewel ATerafin shrugged. "I have more than belief, but I don't have a
pressing need to convince you of anything."
	Michelle West - Sea of Sorrows.
Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
@ 2005-01-24 18:43       ` Evgeniy Polyakov
  2005-01-24 18:29         ` Adrian Bunk
                           ` (2 more replies)
  2005-01-24 20:33       ` Christoph Hellwig
  2005-01-24 21:34       ` Greg KH
  2 siblings, 3 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 18:43 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 18:54:49 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> It seems noone who reviewed the SuperIO patches noticed that there are 
> now two modules "scx200" in the kernel...

They are almost mutually exlusive(SuperIO contains more advanced), 
so I do not see any problem here.
Only one of them can be loaded in a time.

So what does exactly bother you?

> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 11:56     ` 2.6.11-rc2-mm1 Brice Goglin
  2005-01-24 13:41       ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-24 18:52       ` Dave Jones
  2005-01-24 20:44         ` 2.6.11-rc2-mm1 Dave Jones
  1 sibling, 1 reply; 152+ messages in thread
From: Dave Jones @ 2005-01-24 18:52 UTC (permalink / raw)
  To: Brice.Goglin; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 12:56:58PM +0100, Brice Goglin wrote:
 > X does not work anymore when using DRI on my Compaq Evo N600c (Radeon 
 > Mobility M6 LY).
 > My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel 
 > modules.
 
My fault. I'm looking into it.
Drop the agpgart-bk update for now.

		Dave


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (11 preceding siblings ...)
  2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
@ 2005-01-24 18:58     ` Benoit Boissinot
  2005-01-24 19:09       ` 2.6.11-rc2-mm1 Adrian Bunk
  2005-01-24 19:44     ` 2.6.11-rc2-mm1 - fix a typo in nfs3proc.c Benoit Boissinot
                       ` (9 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Benoit Boissinot @ 2005-01-24 18:58 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Adrian Bunk

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> 
> 
> 
> Changes since 2.6.11-rc1-mm2:
>
> [snip]
> 
> +matroxfb_basec-make-some-code-static.patch
> 
>  Little fixes.
> 
It breaks compilation with gcc-4.0

The patch below correct it.

regards,

Benoit

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>

--- linux-clean/drivers/video/matrox/matroxfb_base.h	2005-01-24 12:44:43.000000000 +0100
+++ linux-test/drivers/video/matrox/matroxfb_base.h	2005-01-24 19:49:29.000000000 +0100
@@ -764,7 +764,6 @@ void matroxfb_unregister_driver(struct m
 #define matroxfb_DAC_unlock_irqrestore(flags) spin_unlock_irqrestore(&ACCESS_FBINFO(lock.DAC),flags)
 extern void matroxfb_DAC_out(CPMINFO int reg, int val);
 extern int matroxfb_DAC_in(CPMINFO int reg);
-extern struct list_head matroxfb_list;
 extern void matroxfb_var2my(struct fb_var_screeninfo* fvsi, struct my_timming* mt);
 extern int matroxfb_wait_for_sync(WPMINFO u_int32_t crtc);
 extern int matroxfb_enable_irq(WPMINFO int reenable);

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:19           ` Evgeniy Polyakov
@ 2005-01-24 19:03             ` Adrian Bunk
  2005-01-24 19:46               ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 19:03 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, Jan 24, 2005 at 10:19:29PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 19:29:26 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > 
> > > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > > now two modules "scx200" in the kernel...
> > > 
> > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > so I do not see any problem here.
> > 
> > The Kconfig files allow building both modular at the same time.
> > 
> > > Only one of them can be loaded in a time.
> > 
> > You are assuming the module support was in able to correctly handle two 
> > modules with the same name...
> > 
> > > So what does exactly bother you?
> > 
> > if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.11-rc2-mm1; fi
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
> 
> Sorry, I can not buy it.
> Above symbols are defined in old scx200 driver, and I it is depmod
> who tries to get them from superio.

More exactly, "make modules_install" does install only one of the two 
drivers.

> I definitely sure that it must be solved on the other layers.
>...

Two modules with the same name are simply a _very_ bad idea.

Even if they weren't allowed to be compiled at the same time, they 
should be named differently or it will cause much confusion for 
everyone (or don't you want to see from the output of "lsmod" which of 
the two modules is loaded?).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:23           ` Evgeniy Polyakov
@ 2005-01-24 19:05             ` Adrian Bunk
  2005-01-24 19:39               ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 19:05 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Jurriaan, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 19:41:11 +0100
> Jurriaan <thunder7@xs4all.nl> wrote:
> 
> > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > 
> > > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > > now two modules "scx200" in the kernel...
> > > 
> > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > so I do not see any problem here.
> > > Only one of them can be loaded in a time.
> > > 
> > > So what does exactly bother you?
> > > 
> > lsmod in bugreports giving unspecific results, for example.
> 
> If you load scx200 from superio subsystem, then obviously you can not
> use old i2c/acb modules which require old scx200.
> And vice versa.
> 
> One needs to load exactly what he wants.

You did not understand what Jurriaan said:

Even if it was working, "lsmod" would not be able to tell which of the 
two modules was loaded.

This would cause much headache for many people.

> > Kind regards,
> > Jurriaan
> 
> 	Evgeniy Polyakov

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 18:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
@ 2005-01-24 19:09       ` Adrian Bunk
  0 siblings, 0 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-24 19:09 UTC (permalink / raw)
  To: Benoit Boissinot; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 07:58:23PM +0100, Benoit Boissinot wrote:
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> > 
> > 
> > - Lots of updates and fixes all over the place.
> > 
> > - On my test box there is no flashing cursor on the vga console.  Known bug,
> >   please don't report it.
> > 
> >   Binary searching shows that the bug was introduced by
> >   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> > 
> > 
> > 
> > Changes since 2.6.11-rc1-mm2:
> >
> > [snip]
> > 
> > +matroxfb_basec-make-some-code-static.patch
> > 
> >  Little fixes.
> > 
> It breaks compilation with gcc-4.0
> 
> The patch below correct it.

This patch is correct, too.

I do grep for the symbols I'm making static, but it seems I have to 
sharpen my eyes...

> regards,
> 
> Benoit
>...

Sorry
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 18:29         ` Adrian Bunk
@ 2005-01-24 19:19           ` Evgeniy Polyakov
  2005-01-24 19:03             ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 19:19 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 19:29:26 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > now two modules "scx200" in the kernel...
> > 
> > They are almost mutually exlusive(SuperIO contains more advanced), 
> > so I do not see any problem here.
> 
> The Kconfig files allow building both modular at the same time.
> 
> > Only one of them can be loaded in a time.
> 
> You are assuming the module support was in able to correctly handle two 
> modules with the same name...
> 
> > So what does exactly bother you?
> 
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.11-rc2-mm1; fi
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow

Sorry, I can not buy it.
Above symbols are defined in old scx200 driver, and I it is depmod
who tries to get them from superio.

I definitely sure that it must be solved on the other layers.

But nevertheless, obviously it is much easier to change superio's scx200 name
and I will do it.
 
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 18:41         ` Jurriaan
@ 2005-01-24 19:23           ` Evgeniy Polyakov
  2005-01-24 19:05             ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 19:23 UTC (permalink / raw)
  To: Jurriaan; +Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 19:41:11 +0100
Jurriaan <thunder7@xs4all.nl> wrote:

> From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > now two modules "scx200" in the kernel...
> > 
> > They are almost mutually exlusive(SuperIO contains more advanced), 
> > so I do not see any problem here.
> > Only one of them can be loaded in a time.
> > 
> > So what does exactly bother you?
> > 
> lsmod in bugreports giving unspecific results, for example.

If you load scx200 from superio subsystem, then obviously you can not
use old i2c/acb modules which require old scx200.
And vice versa.

One needs to load exactly what he wants.

> Kind regards,
> Jurriaan
> -- 
> "So you believe."
> Jewel ATerafin shrugged. "I have more than belief, but I don't have a
> pressing need to convince you of anything."
> 	Michelle West - Sea of Sorrows.
> Debian (Unstable) GNU/Linux 2.6.10-mm1 2x6078 bogomips load 0.52


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:39               ` Evgeniy Polyakov
@ 2005-01-24 19:32                 ` Dmitry Torokhov
  2005-01-24 20:28                   ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-24 19:32 UTC (permalink / raw)
  To: johnpol
  Cc: Adrian Bunk, Jurriaan, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 22:39:25 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Mon, 24 Jan 2005 20:05:46 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> > On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 19:41:11 +0100
> > > Jurriaan <thunder7@xs4all.nl> wrote:
> > >
> > > > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> > > > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > >
> > > > > > It seems noone who reviewed the SuperIO patches noticed that there are
> > > > > > now two modules "scx200" in the kernel...
> > > > >
> > > > > They are almost mutually exlusive(SuperIO contains more advanced),
> > > > > so I do not see any problem here.
> > > > > Only one of them can be loaded in a time.
> > > > >
> > > > > So what does exactly bother you?
> > > > >
> > > > lsmod in bugreports giving unspecific results, for example.
> > >
> > > If you load scx200 from superio subsystem, then obviously you can not
> > > use old i2c/acb modules which require old scx200.
> > > And vice versa.
> > >
> > > One needs to load exactly what he wants.
> >
> > You did not understand what Jurriaan said:
> >
> > Even if it was working, "lsmod" would not be able to tell which of the
> > two modules was loaded.
> >
> > This would cause much headache for many people.
> 
> 
> Module is just a piece of code, or programm if someone may think.
> And there no problems when we type
> $ ps
> and see only "aterm", if someone wants to know what exactly means "aterm",
> one can run ps axufw.
> And even with the case of lsmod: one can see that scx200 will or will not
> depend on superio, and that will explain everything.
> 

There are so many problems and ambiguites with having non-unique
module names it is not even funny:
- when I modprobe scx200 what willI get?
- if I want to blacklist one of the modules (let's say hotplug) how do
I do that?
- lsmod (with everything else compiled in, possible?) - which one is loadded?

...etc, etc...

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:05             ` Adrian Bunk
@ 2005-01-24 19:39               ` Evgeniy Polyakov
  2005-01-24 19:32                 ` Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 19:39 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Jurriaan, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 20:05:46 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Jan 24, 2005 at 10:23:02PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 19:41:11 +0100
> > Jurriaan <thunder7@xs4all.nl> wrote:
> > 
> > > From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> > > Date: Mon, Jan 24, 2005 at 09:43:36PM +0300
> > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > 
> > > > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > > > now two modules "scx200" in the kernel...
> > > > 
> > > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > > so I do not see any problem here.
> > > > Only one of them can be loaded in a time.
> > > > 
> > > > So what does exactly bother you?
> > > > 
> > > lsmod in bugreports giving unspecific results, for example.
> > 
> > If you load scx200 from superio subsystem, then obviously you can not
> > use old i2c/acb modules which require old scx200.
> > And vice versa.
> > 
> > One needs to load exactly what he wants.
> 
> You did not understand what Jurriaan said:
> 
> Even if it was working, "lsmod" would not be able to tell which of the 
> two modules was loaded.
> 
> This would cause much headache for many people.


Module is just a piece of code, or programm if someone may think.
And there no problems when we type
$ ps
and see only "aterm", if someone wants to know what exactly means "aterm",
one can run ps axufw.
And even with the case of lsmod: one can see that scx200 will or will not
 depend on superio, and that will explain everything.
 
> > > Kind regards,
> > > Jurriaan
> > 
> > 	Evgeniy Polyakov
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1 - fix a typo in nfs3proc.c
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (12 preceding siblings ...)
  2005-01-24 18:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
@ 2005-01-24 19:44     ` Benoit Boissinot
  2005-01-24 20:24     ` 2.6.11-rc2-mm1 - compile fix Benoit Boissinot
                       ` (8 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Benoit Boissinot @ 2005-01-24 19:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Andreas Gruenbacher

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> 
> +nfsacl-infrastructure-and-server-side-of-nfsacl.patch
> 
>  ACLs for ther NFS client.
>

Patch below fix a typo.


--- linux-clean/fs/nfsd/nfs3proc.c	2005-01-24 12:44:44.000000000 +0100
+++ linux-test/fs/nfsd/nfs3proc.c	2005-01-24 18:22:18.000000000 +0100
@@ -813,7 +813,7 @@ struct svc_procedure		nfsd_acl_procedure
 struct svc_version	nfsd_acl_version3 = {
 		.vs_vers	= 3,
 		.vs_nproc	= 3,
-		.vs_proc	nfsd_acl_procedures3,
+		.vs_proc	= nfsd_acl_procedures3,
 		.vs_dispatch	= nfsd_dispatch,
 		.vs_xdrsize	= NFS3_SVC_XDRSIZE,
 };

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:03             ` Adrian Bunk
@ 2005-01-24 19:46               ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 19:46 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 20:03:20 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Jan 24, 2005 at 10:19:29PM +0300, Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 19:29:26 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > On Mon, Jan 24, 2005 at 09:43:36PM +0300, Evgeniy Polyakov wrote:
> > > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > > 
> > > > > It seems noone who reviewed the SuperIO patches noticed that there are 
> > > > > now two modules "scx200" in the kernel...
> > > > 
> > > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > > so I do not see any problem here.
> > > 
> > > The Kconfig files allow building both modular at the same time.
> > > 
> > > > Only one of them can be loaded in a time.
> > > 
> > > You are assuming the module support was in able to correctly handle two 
> > > modules with the same name...
> > > 
> > > > So what does exactly bother you?
> > > 
> > > if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.6.11-rc2-mm1; fi
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_base
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_configure
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/i2c/busses/scx200_i2c.ko needs unknown symbol scx200_gpio_shadow
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_base
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_configure
> > > WARNING: /lib/modules/2.6.11-rc2-mm1/kernel/drivers/char/scx200_gpio.ko needs unknown symbol scx200_gpio_shadow
> > 
> > Sorry, I can not buy it.
> > Above symbols are defined in old scx200 driver, and I it is depmod
> > who tries to get them from superio.
> 
> More exactly, "make modules_install" does install only one of the two 
> drivers.
> 
> > I definitely sure that it must be solved on the other layers.
> >...
> 
> Two modules with the same name are simply a _very_ bad idea.
> 
> Even if they weren't allowed to be compiled at the same time, they 
> should be named differently or it will cause much confusion for 
> everyone (or don't you want to see from the output of "lsmod" which of 
> the two modules is loaded?).

I do not agree with you, Adrian, but I will not contend.
As I say, noone protects against the same program names and there are
mechnisms to differ modules by simply looking in lsmod output.
Noone can damage systrem by loading "wrong" module.

So I still do not see problems here.

As I say I will change superio scx200 name since it is easier than
flood about unmatched points of view.

I will send patch through Greg and Andrew later.

Thank you, Adrian, for your comments.
 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1 - compile fix
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (13 preceding siblings ...)
  2005-01-24 19:44     ` 2.6.11-rc2-mm1 - fix a typo in nfs3proc.c Benoit Boissinot
@ 2005-01-24 20:24     ` Benoit Boissinot
  2005-01-24 20:26     ` [PATCH] move common compat ioctls to hash Michael S. Tsirkin
                       ` (7 subsequent siblings)
  22 siblings, 0 replies; 152+ messages in thread
From: Benoit Boissinot @ 2005-01-24 20:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, netfilter-devel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.
> 
> 

The patch below fixes the compilation of the tftp nat module

net/ipv4/netfilter/ip_nat_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_nat_tftp.c:44: multiple definition of `ip_nat_tftp_hook'
net/ipv4/netfilter/ip_conntrack_tftp.o(.bss+0x0):net/ipv4/netfilter/ip_conntrack_tftp.c:49: first defined here
make[3]: *** [net/ipv4/netfilter/built-in.o] Error 1
make[2]: *** [net/ipv4/netfilter] Error 2
make[1]: *** [net/ipv4] Error 2
make: *** [net] Error 2

Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org>


--- linux-clean/include/linux/netfilter_ipv4/ip_conntrack_tftp.h	2005-01-24 12:44:29.000000000 +0100
+++ linux-test/include/linux/netfilter_ipv4/ip_conntrack_tftp.h	2005-01-24 21:11:05.000000000 +0100
@@ -13,8 +13,8 @@ struct tftphdr {
 #define TFTP_OPCODE_ACK		4
 #define TFTP_OPCODE_ERROR	5
 
-unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
-				 enum ip_conntrack_info ctinfo,
-				 struct ip_conntrack_expect *exp);
+extern unsigned int (*ip_nat_tftp_hook)(struct sk_buff **pskb,
+					enum ip_conntrack_info ctinfo,
+					struct ip_conntrack_expect *exp);
 
 #endif /* _IP_CT_TFTP */

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH] move common compat ioctls to hash
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (14 preceding siblings ...)
  2005-01-24 20:24     ` 2.6.11-rc2-mm1 - compile fix Benoit Boissinot
@ 2005-01-24 20:26     ` Michael S. Tsirkin
  2005-01-25  6:17       ` Andi Kleen
  2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
                       ` (6 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-24 20:26 UTC (permalink / raw)
  To: Andi Kleen; +Cc: hch, linux-kernel, chrisw, davem

Hi!
The new ioctl code in fs/compat.c can be streamlined a little
using the compat hash instead of an explicit switch statement.

The attached patch is against 2.6.11-rc2-bk2.
Andi, could you please comment? Does this make sence?

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

diff -rup linux-2.6.10/fs/compat.c linux-2.6.10-rc2-bk2/fs/compat.c
--- linux-2.6.10/fs/compat.c	2005-01-24 21:47:17.252499536 +0200
+++ linux-2.6.10-rc2-bk2/fs/compat.c	2005-01-24 22:06:00.254777240 +0200
@@ -439,37 +439,10 @@ asmlinkage long compat_sys_ioctl(unsigne
 	if (!filp)
 		goto out;
 
-	/*
-	 * To allow the compat_ioctl handlers to be self contained
-	 * we need to check the common ioctls here first.
-	 * Just handle them with the standard handlers below.
-	 */
-	switch (cmd) {
-	case FIOCLEX:
-	case FIONCLEX:
-	case FIONBIO:
-	case FIOASYNC:
-	case FIOQSIZE:
-		break;
-
-	case FIBMAP:
-	case FIGETBSZ:
-	case FIONREAD:
-		if (S_ISREG(filp->f_dentry->d_inode->i_mode))
-			break;
-		/*FALL THROUGH*/
-
-	default:
-		if (filp->f_op && filp->f_op->compat_ioctl) {
-			error = filp->f_op->compat_ioctl(filp, cmd, arg);
-			if (error != -ENOIOCTLCMD)
-				goto out_fput;
-		}
-
-		if (!filp->f_op ||
-		    (!filp->f_op->ioctl && !filp->f_op->unlocked_ioctl))
-			goto do_ioctl;
-		break;
+	if (filp->f_op && filp->f_op->compat_ioctl) {
+		error = filp->f_op->compat_ioctl(filp, cmd, arg);
+		if (error != -ENOIOCTLCMD)
+			goto out_fput;
 	}
 
 	/* When register_ioctl32_conversion is finally gone remove
@@ -509,7 +482,7 @@ asmlinkage long compat_sys_ioctl(unsigne
 	}
 
 	up_read(&ioctl32_sem);
- do_ioctl:
+ 
 	error = sys_ioctl(fd, cmd, arg);
  out_fput:
 	fput_light(filp, fput_needed);
diff -rup linux-2.6.10/fs/ioctl.c linux-2.6.10-rc2-bk2/fs/ioctl.c
--- linux-2.6.10/fs/ioctl.c	2005-01-24 21:47:17.400477040 +0200
+++ linux-2.6.10-rc2-bk2/fs/ioctl.c	2005-01-24 22:05:38.346107864 +0200
@@ -80,7 +80,7 @@ static int file_ioctl(struct file *filp,
 
 /*
  * When you add any new common ioctls to the switches above and below
- * please update compat_sys_ioctl() too.
+ * please update compat_ioctl.h too.
  */
 asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
 {
diff -rup linux-2.6.10/include/linux/compat_ioctl.h linux-2.6.10-rc2-bk2/include/linux/compat_ioctl.h
--- linux-2.6.10/include/linux/compat_ioctl.h	2005-01-24 21:47:21.486855816 +0200
+++ linux-2.6.10-rc2-bk2/include/linux/compat_ioctl.h	2005-01-24 22:06:22.349418344 +0200
@@ -10,6 +10,15 @@
 #define ULONG_IOCTL(cmd)  HANDLE_IOCTL((cmd),(ioctl_trans_handler_t)sys_ioctl)
 #endif
 
+/* Common stuff */
+HANDLE_IOCTL(FIOCLEX)
+HANDLE_IOCTL(FIONCLEX)
+HANDLE_IOCTL(FIONBIO)
+HANDLE_IOCTL(FIOASYNC)
+HANDLE_IOCTL(FIOQSIZE)
+HANDLE_IOCTL(FIBMAP)
+HANDLE_IOCTL(FIGETBSZ)
+HANDLE_IOCTL(FIONREAD)
 /* Big T */
 COMPATIBLE_IOCTL(TCGETA)
 COMPATIBLE_IOCTL(TCSETA)


-- 
I dont speak for Mellanox.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 19:32                 ` Dmitry Torokhov
@ 2005-01-24 20:28                   ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 20:28 UTC (permalink / raw)
  To: dtor_core
  Cc: dmitry.torokhov, Adrian Bunk, Jurriaan, Andrew Morton,
	Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 14:32:19 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > > > > lsmod in bugreports giving unspecific results, for example.
> > > >
> > > > If you load scx200 from superio subsystem, then obviously you can not
> > > > use old i2c/acb modules which require old scx200.
> > > > And vice versa.
> > > >
> > > > One needs to load exactly what he wants.
> > >
> > > You did not understand what Jurriaan said:
> > >
> > > Even if it was working, "lsmod" would not be able to tell which of the
> > > two modules was loaded.
> > >
> > > This would cause much headache for many people.
> > 
> > 
> > Module is just a piece of code, or programm if someone may think.
> > And there no problems when we type
> > $ ps
> > and see only "aterm", if someone wants to know what exactly means "aterm",
> > one can run ps axufw.
> > And even with the case of lsmod: one can see that scx200 will or will not
> > depend on superio, and that will explain everything.

Before I murdered in my bad, I want to say, that I agree that changing 
scx200 into scx is easier and probably better idea.
And I will do it(I am doing it right now),

> There are so many problems and ambiguites with having non-unique
> module names it is not even funny:
> - when I modprobe scx200 what willI get?

Sorry or answering with a question, but what will you run when typing 
aterm in your shell?
Is it simlink to xterm, or /bin/aterm, or /usr/local/bin/aterm?
It depends on $PATH, with modprobe it depends on something else...
Bug? Probably. Feature? Maybe. I do not complain.

> - if I want to blacklist one of the modules (let's say hotplug) how do
> I do that?

When you want to run exact program, you type the whole path, no?
Load exact modules with known-to-be-good pathes.
I can hack shell script over modprobe to warn if there are several modules 
with the same name, and ask exact path or something...

> - lsmod (with everything else compiled in, possible?) - which one is loadded?

/sbin/modinfo shows enough information about module to distingiush one from another.

> ...etc, etc...


I understand your point of view, and can say, that the same module names are not 
very convenient and some times even confused, but it is not a cause to kill
such idea and mark it as badly broken.
It is right thing, it just currently has some nitpicks, nothing more, noone complains
that modules for different kernel versions have the same name, but different
elf sections in it, it is of course different things, but they do have the same 
roots in common.

As I have beed told in private, 
"what is technically possible, is not necessarily practically useful.", probably
it is the essence.

Thank you for discussion.
 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
  2005-01-24 18:43       ` Evgeniy Polyakov
@ 2005-01-24 20:33       ` Christoph Hellwig
  2005-01-24 21:10         ` Evgeniy Polyakov
  2005-01-24 21:34       ` Greg KH
  2 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 20:33 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Andrew Morton, Greg Kroah-Hartman, Evgeniy Polyakov, linux-kernel

On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> It seems noone who reviewed the SuperIO patches noticed that there are 
> now two modules "scx200" in the kernel...

Did anyone review them?


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 12:12     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-24 20:36       ` Karsten Keil
  2005-01-24 23:26         ` 2.6.11-rc2-mm1 Christoph Hellwig
  2005-01-24 23:32         ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
  2005-01-24 21:03       ` 2.6.11-rc2-mm1 Andrew Morton
  1 sibling, 2 replies; 152+ messages in thread
From: Karsten Keil @ 2005-01-24 20:36 UTC (permalink / raw)
  To: linux-kernel

On Mon, Jan 24, 2005 at 12:12:26PM +0000, Christoph Hellwig wrote:
> > +i4l-new-hfc_usb-driver-version.patch
> 
> this drivers wants:
> 
>  - update for Documentation/CodingStyle

agree, I only take the patch from chip manufacturer and
test compiling and working with my hardware and do not look at code style
yet.

>  - conversion to proper pci API

??? the driver is not PCI related at all


-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 18:52       ` 2.6.11-rc2-mm1 Dave Jones
@ 2005-01-24 20:44         ` Dave Jones
  2005-01-24 21:31           ` 2.6.11-rc2-mm1 Brice Goglin
  0 siblings, 1 reply; 152+ messages in thread
From: Dave Jones @ 2005-01-24 20:44 UTC (permalink / raw)
  To: Brice.Goglin, Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 01:52:58PM -0500, Dave Jones wrote:
 > On Mon, Jan 24, 2005 at 12:56:58PM +0100, Brice Goglin wrote:
 >  > X does not work anymore when using DRI on my Compaq Evo N600c (Radeon 
 >  > Mobility M6 LY).
 >  > My XFree 4.3 (from Debian testing) with DRI uses drm and radeon kernel 
 >  > modules.
 >  
 > My fault. I'm looking into it.
 > Drop the agpgart-bk update for now.

Here's the most obvious bug fixed. There still seems to be
something wrong however. It only successfully boots 50% of the
time for me, (it reboots when starting X otherwise), and when
it does boot, I get a flood of ...
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800
Warning: kfree_skb on hard IRQ cf7b5800

I think there may be some stupid memory corruptor bug in there still.

		Dave

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/24 15:37:57-05:00 davej@redhat.com 
#   [AGPGART] Fix stupid thinko in device discovery.
#   
#   Should fix the 'cant find AGP VGA controller' warnings.
#   
#   Signed-off-by: Dave Jones <davej@redhat.com>

diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c	2005-01-24 15:38:26 -05:00
+++ b/drivers/char/agp/generic.c	2005-01-24 15:38:26 -05:00
@@ -626,7 +626,7 @@
 	u32 vga_agpstat;
 
 	while (!cap_ptr) {
-		device = pci_get_class(PCI_CLASS_DISPLAY_VGA, device);
+		device = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, device);
 		if (!device) {
 			printk (KERN_INFO PFX "Couldn't find an AGP VGA controller.\n");
 			return 0;

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 12:12     ` 2.6.11-rc2-mm1 Christoph Hellwig
  2005-01-24 20:36       ` 2.6.11-rc2-mm1 Karsten Keil
@ 2005-01-24 21:03       ` Andrew Morton
  1 sibling, 0 replies; 152+ messages in thread
From: Andrew Morton @ 2005-01-24 21:03 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel, Roland McGrath

Christoph Hellwig <hch@infradead.org> wrote:
>
> > +posix-timers-tidy-up-clock-interfaces-and-consolidate-dispatch-logic.patch
> 
>  umm, this adds extreme obsfucation.  Roland, please try to follow normal
>  Linux style, thanks.

Best cc Roland - not everyone follows linux-kernel.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 20:33       ` Christoph Hellwig
@ 2005-01-24 21:10         ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-24 21:10 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Mon, 24 Jan 2005 20:33:53 +0000
Christoph Hellwig <hch@infradead.org> wrote:

> On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> > It seems noone who reviewed the SuperIO patches noticed that there are 
> > now two modules "scx200" in the kernel...
> 
> Did anyone review them?

As I said it is completely my fault, I pressed on Greg, 
since patch several month laid after testing and people often asked
about GPIO in various SuperIO chips.

Patches were sent into lm_sensors@ mail list some time ago 
and code itself did not meet any objections.

	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 20:44         ` 2.6.11-rc2-mm1 Dave Jones
@ 2005-01-24 21:31           ` Brice Goglin
  2005-01-25 19:38             ` 2.6.11-rc2-mm1 Dave Jones
  0 siblings, 1 reply; 152+ messages in thread
From: Brice Goglin @ 2005-01-24 21:31 UTC (permalink / raw)
  To: Dave Jones; +Cc: Andrew Morton, linux-kernel

Dave Jones a écrit :
> Here's the most obvious bug fixed. There still seems to be
> something wrong however. It only successfully boots 50% of the
> time for me, (it reboots when starting X otherwise), and when
> it does boot, I get a flood of ...
> Warning: kfree_skb on hard IRQ cf7b5800
> Warning: kfree_skb on hard IRQ cf7b5800
> Warning: kfree_skb on hard IRQ cf7b5800
> 
> I think there may be some stupid memory corruptor bug in there still.
> 
> 		Dave

Thanks, your patch makes X work again with DRI.
Actually, it successfully booted 100% of the time here.
I tried 6 or 7 times without seeing any problem like yours.
Let me know if you want me to try something special.

Brice

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
  2005-01-24 18:43       ` Evgeniy Polyakov
  2005-01-24 20:33       ` Christoph Hellwig
@ 2005-01-24 21:34       ` Greg KH
  2005-01-24 21:47         ` Christoph Hellwig
  2 siblings, 1 reply; 152+ messages in thread
From: Greg KH @ 2005-01-24 21:34 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, Evgeniy Polyakov, linux-kernel

On Mon, Jan 24, 2005 at 06:54:49PM +0100, Adrian Bunk wrote:
> It seems noone who reviewed the SuperIO patches noticed that there are 
> now two modules "scx200" in the kernel...

Sorry about this.  Andrew warning me about this bug, and I saw it myself
with the depmod errors.  I'll take Evgeniy's patch for my tree and it
should show up in the next -mm release.

And as for the "these patches have never been reviewed" comments, that's
why I put them in my tree, and have them show up in -mm.  It's getting
them a wider exposure and finding out these kinds of issues.  So the
process is working properly :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 21:34       ` Greg KH
@ 2005-01-24 21:47         ` Christoph Hellwig
  2005-01-25  6:02           ` Greg KH
  0 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 21:47 UTC (permalink / raw)
  To: Greg KH; +Cc: Adrian Bunk, Andrew Morton, Evgeniy Polyakov, linux-kernel

On Mon, Jan 24, 2005 at 01:34:42PM -0800, Greg KH wrote:
> And as for the "these patches have never been reviewed" comments, that's
> why I put them in my tree, and have them show up in -mm.  It's getting
> them a wider exposure and finding out these kinds of issues.  So the
> process is working properly :)

It would be a lot more productive to follow the normal rules, though.
That is posting them on lkml as properly split up patches, and with
proper descriptions of what they're doing.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 20:36       ` 2.6.11-rc2-mm1 Karsten Keil
@ 2005-01-24 23:26         ` Christoph Hellwig
  2005-01-25  0:35           ` 2.6.11-rc2-mm1 Karsten Keil
  2005-01-24 23:32         ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
  1 sibling, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-24 23:26 UTC (permalink / raw)
  To: linux-kernel

On Mon, Jan 24, 2005 at 09:36:24PM +0100, Karsten Keil wrote:
> >  - conversion to proper pci API
> 
> ??? the driver is not PCI related at all

Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 20:36       ` 2.6.11-rc2-mm1 Karsten Keil
  2005-01-24 23:26         ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-24 23:32         ` Bartlomiej Zolnierkiewicz
  1 sibling, 0 replies; 152+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2005-01-24 23:32 UTC (permalink / raw)
  To: Karsten Keil, linux-kernel

On Mon, 24 Jan 2005 21:36:24 +0100, Karsten Keil <kkeil@suse.de> wrote:
> On Mon, Jan 24, 2005 at 12:12:26PM +0000, Christoph Hellwig wrote:
> > > +i4l-new-hfc_usb-driver-version.patch
> >
> > this drivers wants:
> >
> >  - update for Documentation/CodingStyle
> 
> agree, I only take the patch from chip manufacturer and
> test compiling and working with my hardware and do not look at code style
> yet.
> 
> >  - conversion to proper pci API
> 
> ??? the driver is not PCI related at all

it seems that hch wanted to also mention this patch:

i4l-hfc-4s-and-hfc-8s-driver.patch

and it is indeed a very ugly one...

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [linux-dvb-maintainer] 2.6.11-rc2-mm1: DVB compile error
  2005-01-24 12:48     ` 2.6.11-rc2-mm1: DVB compile error Adrian Bunk
@ 2005-01-24 23:56       ` Johannes Stezenbach
  0 siblings, 0 replies; 152+ messages in thread
From: Johannes Stezenbach @ 2005-01-24 23:56 UTC (permalink / raw)
  To: Adrian Bunk
  Cc: Andrew Morton, patrick.boettcher, linux-dvb-maintainer, linux-kernel

Adrian Bunk wrote:
> The following compile error comes from Linus' tree:
> 
> <--  snip  -->
> 
> ...
>   LD      .tmp_vmlinux1
> drivers/built-in.o(.bss+0xd50e4): multiple definition of `debug'
> arch/i386/kernel/built-in.o(.text+0x2e4c): first defined here
> make: *** [.tmp_vmlinux1] Error 1
> 
> <--  snip  -->
> 
> 
> The offender is in drivers/media/dvb/dibusb/dvb-dibusb-core.c:
> 
> "debug" is not a good name for a global variable...

I've sorted this out with Patrick. The attached patch cleans up
various aspects of dibusb module argument handling, so it's a bit
larger than just renaming "debug".

Andrew, could you please make sure this patch and
dib3000mc-build-fix.patch (from rc2-mm1) will be
merged into Linus tree before 2.6.11? Or should I
submit it to Linus seperately?

Thanks,
Johannes


diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-core.c	2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-core.c	2005-01-24 23:16:27.000000000 +0100
@@ -27,17 +27,19 @@
 #include <linux/moduleparam.h>
 
 /* debug */
-#ifdef CONFIG_DVB_DIBCOM_DEBUG
-int debug;
-module_param(debug, int, 0644);
-MODULE_PARM_DESC(debug, "set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able)).");
+int dvb_dibusb_debug;
+module_param_named(debug, dvb_dibusb_debug,  int, 0644);
+MODULE_PARM_DESC(debug, "set debugging level (1=info,2=xfer,4=alotmore,8=ts,16=err,32=rc (|-able))."
+#ifndef CONFIG_DVB_DIBCOM_DEBUG
+		" (debugging is not enabled)"
 #endif
+);
 
-int pid_parse;
+static int pid_parse;
 module_param(pid_parse, int, 0644);
 MODULE_PARM_DESC(pid_parse, "enable pid parsing (filtering) when running at USB2.0");
 
-int rc_query_interval;
+static int rc_query_interval;
 module_param(rc_query_interval, int, 0644);
 MODULE_PARM_DESC(rc_query_interval, "interval in msecs for remote control query (default: 100; min: 40)");
 
@@ -410,6 +412,10 @@ static int dibusb_probe(struct usb_inter
 		dib->udev = udev;
 		dib->dibdev = dibdev;
 
+		/* store parameters to structures */
+		dib->rc_query_interval = rc_query_interval;
+		dib->pid_parse = pid_parse;
+
 		usb_set_intfdata(intf, dib);
 		
 		ret = dibusb_init(dib);
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-remote.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-remote.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-remote.c	2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-remote.c	2005-01-24 18:26:53.000000000 +0100
@@ -143,7 +143,7 @@ static void dibusb_remote_query(void *da
 	   if we're busy. */
 	dibusb_read_remote_control(dib);
 	schedule_delayed_work(&dib->rc_query_work,
-			      msecs_to_jiffies(rc_query_interval));
+			      msecs_to_jiffies(dib->rc_query_interval));
 }
 
 int dibusb_remote_init(struct usb_dibusb *dib)
@@ -171,11 +171,11 @@ int dibusb_remote_init(struct usb_dibusb
 	INIT_WORK(&dib->rc_query_work, dibusb_remote_query, dib);
 
 	/* Start the remote-control polling. */
-	if (rc_query_interval < 40)
-		rc_query_interval = 100; /* default */
+	if (dib->rc_query_interval < 40)
+		dib->rc_query_interval = 100; /* default */
 
-	info("schedule remote query interval to %d msecs.",rc_query_interval);
-	schedule_delayed_work(&dib->rc_query_work,msecs_to_jiffies(rc_query_interval));
+	info("schedule remote query interval to %d msecs.",dib->rc_query_interval);
+	schedule_delayed_work(&dib->rc_query_work,msecs_to_jiffies(dib->rc_query_interval));
 
 	dib->init_state |= DIBUSB_STATE_REMOTE;
 	
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-usb.c
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb-usb.c	2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb-usb.c	2005-01-24 18:26:53.000000000 +0100
@@ -158,7 +158,7 @@ int dibusb_streaming(struct usb_dibusb *
 
 int dibusb_urb_init(struct usb_dibusb *dib)
 {
-	int ret,i,bufsize;
+	int ret,i,bufsize,def_pid_parse = 1;
 	
 	/*
 	 * when reloading the driver w/o replugging the device 
@@ -210,12 +210,14 @@ int dibusb_urb_init(struct usb_dibusb *d
 		dib->init_state |= DIBUSB_STATE_URB_SUBMIT;
 	}
 
-
-	dib->pid_parse = 1;
+	/* dib->pid_parse here contains the value of the module parameter */
+	/* decide if pid parsing can be deactivated: 
+	 * is possible (by speed) and wanted (by user) 
+	 */
 	switch (dib->dibdev->dev_cl->id) {
 		case DIBUSB2_0:
-			if (dib->udev->speed == USB_SPEED_HIGH && !pid_parse) {
-				dib->pid_parse = 0;
+			if (dib->udev->speed == USB_SPEED_HIGH && !dib->pid_parse) {
+				def_pid_parse = 0;
 				info("running at HIGH speed, will deliver the complete TS.");
 			} else
 				info("will use pid_parsing.");
@@ -223,6 +225,8 @@ int dibusb_urb_init(struct usb_dibusb *d
 		default: 
 			break;
 	}
+	/* from here on it contains the device and user decision */
+	dib->pid_parse = def_pid_parse;
 	
 	return 0;
 }
diff -rupN linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb.h linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb.h
--- linux-2.6.11-rc2-mm1/drivers/media/dvb/dibusb/dvb-dibusb.h	2005-01-24 23:31:05.000000000 +0100
+++ linux-2.6.11-rc2-mm1-dvb/drivers/media/dvb/dibusb/dvb-dibusb.h	2005-01-24 18:26:53.000000000 +0100
@@ -27,31 +27,26 @@
 /* debug */
 #ifdef CONFIG_DVB_DIBCOM_DEBUG
 #define dprintk(level,args...) \
-	    do { if ((debug & level)) { printk(args); } } while (0)
+	    do { if ((dvb_dibusb_debug & level)) { printk(args); } } while (0)
 
-#define debug_dump(b,l) if (debug) {\
-	int i; deb_xfer("%s: %d > ",__FUNCTION__,l); \
+#define debug_dump(b,l) {\
+	int i; \
 	for (i = 0; i < l; i++) deb_xfer("%02x ", b[i]); \
 	deb_xfer("\n");\
 }
 
-/* module parameters - declared in -core.c */
-extern int debug;
-
 #else
 #define dprintk(args...)
 #define debug_dump(b,l)
 #endif
 
+extern int dvb_dibusb_debug;
+
 /* Version information */
 #define DRIVER_VERSION "0.3"
 #define DRIVER_DESC "Driver for DiBcom based USB Budget DVB-T device"
 #define DRIVER_AUTHOR "Patrick Boettcher, patrick.boettcher@desy.de"
 
-/* module parameters - declared in -core.c */
-extern int pid_parse;
-extern int rc_query_interval;
-
 #define deb_info(args...) dprintk(0x01,args)
 #define deb_xfer(args...) dprintk(0x02,args)
 #define deb_alot(args...) dprintk(0x04,args)
@@ -162,7 +157,6 @@ struct usb_dibusb {
 	int init_state;
 
 	int feedcount;
-	int pid_parse;
 	struct dib_fe_xfer_ops xfer_ops;
 
 	struct dibusb_tuner *tuner;
@@ -196,6 +190,10 @@ struct usb_dibusb {
 	struct input_dev rc_input_dev;
 	struct work_struct rc_query_work;
 	int rc_input_event;
+
+	/* module parameters */
+	int pid_parse;
+	int rc_query_interval;
 };
 
 /* commonly used functions in the separated files */

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (15 preceding siblings ...)
  2005-01-24 20:26     ` [PATCH] move common compat ioctls to hash Michael S. Tsirkin
@ 2005-01-25  0:03     ` Sytse Wielinga
  2005-01-25  7:31       ` Miklos Szeredi
                         ` (2 more replies)
  2005-01-25  1:01     ` 2.6.11-rc2-mm1 Brice Goglin
                       ` (5 subsequent siblings)
  22 siblings, 3 replies; 152+ messages in thread
From: Sytse Wielinga @ 2005-01-25  0:03 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

Hi Andrew,

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> fuse-transfer-readdir-data-through-device.patch
>   fuse: transfer readdir data through device
It is great that this is fixed, don't remove it, but it does require the fuse
libs to be updated at the same time, or opening dirs for listings will break
like this:

open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
not implemented)

As I personally like for my ls to keep on working, and I assume others will,
too, I would appreciate it if you could add a warning to your announcements the
following one or two weeks or so, so that people can remove this patch if they
don't want to update their libs.

Thank you.

    Sytse

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 23:26         ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-25  0:35           ` Karsten Keil
  0 siblings, 0 replies; 152+ messages in thread
From: Karsten Keil @ 2005-01-25  0:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: Christoph Hellwig

On Mon, Jan 24, 2005 at 11:26:03PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 09:36:24PM +0100, Karsten Keil wrote:
> > >  - conversion to proper pci API
> > 
> > ??? the driver is not PCI related at all
> 
> Sorry, this was actually a comment for i4l-hfc-4s-and-hfc-8s-driver.patch.
> 

OK, in the meantime I assumed this too and informed the author about the
problems, I think most things will be solved soon.

I can correct CodingStyle for hfc_usb.c too, this give ~30K bigger patch.

Thanks for the formal code checks, I forget them sometimes, if I get code
from 3 party.

-- 
Karsten Keil
SuSE Labs
ISDN development

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (16 preceding siblings ...)
  2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
@ 2005-01-25  1:01     ` Brice Goglin
  2005-01-25  1:30       ` 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND) Len Brown
  2005-01-25 18:41       ` 2.6.11-rc2-mm1 Pavel Machek
  2005-01-25 12:53     ` 2.6.11-rc2-mm1 Christoph Hellwig
                       ` (4 subsequent siblings)
  22 siblings, 2 replies; 152+ messages in thread
From: Brice Goglin @ 2005-01-25  1:01 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

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

Andrew Morton a écrit :
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> 
> 
> - Lots of updates and fixes all over the place.
> 
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
> 
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

Hi Andrew,

ACPI does not work anymore on my Compaq Evo N600c
(no thermal zone, no fan, no battery, ...).
It works great on Linus' 2.6.11-rc2, and (from what I remember)
it was working on the last -mm releases I tried.

Here's a bunch of lines from dmesg.
.config and lspci attached.

Regards,
Brice


exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node e7fcd548
  dswexec-0446 [21] ds_exec_end_op        : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR] (Node c15ed8c8), AE_AML_NO_OPERAND
  acpi_ac-0098 [12] acpi_ac_get_state     : Error reading AC Adapter state
ACPI: Battery Slot [C19F] (battery absent)
ACPI: Battery Slot [C1A0] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [C1A3]
ACPI: Lid Switch [C1A4]
ACPI: Fan [C1F6] (off)
ACPI: Fan [C1F7] (off)
ACPI: Fan [C1F8] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node e7fcd548
  dswexec-0446 [28] ds_exec_end_op        : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node c15ef3c8), AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node c15ef0c8), AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP] (Node c15f05c8), AE_AML_NO_OPERAND
ACPI wakeup devices:
C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
ACPI: (supports S0 S1 S3 S4 S4bios S5)
exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node e7fcd548
  dswexec-0446 [23] ds_exec_end_op        : [Acquire]: Could not resolve operands, AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
  psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node c15f0248), AE_AML_NO_OPERAND
    evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method [_L10] for GPE[ 0]

[-- Attachment #2: config.gz --]
[-- Type: application/x-gunzip, Size: 8928 bytes --]

[-- Attachment #3: lspci.gz --]
[-- Type: application/x-gunzip, Size: 437 bytes --]

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND)
  2005-01-25  1:01     ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-25  1:30       ` Len Brown
  2005-01-25 18:41       ` 2.6.11-rc2-mm1 Pavel Machek
  1 sibling, 0 replies; 152+ messages in thread
From: Len Brown @ 2005-01-25  1:30 UTC (permalink / raw)
  To: Brice.Goglin; +Cc: Andrew Morton, linux-kernel

On Mon, 2005-01-24 at 20:01, Brice Goglin wrote:
> Andrew Morton a écrit :

> 
> ACPI does not work anymore on my Compaq Evo N600c
> (no thermal zone, no fan, no battery, ...).
> It works great on Linus' 2.6.11-rc2, and (from what I remember)
> it was working on the last -mm releases I tried.
> 
> Here's a bunch of lines from dmesg.
...
> 
> 
> exresnte-0133 [24] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [21] ds_exec_end_op        : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C12A] (Node c15e5788), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_SB_.C1A2._PSR]
> (Node c15ed8c8), AE_AML_NO_OPERAND
>   acpi_ac-0098 [12] acpi_ac_get_state     : Error reading AC Adapter
> state
> ACPI: Battery Slot [C19F] (battery absent)
> ACPI: Battery Slot [C1A0] (battery absent)
> ACPI: Power Button (FF) [PWRF]
> ACPI: Sleep Button (CM) [C1A3]
> ACPI: Lid Switch [C1A4]
> ACPI: Fan [C1F6] (off)
> ACPI: Fan [C1F7] (off)
> ACPI: Fan [C1F8] (off)
> ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
> exresnte-0133 [31] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [28] ds_exec_end_op        : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C11A] (Node c15e5b48), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.C11A] (Node
> c15ef3c8), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.C1F1] (Node
> c15ef0c8), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_TZ_.TZ1_._TMP]
> (Node c15f05c8), AE_AML_NO_OPERAND
> ACPI wakeup devices:
> C052 C17E C185 C0A4 C0AA C19F C1A0 C1A3 C1A4
> ACPI: (supports S0 S1 S3 S4 S4bios S5)
> exresnte-0133 [26] ex_resolve_node_to_val: No object attached to node
> e7fcd548
>   dswexec-0446 [23] ds_exec_end_op        : [Acquire]: Could not
> resolve operands, AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed
> [\_SB_.C03E.C053.C0D1.C119] (Node c15e5b88), AE_AML_NO_OPERAND
>   psparse-1138: *** Error: Method execution failed [\_GPE._L10] (Node
> c15f0248), AE_AML_NO_OPERAND
>     evgpe-0552: *** Error: AE_AML_NO_OPERAND while evaluating method
> [_L10] for GPE[ 0]

Please patch -Rp1 this file:
http://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/bk-acpi.patch
to verify that the issue goes away when backing out the ACPI part of the
latest mm patch.

We'll likely need your acpidmp output to bottom out on this.
Please open a bug here:

http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Category: AML-interpreter

and attach (don't paste) the output from acpidmp, available in /usr/sbin
or in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
along with the complete dmesg -s64000 output of the failure case.

thanks,
-Len



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 21:47         ` Christoph Hellwig
@ 2005-01-25  6:02           ` Greg KH
  2005-01-25  7:11             ` Christoph Hellwig
  2005-01-25 18:59             ` Jean Delvare
  0 siblings, 2 replies; 152+ messages in thread
From: Greg KH @ 2005-01-25  6:02 UTC (permalink / raw)
  To: Christoph Hellwig, Adrian Bunk, Andrew Morton, Evgeniy Polyakov,
	linux-kernel

On Mon, Jan 24, 2005 at 09:47:51PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 24, 2005 at 01:34:42PM -0800, Greg KH wrote:
> > And as for the "these patches have never been reviewed" comments, that's
> > why I put them in my tree, and have them show up in -mm.  It's getting
> > them a wider exposure and finding out these kinds of issues.  So the
> > process is working properly :)
> 
> It would be a lot more productive to follow the normal rules, though.
> That is posting them on lkml as properly split up patches, and with
> proper descriptions of what they're doing.

As previously mentioned, these patches have had that, on the sensors
mailing list.  Lots of review and comments went into them there, and the
code was reworked quite a lot based on it.

Surely you don't want me to forward _every_ driver patch that I get to
lkml first?  :)

That's what all of the subsystem specific mailing lists are for...

thanks,

greg k-h


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH] move common compat ioctls to hash
  2005-01-24 20:26     ` [PATCH] move common compat ioctls to hash Michael S. Tsirkin
@ 2005-01-25  6:17       ` Andi Kleen
  2005-01-26  8:40         ` Michael S. Tsirkin
  0 siblings, 1 reply; 152+ messages in thread
From: Andi Kleen @ 2005-01-25  6:17 UTC (permalink / raw)
  To: Michael S. Tsirkin; +Cc: Andi Kleen, hch, linux-kernel, chrisw, davem

On Mon, Jan 24, 2005 at 10:26:09PM +0200, Michael S. Tsirkin wrote:
> Hi!
> The new ioctl code in fs/compat.c can be streamlined a little
> using the compat hash instead of an explicit switch statement.
> 
> The attached patch is against 2.6.11-rc2-bk2.
> Andi, could you please comment? Does this make sence?

Problem is that when a compat_ioctl handler returns -EINVAL
instead of -ENOIOCTLCMD on unknown ioctl it won't check the common
ones.

I fear this mistake would be common, that is why I put in the switch.

-Andi

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [1/1] superio: remove unneded exports and make some functions static.
  2005-01-24 14:14             ` [1/1] superio: remove unneded exports and make some functions static Evgeniy Polyakov
@ 2005-01-25  6:19               ` Greg KH
  0 siblings, 0 replies; 152+ messages in thread
From: Greg KH @ 2005-01-25  6:19 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 05:14:04PM +0300, Evgeniy Polyakov wrote:
> Remove unneded exports and make some functions static.
> 
> Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>

Applied, thanks.

greg k-h

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25  6:02           ` Greg KH
@ 2005-01-25  7:11             ` Christoph Hellwig
  2005-01-25 18:59             ` Jean Delvare
  1 sibling, 0 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-25  7:11 UTC (permalink / raw)
  To: Greg KH
  Cc: Christoph Hellwig, Adrian Bunk, Andrew Morton, Evgeniy Polyakov,
	linux-kernel

On Mon, Jan 24, 2005 at 10:02:56PM -0800, Greg KH wrote:
> > It would be a lot more productive to follow the normal rules, though.
> > That is posting them on lkml as properly split up patches, and with
> > proper descriptions of what they're doing.
> 
> As previously mentioned, these patches have had that, on the sensors
> mailing list.  Lots of review and comments went into them there, and the
> code was reworked quite a lot based on it.
> 
> Surely you don't want me to forward _every_ driver patch that I get to
> lkml first?  :)

If you add completely new subsystems please send them to lkml first.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
@ 2005-01-25  7:31       ` Miklos Szeredi
  2005-01-27 15:45       ` Bill Davidsen
  2005-01-27 18:09       ` Christoph Hellwig
  2 siblings, 0 replies; 152+ messages in thread
From: Miklos Szeredi @ 2005-01-25  7:31 UTC (permalink / raw)
  To: s.b.wielinga; +Cc: akpm, linux-kernel

> > fuse-transfer-readdir-data-through-device.patch
> >   fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
> 
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> not implemented)
> 
> As I personally like for my ls to keep on working, and I assume
> others will, too, I would appreciate it if you could add a warning
> to your announcements the following one or two weeks or so, so that
> people can remove this patch if they don't want to update their
> libs.

This is my fault, sorry.

I promise, that there'll be no more backward incompatible changes (and
if there will, a big warning about library dependency will be added :).

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
  2005-01-24 17:45         ` Adrian Bunk
@ 2005-01-25 10:15           ` Gerd Knorr
  2005-01-25 10:38             ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Gerd Knorr @ 2005-01-25 10:15 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel

> > The patch below should fix this.
> 
> Not completely:

>   CC      drivers/media/video/saa7134/saa7134-core.o
> drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
> drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)

New version, this time using a #define, which should kill the reference
to need_* as well ...

  Gerd

Index: linux-2005-01-23/drivers/media/video/saa7134/saa7134-core.c
===================================================================
--- linux-2005-01-23.orig/drivers/media/video/saa7134/saa7134-core.c	2005-01-24 18:43:20.000000000 +0100
+++ linux-2005-01-23/drivers/media/video/saa7134/saa7134-core.c	2005-01-25 10:04:17.000000000 +0100
@@ -21,6 +21,7 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include <linux/config.h>
 #include <linux/init.h>
 #include <linux/list.h>
 #include <linux/module.h>
@@ -225,6 +226,8 @@ static void dump_statusregs(struct saa71
 /* ----------------------------------------------------------- */
 /* delayed request_module                                      */
 
+#ifdef CONFIG_MODULES
+
 static int need_empress;
 static int need_dvb;
 
@@ -265,6 +268,12 @@ static void request_module_depend(char *
 	}
 }
 
+#else
+
+#define request_module_depend(name,flag)
+
+#endif /* CONFIG_MODULES */
+
 /* ------------------------------------------------------------------ */
 
 /* nr of (saa7134-)pages for the given buffer size */

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: v4l-saa7134-module compile error
  2005-01-25 10:15           ` Gerd Knorr
@ 2005-01-25 10:38             ` Adrian Bunk
  0 siblings, 0 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-25 10:38 UTC (permalink / raw)
  To: Gerd Knorr; +Cc: Andrew Morton, linux-kernel

On Tue, Jan 25, 2005 at 11:15:09AM +0100, Gerd Knorr wrote:
> > > The patch below should fix this.
> > 
> > Not completely:
> 
> >   CC      drivers/media/video/saa7134/saa7134-core.o
> > drivers/media/video/saa7134/saa7134-core.c: In function `saa7134_initdev':
> > drivers/media/video/saa7134/saa7134-core.c:997: error: `need_empress' undeclared (first use in this function)
> 
> New version, this time using a #define, which should kill the reference
> to need_* as well ...

I can confirm that this patch fixes the compilation.

>   Gerd
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (17 preceding siblings ...)
  2005-01-25  1:01     ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-25 12:53     ` Christoph Hellwig
  2005-01-25 14:11       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 19:35       ` 2.6.11-rc2-mm1 Pavel Machek
  2005-01-25 19:12     ` 2.6.11-rc2-mm1 Marcos D. Marado Torres
                       ` (3 subsequent siblings)
  22 siblings, 2 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-25 12:53 UTC (permalink / raw)
  To: Andrew Morton, johnpol, greg; +Cc: linux-kernel

Review of the superio subsystem sneaked in through bk-i2c.patch:


diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/Kconfig	2005-01-23 22:34:15 -08:00
@@ -0,0 +1,56 @@
+menu "SuperIO subsystem support"
+
+config SC_SUPERIO
+	tristate "SuperIO subsystem support"
+	depends on CONNECTOR
+	help
+	  SuperIO subsystem support.
+	
+	  This support is also available as a module.  If so, the module
+          will be called superio.ko.

This doesn't mention what "SuperIO" is at all.  Also please skip the .ko
postfix for the module name as the intree Kconfigs do.  The boilerplate has
changed to:

  To compile this driver as a module, choose M here: the
  module will be called <foo>.

diff -Nru a/drivers/superio/Makefile b/drivers/superio/Makefile
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/Makefile	2005-01-23 22:34:15 -08:00
@@ -0,0 +1,11 @@
+#
+# Makefile for the SuperIO subsystem.
+#

Superflous.

+
+obj-$(CONFIG_SC_SUPERIO)	+= superio.o
+obj-$(CONFIG_SC_GPIO)		+= sc_gpio.o
+obj-$(CONFIG_SC_ACB)		+= sc_acb.o
+obj-$(CONFIG_SC_PC8736X)	+= pc8736x.o
+obj-$(CONFIG_SC_SCX200)		+= scx200.o
+
+superio-objs		:= sc.o chain.o sc_conn.o

please use superio-y += so new conditional objects can be added more easily.

diff -Nru a/drivers/superio/chain.c b/drivers/superio/chain.c
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/chain.c	2005-01-23 22:34:15 -08:00
@@ -0,0 +1,52 @@
+/*
+ * 	chain.c

superfluos, the file name is obvious.  (Dito for all other files)

+ * 
+ * 2004 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
+ * All rights reserved.
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include <asm/atomic.h>
+#include <asm/types.h>
+
+#include <linux/list.h>
+#include <linux/slab.h>

always include <asm/*> after <linux/*> headers.  Please use <linux/types.h>
istead of <asm/types.h> always.

(comment applies to later files aswell)

+#include "chain.h"
+
+struct dev_chain *chain_alloc(void *ptr)
+{
+	struct dev_chain *ch;
+
+	ch = kmalloc(sizeof(struct dev_chain), GFP_ATOMIC);
+	if (!ch) {
+		printk(KERN_ERR "Failed to allocate new chain for %p.\n", ptr);
+		return NULL;
+	}
+
+	memset(ch, 0, sizeof(struct dev_chain));
+
+	ch->ptr = ptr;
+
+	return ch;
+}
+
+void chain_free(struct dev_chain *ch)
+{
+	memset(ch, 0, sizeof(struct dev_chain));
+	kfree(ch);

The memset completely defeats slab redzoning to catch bugs, don't
do that.

Also what's the reason you can't simply put the list_head into struct
logical_dev?

+static void pc8736x_fini(void)
+{
+	sc_del_sc_dev(&pc8736x_dev);
+
+	while (atomic_read(&pc8736x_dev.refcnt)) {
+		printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
+				pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
+		
+		set_current_state(TASK_INTERRUPTIBLE);
+		schedule_timeout(HZ);
+			
+		if (current->flags & PF_FREEZE)
+			refrigerator(PF_FREEZE);
+
+		if (signal_pending(current))
+			flush_signals(current);
+	}
+}

And who gurantess this won't deadlock?  Please use a dynamically allocated
driver model device and it's refcounting, thanks.

+int sc_add_sc_dev(struct sc_dev *__sdev)

btw, what's the reason you use those ugly __ names for local variables all over?

+	while (atomic_read(&__sdev->refcnt)) {
+		printk(KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n",
+		       __sdev->name, atomic_read(&__sdev->refcnt));
+		set_current_state(TASK_UNINTERRUPTIBLE);
+		schedule_timeout(HZ);
+			
+		if (current->flags & PF_FREEZE)
+			refrigerator(PF_FREEZE);
+
+		if (signal_pending(current))
+			flush_signals(current);
+	}
+}

Again as above.

+static void sc_deactivate_logical(struct sc_dev *dev, struct logical_dev *ldev)
+{
+	printk(KERN_INFO "Deactivating logical device %s in SuperIO chip %s... ",
+	       ldev->name, dev->name);
+	
+	if (ldev->irq)
+	{
+		free_irq(ldev->irq, ldev);
+		ldev->irq = 0;
+	}

CodingStyle: if (ldev->irq) {  (also in various other places)

+static int __devinit sc_init(void)
+{
+	printk(KERN_INFO "SuperIO driver is starting...\n");
+
+	return sc_register_callback();
+}
+
+static void __devexit sc_fini(void)
+{
+	sc_unregister_callback();
+	printk(KERN_INFO "SuperIO driver finished.\n");
+}

quite noise.  Please only print messages when you find an actual
device and not on unloading at all.

+	INIT_LIST_HEAD(&ldev_acb.ldev_entry);
+	spin_lock_init(&ldev_acb.lock);

these two can be initialized at compile time.

+#include "../superio/sc.h"
+#include "../superio/sc_gpio.h"

just include them normalluy, ok?

+static int scx200_pci_probe(struct pci_dev *pdev,
+			    const struct pci_device_id *ent)
+{
+	private_base = pci_resource_start(pdev, 0);
+	printk(KERN_INFO "%s: GPIO base 0x%lx.\n", pci_name(pdev), private_base);
+
+	if (!request_region
+	    (private_base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO")) {
+		printk(KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n",
+		       pci_name(pdev), SCx200_GPIO_SIZE);
+		return -EBUSY;
+	}
+
+	pci_set_drvdata(pdev, &private_base);
+	pci_enable_device(pdev);

pci_enable_device needs to be done first, and it returns and error that
should be handled.

+	pci_unregister_driver(&scx200_pci_driver);
+	if (private_base)
+		release_region(private_base, SCx200_GPIO_SIZE);

this must happen in the ->remove callback.

diff -Nru a/drivers/superio/scx200.h b/drivers/superio/scx200.h
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/drivers/superio/scx200.h	2005-01-23 22:34:15 -08:00
@@ -0,0 +1,28 @@
+/*
+ * 	scx200.h
+ * 
+ * 2004 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
+ * All rights reserved.
+ * 
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef __SCX200_H
+#define __SCX200_H
+
+#define SCx200_GPIO_SIZE 	0x2c
+
+#endif /* __SCX200_H */

Yeah, right - a 30 line header for a single define that's used in a
single source file..

Also your locking is broken.  sdev_lock sometimes nests outside
sdev->lock and sometimes inside.  Similarly dev->chain_lock nests
inside dev->lock sometimes and sometimes outside.  You really need
a locking hiearchy document and the lockign should probably be
simplified a lot.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 12:53     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-25 14:11       ` Evgeniy Polyakov
  2005-01-25 14:23         ` 2.6.11-rc2-mm1 Christoph Hellwig
  2005-01-25 19:35       ` 2.6.11-rc2-mm1 Pavel Machek
  1 sibling, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 14:11 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, greg, linux-kernel

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

On Tue, 2005-01-25 at 12:53 +0000, Christoph Hellwig wrote:
> Review of the superio subsystem sneaked in through bk-i2c.patch:

Hmm, "sneaked"... Good start, Christoph.

> diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Kconfig	2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,56 @@
> +menu "SuperIO subsystem support"
> +
> +config SC_SUPERIO
> +	tristate "SuperIO subsystem support"
> +	depends on CONNECTOR
> +	help
> +	  SuperIO subsystem support.
> +	
> +	  This support is also available as a module.  If so, the module
> +          will be called superio.ko.
> 
> This doesn't mention what "SuperIO" is at all.  Also please skip the .ko
> postfix for the module name as the intree Kconfigs do.  The boilerplate has
> changed to:

Ok.

>   To compile this driver as a module, choose M here: the
>   module will be called <foo>.
> 
> diff -Nru a/drivers/superio/Makefile b/drivers/superio/Makefile
> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Makefile	2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,11 @@
> +#
> +# Makefile for the SuperIO subsystem.
> +#
> 
> Superflous.
> 
> +
> +obj-$(CONFIG_SC_SUPERIO)	+= superio.o
> +obj-$(CONFIG_SC_GPIO)		+= sc_gpio.o
> +obj-$(CONFIG_SC_ACB)		+= sc_acb.o
> +obj-$(CONFIG_SC_PC8736X)	+= pc8736x.o
> +obj-$(CONFIG_SC_SCX200)		+= scx200.o
> +
> +superio-objs		:= sc.o chain.o sc_conn.o
> 
> please use superio-y += so new conditional objects can be added more easily.

They must be added in the same file and line to allow easy control.
It is not directory like char/.

> diff -Nru a/drivers/superio/chain.c b/drivers/superio/chain.c
> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/chain.c	2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,52 @@
> +/*
> + * 	chain.c
> 
> superfluos, the file name is obvious.  (Dito for all other files)
> 
> + * 
> + * 2004 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> + * All rights reserved.
> + * 
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + */
> +
> +#include <asm/atomic.h>
> +#include <asm/types.h>
> +
> +#include <linux/list.h>
> +#include <linux/slab.h>
> 
> always include <asm/*> after <linux/*> headers.  Please use <linux/types.h>
> istead of <asm/types.h> always.
> 
> (comment applies to later files aswell)

Ok.

> +#include "chain.h"
> +
> +struct dev_chain *chain_alloc(void *ptr)
> +{
> +	struct dev_chain *ch;
> +
> +	ch = kmalloc(sizeof(struct dev_chain), GFP_ATOMIC);
> +	if (!ch) {
> +		printk(KERN_ERR "Failed to allocate new chain for %p.\n", ptr);
> +		return NULL;
> +	}
> +
> +	memset(ch, 0, sizeof(struct dev_chain));
> +
> +	ch->ptr = ptr;
> +
> +	return ch;
> +}
> +
> +void chain_free(struct dev_chain *ch)
> +{
> +	memset(ch, 0, sizeof(struct dev_chain));
> +	kfree(ch);
> 
> The memset completely defeats slab redzoning to catch bugs, don't
> do that.

What? Does following code also kills redzoning?

int *a;
a = kmalloc();
if (a)
{
	memset(a, 0, sizeof(*a));
	kfree(a);
}

Consider size of the dev_chain structure...

> Also what's the reason you can't simply put the list_head into struct
> logical_dev?

Because it is not just list_head, but special structure used for special
pointer manipulations,
which you are obviously saw in sc.c 

> +static void pc8736x_fini(void)
> +{
> +	sc_del_sc_dev(&pc8736x_dev);
> +
> +	while (atomic_read(&pc8736x_dev.refcnt)) {
> +		printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> +				pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> +		
> +		set_current_state(TASK_INTERRUPTIBLE);
> +		schedule_timeout(HZ);
> +			
> +		if (current->flags & PF_FREEZE)
> +			refrigerator(PF_FREEZE);
> +
> +		if (signal_pending(current))
> +			flush_signals(current);
> +	}
> +}
> 
> And who gurantess this won't deadlock?  Please use a dynamically allocated
> driver model device and it's refcounting, thanks.

Sigh.

Christoph, please read the code before doing such comments.
I very respect your review and opinion, but only until you respect
others.

> +int sc_add_sc_dev(struct sc_dev *__sdev)
> 
> btw, what's the reason you use those ugly __ names for local variables all over?
> 
> +	while (atomic_read(&__sdev->refcnt)) {
> +		printk(KERN_INFO "Waiting SuperIO chip %s to become free: refcnt=%d.\n",
> +		       __sdev->name, atomic_read(&__sdev->refcnt));
> +		set_current_state(TASK_UNINTERRUPTIBLE);
> +		schedule_timeout(HZ);
> +			
> +		if (current->flags & PF_FREEZE)
> +			refrigerator(PF_FREEZE);
> +
> +		if (signal_pending(current))
> +			flush_signals(current);
> +	}
> +}
> 
> Again as above.
> 
> +static void sc_deactivate_logical(struct sc_dev *dev, struct logical_dev *ldev)
> +{
> +	printk(KERN_INFO "Deactivating logical device %s in SuperIO chip %s... ",
> +	       ldev->name, dev->name);
> +	
> +	if (ldev->irq)
> +	{
> +		free_irq(ldev->irq, ldev);
> +		ldev->irq = 0;
> +	}
> 
> CodingStyle: if (ldev->irq) {  (also in various other places)

Yep.

> +static int __devinit sc_init(void)
> +{
> +	printk(KERN_INFO "SuperIO driver is starting...\n");
> +
> +	return sc_register_callback();
> +}
> +
> +static void __devexit sc_fini(void)
> +{
> +	sc_unregister_callback();
> +	printk(KERN_INFO "SuperIO driver finished.\n");
> +}
> 
> quite noise.  Please only print messages when you find an actual
> device and not on unloading at all.
> 
> +	INIT_LIST_HEAD(&ldev_acb.ldev_entry);
> +	spin_lock_init(&ldev_acb.lock);
> 
> these two can be initialized at compile time.

Ok.

> +#include "../superio/sc.h"
> +#include "../superio/sc_gpio.h"
> 
> just include them normalluy, ok?

Sure.

> +static int scx200_pci_probe(struct pci_dev *pdev,
> +			    const struct pci_device_id *ent)
> +{
> +	private_base = pci_resource_start(pdev, 0);
> +	printk(KERN_INFO "%s: GPIO base 0x%lx.\n", pci_name(pdev), private_base);
> +
> +	if (!request_region
> +	    (private_base, SCx200_GPIO_SIZE, "NatSemi SCx200 GPIO")) {
> +		printk(KERN_ERR "%s: failed to request %d bytes I/O region for GPIOs.\n",
> +		       pci_name(pdev), SCx200_GPIO_SIZE);
> +		return -EBUSY;
> +	}
> +
> +	pci_set_drvdata(pdev, &private_base);
> +	pci_enable_device(pdev);
> 
> pci_enable_device needs to be done first, and it returns and error that
> should be handled.

Yep, it can be a problem, thank you.

> +	pci_unregister_driver(&scx200_pci_driver);
> +	if (private_base)
> +		release_region(private_base, SCx200_GPIO_SIZE);
> 
> this must happen in the ->remove callback.
> 
> diff -Nru a/drivers/superio/scx200.h b/drivers/superio/scx200.h
> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/scx200.h	2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,28 @@
> +/*
> + * 	scx200.h
> + * 
> + * 2004 Copyright (c) Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> + * All rights reserved.
> + * 
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + *
> + */
> +
> +#ifndef __SCX200_H
> +#define __SCX200_H
> +
> +#define SCx200_GPIO_SIZE 	0x2c
> +
> +#endif /* __SCX200_H */
> 
> Yeah, right - a 30 line header for a single define that's used in a
> single source file..

Christoph, do you know what SuperIO is?
I doubt...

It is a small chip, which can include various number of devices.
SuperIO currently supports only GPIO and ACB, so this header only
includes
one define. I do not have hardware(sc1100 based for example) that
"exports"
other devices and which can be accessed from the outside of the board, 
so I did not add other defines.

But specially for you I can remove this file, will it satisfy you?

> Also your locking is broken.  sdev_lock sometimes nests outside
> sdev->lock and sometimes inside.  Similarly dev->chain_lock nests
> inside dev->lock sometimes and sometimes outside.  You really need
> a locking hiearchy document and the lockign should probably be
> simplified a lot.

It is almost the same like after hand waving say that there is a wind.

Each lock protect it's own data, sometimes it happens when other data is
locked, 
sometimes not. Yes, probably interrupt handling can race, it requires
more review,
I will take a look.

Below is part of the announce in lm_sensors@ which probably will throw
light on your
claims.
************
Main goal was to be able to link any registered SuperIO chip with any
number of registered logical devices. Next step is to add ability to
communicate with SuperIO subsystem from userspace.
External kernel modules may access to logical devices using
sc_{get,put}_ldev() and in similar way to SuperIO chip drivers -
sc_{get,put}_sdev().

Driver writers shoud use sc_{add,del}_logical_dev() and
sc_{add,del}_sc_dev() to accordingly add/remove logical devices and
SuperIO chip drivers.

Any SuperIO chip driver must provite at least 2 functions:
->probe() and ->activate_one().
The former is called with different HW addresses and should return 0 if
device was found there or negative error value.
The latter is called each time new logical device being added with
pointer to it's logical device structure. It should return 0 if logical
device was found to be active or negative error value.

Any logical device must provide 4 functions:
->activate() - it is used to activate logical device.
->read()/write() - what do you think, it is used to read and write
from/to logical device registers.
->control() - it is used to control access to logical device. Actually
it is private combination of ->read()/write() functions but is providede
for convenience.
********************

Resume:
Cristoph, you rudely try to show that this code is badly broken.
It is not.
It was tested as opposed to your claims, and works as expected.

To be more productive please next time be polite and respect others, 
or you will be just ignored no matter how strong your knowledges are.

Talk is cheap, show me the code, that is broken, and I will fix it.

Thank you.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 14:11       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-25 14:23         ` Christoph Hellwig
  2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-25 14:23 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Andrew Morton, greg, linux-kernel

> > +obj-$(CONFIG_SC_SUPERIO)	+= superio.o
> > +obj-$(CONFIG_SC_GPIO)		+= sc_gpio.o
> > +obj-$(CONFIG_SC_ACB)		+= sc_acb.o
> > +obj-$(CONFIG_SC_PC8736X)	+= pc8736x.o
> > +obj-$(CONFIG_SC_SCX200)		+= scx200.o
> > +
> > +superio-objs		:= sc.o chain.o sc_conn.o
> > 
> > please use superio-y += so new conditional objects can be added more easily.
> 
> They must be added in the same file and line to allow easy control.
> It is not directory like char/.

Huh?

What I mean is you should write

superio-y		+= sc.o chain.o sc_conn.o

this allows adding things like

superio-$(CONFIG_FOO)	+= sc_foo.o

and is generally the canonical form since 2.6

> > +void chain_free(struct dev_chain *ch)
> > +{
> > +	memset(ch, 0, sizeof(struct dev_chain));
> > +	kfree(ch);
> > 
> > The memset completely defeats slab redzoning to catch bugs, don't
> > do that.
> 
> What? Does following code also kills redzoning?
> 
> int *a;
> a = kmalloc();
> if (a)
> {
> 	memset(a, 0, sizeof(*a));
> 	kfree(a);
> }
> 
> Consider size of the dev_chain structure...

Sorry, didn't mean redzoning but poisoning in general, little
brainfart on my side.  The slab code can set freed objects to
known patters so use after frees can be debugged easily, and
by zeroing a structure before freeing we lose that.

> > Also what's the reason you can't simply put the list_head into struct
> > logical_dev?
> 
> Because it is not just list_head, but special structure used for special
> pointer manipulations,
> which you are obviously saw in sc.c 

No, I didn't see it.  I see that the void pointer ptr in struct dev_chain
always points to a struct sc_dev *, and I see we never change that
pointer at run time.  I might have missed something obvious, so maybe
you could point me to it (or even better add a comment describing it)

> 
> > +static void pc8736x_fini(void)
> > +{
> > +	sc_del_sc_dev(&pc8736x_dev);
> > +
> > +	while (atomic_read(&pc8736x_dev.refcnt)) {
> > +		printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > +				pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > +		
> > +		set_current_state(TASK_INTERRUPTIBLE);
> > +		schedule_timeout(HZ);
> > +			
> > +		if (current->flags & PF_FREEZE)
> > +			refrigerator(PF_FREEZE);
> > +
> > +		if (signal_pending(current))
> > +			flush_signals(current);
> > +	}
> > +}
> > 
> > And who gurantess this won't deadlock?  Please use a dynamically allocated
> > driver model device and it's refcounting, thanks.
> 
> Sigh.
> 
> Christoph, please read the code before doing such comments.
> I very respect your review and opinion, but only until you respect
> others.

The code above pretty much means you can keep rmmod stalled forever.

Also it seems to be the only code intree doing refrigerator() on anything
but kernel thread.  While I can't comment on swsusp internals it surely
looks buggy to me.
 
> > +#ifndef __SCX200_H
> > +#define __SCX200_H
> > +
> > +#define SCx200_GPIO_SIZE 	0x2c
> > +
> > +#endif /* __SCX200_H */
> > 
> > Yeah, right - a 30 line header for a single define that's used in a
> > single source file..
> 
> Christoph, do you know what SuperIO is?
> I doubt...
> 
> It is a small chip, which can include various number of devices.
> SuperIO currently supports only GPIO and ACB, so this header only
> includes
> one define. I do not have hardware(sc1100 based for example) that
> "exports"
> other devices and which can be accessed from the outside of the board, 
> so I did not add other defines.
> 
> But specially for you I can remove this file, will it satisfy you?

I've just told you it looks extremly silly, you need to decide on your
own whether it's worthwile.

> > Also your locking is broken.  sdev_lock sometimes nests outside
> > sdev->lock and sometimes inside.  Similarly dev->chain_lock nests
> > inside dev->lock sometimes and sometimes outside.  You really need
> > a locking hiearchy document and the lockign should probably be
> > simplified a lot.
> 
> It is almost the same like after hand waving say that there is a wind.
> 
> Each lock protect it's own data, sometimes it happens when other data is
> locked, 
> sometimes not. Yes, probably interrupt handling can race, it requires
> more review,
> I will take a look.

The thing I mention is called lock order reversal, which means a deadlock
in most cases.  I don't have the time to actual walk through all codepathes
to tell you whether it can really happen and where, but it's a really
big warning sign.

> Resume:
> Cristoph, you rudely try to show that this code is badly broken.
> It is not.
> It was tested as opposed to your claims, and works as expected.

I've seen tons of code that "works as expected" but still is buggy.
That's why code needs to be both tested (with a workload as
expected and other stress testing that shows it handles loads _not_
expected) and reviewed for errors that don't happen with a normal
load or design problems.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 14:23         ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-25 15:24           ` Evgeniy Polyakov
  2005-01-25 15:34             ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
                               ` (3 more replies)
  0 siblings, 4 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 15:24 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, greg, linux-kernel

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

On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > +obj-$(CONFIG_SC_SUPERIO)	+= superio.o
> > > +obj-$(CONFIG_SC_GPIO)		+= sc_gpio.o
> > > +obj-$(CONFIG_SC_ACB)		+= sc_acb.o
> > > +obj-$(CONFIG_SC_PC8736X)	+= pc8736x.o
> > > +obj-$(CONFIG_SC_SCX200)		+= scx200.o
> > > +
> > > +superio-objs		:= sc.o chain.o sc_conn.o
> > > 
> > > please use superio-y += so new conditional objects can be added more easily.
> > 
> > They must be added in the same file and line to allow easy control.
> > It is not directory like char/.
> 
> Huh?
> 
> What I mean is you should write
> 
> superio-y		+= sc.o chain.o sc_conn.o
> 
> this allows adding things like
> 
> superio-$(CONFIG_FOO)	+= sc_foo.o
> 
> and is generally the canonical form since 2.6

Yes, I understand you, but this is the case when it is not supposed to
have external dependent features, they are already inside :)
But who knows.

I think it is better to change.

> > > +void chain_free(struct dev_chain *ch)
> > > +{
> > > +	memset(ch, 0, sizeof(struct dev_chain));
> > > +	kfree(ch);
> > > 
> > > The memset completely defeats slab redzoning to catch bugs, don't
> > > do that.
> > 
> > What? Does following code also kills redzoning?
> > 
> > int *a;
> > a = kmalloc();
> > if (a)
> > {
> > 	memset(a, 0, sizeof(*a));
> > 	kfree(a);
> > }
> > 
> > Consider size of the dev_chain structure...
> 
> Sorry, didn't mean redzoning but poisoning in general, little
> brainfart on my side.  The slab code can set freed objects to
> known patters so use after frees can be debugged easily, and
> by zeroing a structure before freeing we lose that.

Zeroing can be found easily - the whole structure is NULL pointer, 
and will always panic if accessed(from running superio code), 
but redzoning is only happen on borders,
and can catch writes over the boards, which is rarely in this case.

> > > Also what's the reason you can't simply put the list_head into struct
> > > logical_dev?
> > 
> > Because it is not just list_head, but special structure used for special
> > pointer manipulations,
> > which you are obviously saw in sc.c 
> 
> No, I didn't see it.  I see that the void pointer ptr in struct dev_chain
> always points to a struct sc_dev *, and I see we never change that
> pointer at run time.  I might have missed something obvious, so maybe
> you could point me to it (or even better add a comment describing it)

Each superio chip is registered with superio core without any devices.
Each logical device is registered with superio core without any superio
chip.
Then core checks if some chip is found in some superio device, and
links 
it to appropriate device.
So if board has several superio chips(like soekris board) and several
logical devices in it, then we only have 2 superio small drivers, and
several 
logical device drivers, but not
number_of_superio_chips*number_of_logical_devices drivers.
Without dev_chain structure each logical device should have a separate
list of
superio chips that owns it.
Above chain structure is a glue between superio core, logical devices
and superio chips.
It is especially usefull in case of logical device cloning, when chip
does not follow
the standart and place it somewhere else, but to allow access to it
superio core
"clones" logical device and link them instead of the standart one.

> > 
> > > +static void pc8736x_fini(void)
> > > +{
> > > +	sc_del_sc_dev(&pc8736x_dev);
> > > +
> > > +	while (atomic_read(&pc8736x_dev.refcnt)) {
> > > +		printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > +				pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > +		
> > > +		set_current_state(TASK_INTERRUPTIBLE);
> > > +		schedule_timeout(HZ);
> > > +			
> > > +		if (current->flags & PF_FREEZE)
> > > +			refrigerator(PF_FREEZE);
> > > +
> > > +		if (signal_pending(current))
> > > +			flush_signals(current);
> > > +	}
> > > +}
> > > 
> > > And who gurantess this won't deadlock?  Please use a dynamically allocated
> > > driver model device and it's refcounting, thanks.
> > 
> > Sigh.
> > 
> > Christoph, please read the code before doing such comments.
> > I very respect your review and opinion, but only until you respect
> > others.
> 
> The code above pretty much means you can keep rmmod stalled forever.

Yes, and it is better than removing module whose structures are in use.
SuperIO core is asynchronous in it's nature, one can use logical device 
through superio core and remove it's module on other CPU, above loop
will
wait untill all reference counters are dropped.

Access to devices can be done not through ioctl or such mechanism which 
"locks" the module owner.

It is better than module_get() since with the latter variant we may end
up
not removing device at all.

> Also it seems to be the only code intree doing refrigerator() on anything
> but kernel thread.  While I can't comment on swsusp internals it surely
> looks buggy to me.
>  
> > > +#ifndef __SCX200_H
> > > +#define __SCX200_H
> > > +
> > > +#define SCx200_GPIO_SIZE 	0x2c
> > > +
> > > +#endif /* __SCX200_H */
> > > 
> > > Yeah, right - a 30 line header for a single define that's used in a
> > > single source file..
> > 
> > Christoph, do you know what SuperIO is?
> > I doubt...
> > 
> > It is a small chip, which can include various number of devices.
> > SuperIO currently supports only GPIO and ACB, so this header only
> > includes
> > one define. I do not have hardware(sc1100 based for example) that
> > "exports"
> > other devices and which can be accessed from the outside of the board, 
> > so I did not add other defines.
> > 
> > But specially for you I can remove this file, will it satisfy you?
> 
> I've just told you it looks extremly silly, you need to decide on your
> own whether it's worthwile.
> 
> > > Also your locking is broken.  sdev_lock sometimes nests outside
> > > sdev->lock and sometimes inside.  Similarly dev->chain_lock nests
> > > inside dev->lock sometimes and sometimes outside.  You really need
> > > a locking hiearchy document and the lockign should probably be
> > > simplified a lot.
> > 
> > It is almost the same like after hand waving say that there is a wind.
> > 
> > Each lock protect it's own data, sometimes it happens when other data is
> > locked, 
> > sometimes not. Yes, probably interrupt handling can race, it requires
> > more review,
> > I will take a look.
> 
> The thing I mention is called lock order reversal, which means a deadlock
> in most cases.  I don't have the time to actual walk through all codepathes
> to tell you whether it can really happen and where, but it's a really
> big warning sign.

No, it is not called lock order reversal.

There are no places like
lock a
lock b
unlock a
unlock b

and if they are, then I'm completely wrong.

What you see is only following:

place 1:
lock a
lock b
unlock b
lock c
unlock c
unlock a

place 2:
lock b
lock a
unlock a
lock c
unlock c
unlock b


It is done since manipulation with the chain pointer can be done from
logical device structure and from superio chip structure, and this
operations are absolutely the same in nature.

> > Resume:
> > Cristoph, you rudely try to show that this code is badly broken.
> > It is not.
> > It was tested as opposed to your claims, and works as expected.
> 
> I've seen tons of code that "works as expected" but still is buggy.
> That's why code needs to be both tested (with a workload as
> expected and other stress testing that shows it handles loads _not_
> expected) and reviewed for errors that don't happen with a normal
> load or design problems.

Yes, you are right, of course.
That is why we write code, test and discuss(but not knock against each
other) it.

I will send patch to address your comments soon, thank you.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-25 15:34             ` Bartlomiej Zolnierkiewicz
  2005-01-25 16:04               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 15:36             ` 2.6.11-rc2-mm1 Paulo Marques
                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 152+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2005-01-25 15:34 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > Also your locking is broken.  sdev_lock sometimes nests outside
> > > > sdev->lock and sometimes inside.  Similarly dev->chain_lock nests
> > > > inside dev->lock sometimes and sometimes outside.  You really need
> > > > a locking hiearchy document and the lockign should probably be
> > > > simplified a lot.
> > >
> > > It is almost the same like after hand waving say that there is a wind.
> > >
> > > Each lock protect it's own data, sometimes it happens when other data is
> > > locked,
> > > sometimes not. Yes, probably interrupt handling can race, it requires
> > > more review,
> > > I will take a look.
> >
> > The thing I mention is called lock order reversal, which means a deadlock
> > in most cases.  I don't have the time to actual walk through all codepathes
> > to tell you whether it can really happen and where, but it's a really
> > big warning sign.
> 
> No, it is not called lock order reversal.
> 
> There are no places like
> lock a
> lock b
> unlock a
> unlock b
> 
> and if they are, then I'm completely wrong.
> 
> What you see is only following:
> 
> place 1:
> lock a
> lock b
> unlock b
> lock c
> unlock c
> unlock a
> 
> place 2:
> lock b
> lock a
> unlock a
> lock c
> unlock c
> unlock b

Ugh, now think about that:

CPU0     CPU1
place1:   place2:
lock a      lock b
< guess what happens here :-) >
lock b      lock a
...             ...

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 15:34             ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
@ 2005-01-25 15:36             ` Paulo Marques
  2005-01-25 21:08               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 16:11             ` 2.6.11-rc2-mm1 Dmitry Torokhov
  2005-01-25 22:42             ` 2.6.11-rc2-mm1 Christoph Hellwig
  3 siblings, 1 reply; 152+ messages in thread
From: Paulo Marques @ 2005-01-25 15:36 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

Evgeniy Polyakov wrote:
> [...]
> No, it is not called lock order reversal.
> 
> There are no places like
> lock a
> lock b
> unlock a
> unlock b

This would be perfectly fine. The order of unlocking doesn't really 
matter. It is the actual locking that must be carried out on the same 
order everywhere to guarantee that there are no deadlocks.

> and if they are, then I'm completely wrong.
> 
> What you see is only following:
> 
> place 1:
> lock a
> lock b
> unlock b
> lock c
> unlock c
> unlock a
> 
> place 2:
> lock b
> lock a
> unlock a
> lock c
> unlock c
> unlock b

I haven't look at the code yet, but this is a deadlock waiting to 
happen. "place 1" gets "lock a", then is interrupted and "place 2" gets 
"lock b". "place 2" waits forever for "lock a" and "place 1" waits 
forever for "lock b". Deadlock.

-- 
Paulo Marques - www.grupopie.com

"A journey of a thousand miles begins with a single step."
Lao-tzu, The Way of Lao-tzu


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:34             ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
@ 2005-01-25 16:04               ` Evgeniy Polyakov
  2005-01-25 18:21                 ` 2.6.11-rc2-mm1 Jörn Engel
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 16:04 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:

> > There are no places like
> > lock a
> > lock b
> > unlock a
> > unlock b
> > 
> > and if they are, then I'm completely wrong.
> > 
> > What you see is only following:
> > 
> > place 1:
> > lock a
> > lock b
> > unlock b
> > lock c
> > unlock c
> > unlock a
> > 
> > place 2:
> > lock b
> > lock a
> > unlock a
> > lock c
> > unlock c
> > unlock b
> 
> Ugh, now think about that:
> 
> CPU0     CPU1
> place1:   place2:
> lock a      lock b
> < guess what happens here :-) >
> lock b      lock a
> ...             ...

:) he-he, such place are in add and remove routings, and they can not be
run simultaneously
in different CPUs.

And in other places they should go through the same lock(sdev or chain):
like 
lock sdev_lock
lock chain
unclok chain 
lock logic
unlock logic
unlock sdev_lock


lock sdev_lock
lock logic
unlock logic
lock chain
unclok chain 
unlock sdev_lock

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 15:34             ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
  2005-01-25 15:36             ` 2.6.11-rc2-mm1 Paulo Marques
@ 2005-01-25 16:11             ` Dmitry Torokhov
  2005-01-25 21:14               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  2005-01-25 22:42             ` 2.6.11-rc2-mm1 Christoph Hellwig
  3 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-25 16:11 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > +static void pc8736x_fini(void)
> > > > +{
> > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > +
> > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > +         printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > +                         pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > +
> > > > +         set_current_state(TASK_INTERRUPTIBLE);
> > > > +         schedule_timeout(HZ);
> > > > +
> > > > +         if (current->flags & PF_FREEZE)
> > > > +                 refrigerator(PF_FREEZE);
> > > > +
> > > > +         if (signal_pending(current))
> > > > +                 flush_signals(current);
> > > > + }
> > > > +}
> > > >
> > > > And who gurantess this won't deadlock?  Please use a dynamically allocated
> > > > driver model device and it's refcounting, thanks.
> > >
> > > Sigh.
> > >
> > > Christoph, please read the code before doing such comments.
> > > I very respect your review and opinion, but only until you respect
> > > others.
> >
> > The code above pretty much means you can keep rmmod stalled forever.
> 
> Yes, and it is better than removing module whose structures are in use.
> SuperIO core is asynchronous in it's nature, one can use logical device
> through superio core and remove it's module on other CPU, above loop
> will wait untill all reference counters are dropped.

I have a slightly different concern - the superio is a completely new
subsystem and it should be integtrated with the driver model
("superio" bus?). Right now it looks like it is reimplementing most of
the abstractions (device lists, driver lists, matching, probing).
Moving to driver model significatntly affects lifetime rules for the
objects, etc. etc. and will definitely not allow code such as above.

It would be nice it we get things right from the start.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 16:04               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-25 18:21                 ` Jörn Engel
  2005-01-25 21:17                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Jörn Engel @ 2005-01-25 18:21 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Bartlomiej Zolnierkiewicz, Christoph Hellwig, Andrew Morton,
	greg, linux-kernel

On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> 
> > Ugh, now think about that:
> > 
> > CPU0     CPU1
> > place1:   place2:
> > lock a      lock b
> > < guess what happens here :-) >
> > lock b      lock a
> > ...             ...
> 
> :) he-he, such place are in add and remove routings, and they can not be
> run simultaneously
> in different CPUs.

Makes my toenails curl.  Something fun I might write someday is a
statical (dead-)lock checker.  The design is very simple:

o Annotate code with the lock that could be taken.
o Whenever getting a lock B, write down something like "A->B" for
  every lock A we already have.
o Create a graph from the locking hierarchy obtained above.
o Look for cycles.

A cycle-free graph means that the code is deadlock-free.  In the
above, the graph surely has cycles.  You could argue that the checker
should be smarter, but then again - why should it?  Is there a
compelling reason why locking schemes as outlined above actually make
the code better?

Jörn

-- 
It does not matter how slowly you go, so long as you do not stop.
-- Confucius

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25  1:01     ` 2.6.11-rc2-mm1 Brice Goglin
  2005-01-25  1:30       ` 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND) Len Brown
@ 2005-01-25 18:41       ` Pavel Machek
  2005-01-25 19:10         ` 2.6.11-rc2-mm1 Espen Fjellvær Olsen
  1 sibling, 1 reply; 152+ messages in thread
From: Pavel Machek @ 2005-01-25 18:41 UTC (permalink / raw)
  To: Brice.Goglin; +Cc: Andrew Morton, linux-kernel

Hi!

> Andrew Morton a écrit :
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> >
> >
> >- Lots of updates and fixes all over the place.
> >
> >- On my test box there is no flashing cursor on the vga console.  Known 
> >bug,
> >  please don't report it.
> >
> >  Binary searching shows that the bug was introduced by
> >  cleanup-vc-array-access.patch but that patch is, unfortunately,
> > huge.

Heh, on my system, I get no cursor, and no letters, either (this is
vga text console). I *can* see the backgrounds, for example if I run
aumix I see colored blocks... Framebuffer does not seem to work,
either.

Letters are present for a while during boot; not sure what makes them
go away.

> ACPI does not work anymore on my Compaq Evo N600c
> (no thermal zone, no fan, no battery, ...).
> It works great on Linus' 2.6.11-rc2, and (from what I remember)
> it was working on the last -mm releases I tried.

I'd test on N620c, but it is rather hard without video :-(.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25  6:02           ` Greg KH
  2005-01-25  7:11             ` Christoph Hellwig
@ 2005-01-25 18:59             ` Jean Delvare
  2005-01-25 21:39               ` Evgeniy Polyakov
  1 sibling, 1 reply; 152+ messages in thread
From: Jean Delvare @ 2005-01-25 18:59 UTC (permalink / raw)
  To: Greg KH
  Cc: Christoph Hellwig, Adrian Bunk, Andrew Morton, Evgeniy Polyakov, LKML

Hi all,

> As previously mentioned, these patches have had that, on the sensors
> mailing list.  Lots of review and comments went into them there, and
> the code was reworked quite a lot based on it.

That's right, I did actually review Evgeniy's code some times ago, as
can be seen here:
http://archives.andrew.net.au/lm-sensors/msg27817.html

I might however add the following:

1* This was 5 months ago. I'd expect Evgeniy's code to have
significantly evolved since, so an additional review now would certainly
be welcome.

2* I only reviewed the superio code. The acb part is completely new so I
obviously couldn't comment on it back then, and I skipped the gpio part
because I admittedly have no particular interest in this part.

3* Some of my objections have been ignored by Evgeniy. Among others, the
choice of "sc" as a prefix for the superio stuff is definitely poor and
has to be changed.

http://archives.andrew.net.au/lm-sensors/msg27847.html

I don't think that getting the whole stuff (superio, acb and gpio)
merged at once is a good idea. Preferably we would merge superio alone
first, then update the drivers that are already in the kernel and could
make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors
fame, come to mind). This would help ensure that Evgeniy's interface
choices were correct, and would additionally be a very good example of
how this interface must be used. Then, and only then IMVHO, should the
gpio and acb stuff be merged.

Before all this happens, I really would like Evgeniy to present an
overall plan of his current superio implementation. Last time we
discussed about this, we obviously had different views on the interface
level that should be proposed by the superio core, as well as how
chip-specific values should be handled (or, according to me, mostly not
handled). 

Please note that I am certainly not the most qualified of us all to
review this code. What I can do is check whether I will be able to use
the new superio interface in the sensor chip drivers I mentioned above,
and that's about it. I am not familiar enough with kernel core
architectures to decide whether Evgeniy's approach is correct or not. I
am willing to help, but I can do so only within my own current skills.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 18:41       ` 2.6.11-rc2-mm1 Pavel Machek
@ 2005-01-25 19:10         ` Espen Fjellvær Olsen
  0 siblings, 0 replies; 152+ messages in thread
From: Espen Fjellvær Olsen @ 2005-01-25 19:10 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Brice.Goglin, Andrew Morton, linux-kernel

On Tue, 25 Jan 2005 19:41:39 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> Heh, on my system, I get no cursor, and no letters, either (this is
> vga text console). I *can* see the backgrounds, for example if I run
> aumix I see colored blocks... Framebuffer does not seem to work,
> either.
> 
> Letters are present for a while during boot; not sure what makes them
> go away.

I get the same thing, text disappairs after a second or something like
that. Framebuffer has no effect.

-- 
Mvh / Best regards
Espen Fjellvær Olsen
espenfjo@gmail.com
Norway

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (18 preceding siblings ...)
  2005-01-25 12:53     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-25 19:12     ` Marcos D. Marado Torres
  2005-01-25 23:07       ` 2.6.11-rc2-mm1 Barry K. Nathan
  2005-01-26  2:40     ` 2.6.11-rc2-mm1 William Lee Irwin III
                       ` (2 subsequent siblings)
  22 siblings, 1 reply; 152+ messages in thread
From: Marcos D. Marado Torres @ 2005-01-25 19:12 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 24 Jan 2005, Andrew Morton wrote:

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/

This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still happens.

Marcos Marado

- -- 
/* *************************************************************** */
    Marcos Daniel Marado Torres	     AKA	Mind Booster Noori
    http://student.dei.uc.pt/~marado   -	  marado@student.dei.uc.pt
    () Join the ASCII ribbon campaign against html email, Microsoft
    /\ attachments and Software patents.   They endanger the World.
    Sign a petition against patents:  http://petition.eurolinux.org
/* *************************************************************** */
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFB9po4mNlq8m+oD34RAuoFAKDWkLvIwIdpf/6NBQWdtML41LLXcQCcDSWq
yiRWlDpUaJrfrZR4iMKHcGY=
=nv2D
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 12:53     ` 2.6.11-rc2-mm1 Christoph Hellwig
  2005-01-25 14:11       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-25 19:35       ` Pavel Machek
  1 sibling, 0 replies; 152+ messages in thread
From: Pavel Machek @ 2005-01-25 19:35 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, johnpol, greg, linux-kernel

Hi!

> Review of the superio subsystem sneaked in through bk-i2c.patch:
> 
> 
> diff -Nru a/drivers/superio/Kconfig b/drivers/superio/Kconfig
> --- /dev/null	Wed Dec 31 16:00:00 196900
> +++ b/drivers/superio/Kconfig	2005-01-23 22:34:15 -08:00
> @@ -0,0 +1,56 @@
> +menu "SuperIO subsystem support"
> +
> +config SC_SUPERIO
> +	tristate "SuperIO subsystem support"
> +	depends on CONNECTOR
> +	help
> +	  SuperIO subsystem support.
> +	
> +	  This support is also available as a module.  If so, the module
> +          will be called superio.ko.
> 
> This doesn't mention what "SuperIO" is at all.  Also please skip the .ko
> postfix for the module name as the intree Kconfigs do.  The boilerplate has
> changed to:
> 
>   To compile this driver as a module, choose M here: the
>   module will be called <foo>.

Could we kill this boilerplate? Just explain modules in CONFIG_MODULE
or something like that. Or making module name mandatory parameter for
tristates, or something like that...

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 21:31           ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-25 19:38             ` Dave Jones
  2005-01-25 19:58               ` 2.6.11-rc2-mm1 Brice Goglin
  0 siblings, 1 reply; 152+ messages in thread
From: Dave Jones @ 2005-01-25 19:38 UTC (permalink / raw)
  To: Brice.Goglin; +Cc: Andrew Morton, linux-kernel

On Mon, Jan 24, 2005 at 10:31:53PM +0100, Brice Goglin wrote:
 > Dave Jones a écrit :
 > >Here's the most obvious bug fixed. There still seems to be
 > >something wrong however. It only successfully boots 50% of the
 > >time for me, (it reboots when starting X otherwise), and when
 > >it does boot, I get a flood of ...
 > >Warning: kfree_skb on hard IRQ cf7b5800
 > >Warning: kfree_skb on hard IRQ cf7b5800
 > >Warning: kfree_skb on hard IRQ cf7b5800
 > >
 > >I think there may be some stupid memory corruptor bug in there still.
 > 
 > Thanks, your patch makes X work again with DRI.
 > Actually, it successfully booted 100% of the time here.
 > I tried 6 or 7 times without seeing any problem like yours.
 > Let me know if you want me to try something special.

It's quite remarkable that it works at all.
This is needed too on top of -mm1.

		Dave

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/01/25 14:27:39-05:00 davej@redhat.com 
#   [AGPGART] Silly thinko in reserve bit masking.
#   
#   Stupid inversion meant we passed '0' to userspace, and madness
#   ensued resulting in very funky visuals.
#   
#   Signed-off-by: Dave Jones <davej@redhat.com>
# 
diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
+++ b/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
@@ -324,9 +324,9 @@
 	info->chipset = agp_bridge->type;
 	info->device = agp_bridge->dev;
 	if (check_bridge_mode(agp_bridge->dev))
-		info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
+		info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
 	else
-		info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
+		info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
 	info->aper_base = agp_bridge->gart_bus_addr;
 	info->aper_size = agp_return_size();
 	info->max_memory = agp_bridge->max_memory_agp;



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 19:38             ` 2.6.11-rc2-mm1 Dave Jones
@ 2005-01-25 19:58               ` Brice Goglin
  2005-01-25 20:29                 ` 2.6.11-rc2-mm1 Dave Jones
  0 siblings, 1 reply; 152+ messages in thread
From: Brice Goglin @ 2005-01-25 19:58 UTC (permalink / raw)
  To: Dave Jones; +Cc: Andrew Morton, linux-kernel

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

Dave Jones a écrit :
> This is needed too on top of -mm1.
> 
> diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
> --- a/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
> +++ b/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
> @@ -324,9 +324,9 @@
>  	info->chipset = agp_bridge->type;
>  	info->device = agp_bridge->dev;
>  	if (check_bridge_mode(agp_bridge->dev))
> -		info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
> +		info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
>  	else
> -		info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
> +		info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
>  	info->aper_base = agp_bridge->gart_bus_addr;
>  	info->aper_size = agp_return_size();
>  	info->max_memory = agp_bridge->max_memory_agp;
> 

Maybe that's not important, but on top of my -rc2-mm1, your patch looks like the
one I attached to this mail.

Regards,
Brice

[-- Attachment #2: fix-agp-mode.patch --]
[-- Type: text/x-patch, Size: 629 bytes --]

diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
--- a/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
+++ b/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
@@ -328,9 +328,9 @@
 	info->chipset = SUPPORTED;
 	info->device = bridge->dev;
 	if (check_bridge_mode(bridge->dev))
-		info->mode = bridge->mode & AGP3_RESERVED_MASK;
+		info->mode = bridge->mode & ~AGP3_RESERVED_MASK;
 	else
-		info->mode = bridge->mode & AGP2_RESERVED_MASK;
+		info->mode = bridge->mode & ~AGP2_RESERVED_MASK;
 	info->mode = bridge->mode;
 	info->aper_base = bridge->gart_bus_addr;
 	info->aper_size = agp_return_size();

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 19:58               ` 2.6.11-rc2-mm1 Brice Goglin
@ 2005-01-25 20:29                 ` Dave Jones
  0 siblings, 0 replies; 152+ messages in thread
From: Dave Jones @ 2005-01-25 20:29 UTC (permalink / raw)
  To: Brice.Goglin; +Cc: Andrew Morton, linux-kernel

On Tue, Jan 25, 2005 at 08:58:31PM +0100, Brice Goglin wrote:
 > Dave Jones a écrit :
 > >This is needed too on top of -mm1.
 > >
 > >diff -Nru a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
 > >--- a/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
 > >+++ b/drivers/char/agp/generic.c	2005-01-25 14:34:24 -05:00
 > >@@ -324,9 +324,9 @@
 > > 	info->chipset = agp_bridge->type;
 > > 	info->device = agp_bridge->dev;
 > > 	if (check_bridge_mode(agp_bridge->dev))
 > >-		info->mode = agp_bridge->mode & AGP3_RESERVED_MASK;
 > >+		info->mode = agp_bridge->mode & ~AGP3_RESERVED_MASK;
 > > 	else
 > >-		info->mode = agp_bridge->mode & AGP2_RESERVED_MASK;
 > >+		info->mode = agp_bridge->mode & ~AGP2_RESERVED_MASK;
 > > 	info->aper_base = agp_bridge->gart_bus_addr;
 > > 	info->aper_size = agp_return_size();
 > > 	info->max_memory = agp_bridge->max_memory_agp;
 > >
 > 
 > Maybe that's not important, but on top of my -rc2-mm1, your patch looks 
 > like the one I attached to this mail.

Doh, yes. Your variant is needed with the multi-gart patches that
are in -mm. The one I posted is what I just committed to agpgart-bk

		Dave
 

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:36             ` 2.6.11-rc2-mm1 Paulo Marques
@ 2005-01-25 21:08               ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 21:08 UTC (permalink / raw)
  To: Paulo Marques; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Tue, 25 Jan 2005 15:36:57 +0000
Paulo Marques <pmarques@grupopie.com> wrote:

> Evgeniy Polyakov wrote:
> > [...]
> > No, it is not called lock order reversal.
> > 
> > There are no places like
> > lock a
> > lock b
> > unlock a
> > unlock b
> 
> This would be perfectly fine. The order of unlocking doesn't really 
> matter. It is the actual locking that must be carried out on the same 
> order everywhere to guarantee that there are no deadlocks.

It is bad style, and since unlocking changes the order someone
may pass wrong locking.

> > and if they are, then I'm completely wrong.
> > 
> > What you see is only following:
> > 
> > place 1:
> > lock a
> > lock b
> > unlock b
> > lock c
> > unlock c
> > unlock a
> > 
> > place 2:
> > lock b
> > lock a
> > unlock a
> > lock c
> > unlock c
> > unlock b
> 
> I haven't look at the code yet, but this is a deadlock waiting to 
> happen. "place 1" gets "lock a", then is interrupted and "place 2" gets 
> "lock b". "place 2" waits forever for "lock a" and "place 1" waits 
> forever for "lock b". Deadlock.

As I said, that pathes are mutually exclusive - common pathes are guarded
by one lock always.

> -- 
> Paulo Marques - www.grupopie.com
> 
> "A journey of a thousand miles begins with a single step."
> Lao-tzu, The Way of Lao-tzu


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 16:11             ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-25 21:14               ` Evgeniy Polyakov
  2005-01-26  4:57                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 21:14 UTC (permalink / raw)
  To: dtor_core
  Cc: dmitry.torokhov, Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Tue, 25 Jan 2005 11:11:42 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > > +static void pc8736x_fini(void)
> > > > > +{
> > > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > > +
> > > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > > +         printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > > +                         pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > > +
> > > > > +         set_current_state(TASK_INTERRUPTIBLE);
> > > > > +         schedule_timeout(HZ);
> > > > > +
> > > > > +         if (current->flags & PF_FREEZE)
> > > > > +                 refrigerator(PF_FREEZE);
> > > > > +
> > > > > +         if (signal_pending(current))
> > > > > +                 flush_signals(current);
> > > > > + }
> > > > > +}
> > > > >
> > > > > And who gurantess this won't deadlock?  Please use a dynamically allocated
> > > > > driver model device and it's refcounting, thanks.
> > > >
> > > > Sigh.
> > > >
> > > > Christoph, please read the code before doing such comments.
> > > > I very respect your review and opinion, but only until you respect
> > > > others.
> > >
> > > The code above pretty much means you can keep rmmod stalled forever.
> > 
> > Yes, and it is better than removing module whose structures are in use.
> > SuperIO core is asynchronous in it's nature, one can use logical device
> > through superio core and remove it's module on other CPU, above loop
> > will wait untill all reference counters are dropped.
> 
> I have a slightly different concern - the superio is a completely new
> subsystem and it should be integtrated with the driver model
> ("superio" bus?). Right now it looks like it is reimplementing most of
> the abstractions (device lists, driver lists, matching, probing).
> Moving to driver model significatntly affects lifetime rules for the
> objects, etc. etc. and will definitely not allow code such as above.
> 
> It would be nice it we get things right from the start.

bus model is not good here - we need bus in each logical device and
bus in each superio chip(or at least second case).
Each bus bus have some crosslinking to devices in other buses, 
and each new device
must be checked in each bus and probably added to each device...

It is not like I see it.

Consider folowing example: 
each device from set A belongs to each device from set B.
n <-> n, it is not the case when one bus can handle all features.

That is why I did not use driver model there.
It is specific design feature, which is proven to work.
 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 18:21                 ` 2.6.11-rc2-mm1 Jörn Engel
@ 2005-01-25 21:17                   ` Evgeniy Polyakov
  2005-01-26  2:20                     ` 2.6.11-rc2-mm1 Jörn Engel
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 21:17 UTC (permalink / raw)
  To: J_rn Engel
  Cc: Bartlomiej Zolnierkiewicz, Christoph Hellwig, Andrew Morton,
	greg, linux-kernel

On Tue, 25 Jan 2005 19:21:10 +0100
J_rn Engel <joern@wohnheim.fh-wedel.de> wrote:

> On Tue, 25 January 2005 19:04:47 +0300, Evgeniy Polyakov wrote:
> > On Tue, 2005-01-25 at 16:34 +0100, Bartlomiej Zolnierkiewicz wrote:
> > 
> > > Ugh, now think about that:
> > > 
> > > CPU0     CPU1
> > > place1:   place2:
> > > lock a      lock b
> > > < guess what happens here :-) >
> > > lock b      lock a
> > > ...             ...
> > 
> > :) he-he, such place are in add and remove routings, and they can not be
> > run simultaneously
> > in different CPUs.
> 
> Makes my toenails curl.  Something fun I might write someday is a
> statical (dead-)lock checker.  The design is very simple:
> 
> o Annotate code with the lock that could be taken.
> o Whenever getting a lock B, write down something like "A->B" for
>   every lock A we already have.
> o Create a graph from the locking hierarchy obtained above.
> o Look for cycles.
> 
> A cycle-free graph means that the code is deadlock-free.  In the
> above, the graph surely has cycles.  You could argue that the checker
> should be smarter, but then again - why should it?  Is there a
> compelling reason why locking schemes as outlined above actually make
> the code better?

That will catch only simple cases - for the whole picture you need
to run graph generator from all allowed code pathes, but that
will require knowledge of the tested system, so it will not and 
actually can not be absolutely generic.
 
> J_rn
> 
> -- 
> It does not matter how slowly you go, so long as you do not stop.
> -- Confucius


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25 18:59             ` Jean Delvare
@ 2005-01-25 21:39               ` Evgeniy Polyakov
  2005-01-25 21:40                 ` Jean Delvare
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 21:39 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Greg KH, Christoph Hellwig, Adrian Bunk, Andrew Morton, LKML

On Tue, 25 Jan 2005 19:59:18 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> Hi all,
> 
> > As previously mentioned, these patches have had that, on the sensors
> > mailing list.  Lots of review and comments went into them there, and
> > the code was reworked quite a lot based on it.
> 
> That's right, I did actually review Evgeniy's code some times ago, as
> can be seen here:
> http://archives.andrew.net.au/lm-sensors/msg27817.html
> 
> I might however add the following:
> 
> 1* This was 5 months ago. I'd expect Evgeniy's code to have
> significantly evolved since, so an additional review now would certainly
> be welcome.

superio core was not changed much, all related changes were posted into 
lm_sensors mail list and discussed.
 
> 2* I only reviewed the superio code. The acb part is completely new so I
> obviously couldn't comment on it back then, and I skipped the gpio part
> because I admittedly have no particular interest in this part.

acb and gpio are logical devices and are very simple.
It was design task to create such model, where each device is as simple 
as possible, and only handle low-level operations.

> 3* Some of my objections have been ignored by Evgeniy. Among others, the
> choice of "sc" as a prefix for the superio stuff is definitely poor and
> has to be changed.
>
> http://archives.andrew.net.au/lm-sensors/msg27847.html

Yep %)
SuperIO Control - is a good name, sio_ I've seen somewhere...
 
> I don't think that getting the whole stuff (superio, acb and gpio)
> merged at once is a good idea. Preferably we would merge superio alone
> first, then update the drivers that are already in the kernel and could
> make use of it (it87, w83627hf, pc87360 and smsc47m1, all of i2c/sensors
> fame, come to mind). This would help ensure that Evgeniy's interface
> choices were correct, and would additionally be a very good example of
> how this interface must be used. Then, and only then IMVHO, should the
> gpio and acb stuff be merged.
> 
> Before all this happens, I really would like Evgeniy to present an
> overall plan of his current superio implementation. Last time we
> discussed about this, we obviously had different views on the interface
> level that should be proposed by the superio core, as well as how
> chip-specific values should be handled (or, according to me, mostly not
> handled). 

GPIO and AccessBus are very simple devices, and I added them just because
1. people often asked exactly about GPIO
2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, 
but noone never asked in any mail list about them, but I think it worth
to implement.

Addind SuperIO itself does not have much sence that it can not be 
tested without at least one logical device, thus I added two.

Porting existing SuperIO devices to the new schema is a very good task, 
but I had only SC1100 processor and PC87366 chip, so I created and tested 
superio chip drivers for them.

> Please note that I am certainly not the most qualified of us all to
> review this code. What I can do is check whether I will be able to use
> the new superio interface in the sensor chip drivers I mentioned above,
> and that's about it. I am not familiar enough with kernel core
> architectures to decide whether Evgeniy's approach is correct or not. I
> am willing to help, but I can do so only within my own current skills.

I always appreciate your comments, they are definitely right and helped
me very much.

Thank you.
 
> Thanks,
> -- 
> Jean Delvare
> http://khali.linux-fr.org/


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25 21:39               ` Evgeniy Polyakov
@ 2005-01-25 21:40                 ` Jean Delvare
  2005-01-25 22:35                   ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Jean Delvare @ 2005-01-25 21:40 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Greg KH, Christoph Hellwig, Adrian Bunk, Andrew Morton, LKML

Hi Evgeniy & all,

> > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > significantly evolved since, so an additional review now would
> > certainly be welcome.
> 
> superio core was not changed much, all related changes were posted
> into  lm_sensors mail list and discussed.

Well, according to the mailing-list archives, which have a better memory
than I do, I skipped at least one:

http://archives.andrew.net.au/lm-sensors/msg18655.html

So I suspect that this update at least was never reviewed by anyone (on
the sensors list at least).

And while we are at it, this post by Andrew is certainly of interest
too:

http://archives.andrew.net.au/lm-sensors/msg18749.html

> > 3* Some of my objections have been ignored by Evgeniy. Among others,
> > the choice of "sc" as a prefix for the superio stuff is definitely
> > poor and has to be changed.
> >
> > http://archives.andrew.net.au/lm-sensors/msg27847.html
> 
> Yep %)
> SuperIO Control - is a good name, sio_ I've seen somewhere...

Sure, sio would be better, or even superio in whole. Anything that
reminds "Super-I/O" is fine with me. sc doesn't.

> GPIO and AccessBus are very simple devices, and I added them just
> because 1. people often asked exactly about GPIO
> 2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, 
> but noone never asked in any mail list about them, but I think it
> worth to implement.
> 
> Addind SuperIO itself does not have much sence that it can not be 
> tested without at least one logical device, thus I added two.
> 
> Porting existing SuperIO devices to the new schema is a very good
> task,  but I had only SC1100 processor and PC87366 chip, so I created
> and tested  superio chip drivers for them.

The PC87366 has integrated sensors, some of which have to be connected
whatever your configuration: voltage inputs 7 to 10 and third
temperature channel. We have a driver for it in the kernel:
drivers/i2c/chips/pc87360. So if you have such a chip, this is actually
someone you can use as a test for your superio subsystem.

If you can provide a patch which adds your superio core driver and one
which modifies the pc87360 driver to take make use of it, and only that,
this would certainly be easier for everyone (and especially me) to
review your superio code. Once this is in, incremental patches for the
additional features should be easier for you to generate and for the
rest of us to review.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25 21:40                 ` Jean Delvare
@ 2005-01-25 22:35                   ` Evgeniy Polyakov
  2005-01-26  9:55                     ` Jean Delvare
  2005-01-26 10:14                     ` Christoph Hellwig
  0 siblings, 2 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-25 22:35 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Greg KH, LKML

On Tue, 25 Jan 2005 22:40:51 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> Hi Evgeniy & all,
> 
> > > 1* This was 5 months ago. I'd expect Evgeniy's code to have
> > > significantly evolved since, so an additional review now would
> > > certainly be welcome.
> > 
> > superio core was not changed much, all related changes were posted
> > into  lm_sensors mail list and discussed.
> 
> Well, according to the mailing-list archives, which have a better memory
> than I do, I skipped at least one:
> 
> http://archives.andrew.net.au/lm-sensors/msg18655.html
> 
> So I suspect that this update at least was never reviewed by anyone (on
> the sensors list at least).

I have one rule - if noone answers that it means noone objects,
or it is not interesting for anyone, and thus noone objects.

> And while we are at it, this post by Andrew is certainly of interest
> too:
> 
> http://archives.andrew.net.au/lm-sensors/msg18749.html

I believe he commented connector patch mostly - we had some very little
private discussion that time about it.

I've posted connector patch several times to lkml - no answers except 
Alan Cox, thus noone objects but patch is very usefull.

> > > 3* Some of my objections have been ignored by Evgeniy. Among others,
> > > the choice of "sc" as a prefix for the superio stuff is definitely
> > > poor and has to be changed.
> > >
> > > http://archives.andrew.net.au/lm-sensors/msg27847.html
> > 
> > Yep %)
> > SuperIO Control - is a good name, sio_ I've seen somewhere...
> 
> Sure, sio would be better, or even superio in whole. Anything that
> reminds "Super-I/O" is fine with me. sc doesn't.
> 
> > GPIO and AccessBus are very simple devices, and I added them just
> > because 1. people often asked exactly about GPIO
> > 2. I had only GPIO and ACB to test. Actually I had a RTC and WDT too, 
> > but noone never asked in any mail list about them, but I think it
> > worth to implement.
> > 
> > Addind SuperIO itself does not have much sence that it can not be 
> > tested without at least one logical device, thus I added two.
> > 
> > Porting existing SuperIO devices to the new schema is a very good
> > task,  but I had only SC1100 processor and PC87366 chip, so I created
> > and tested  superio chip drivers for them.
> 
> The PC87366 has integrated sensors, some of which have to be connected
> whatever your configuration: voltage inputs 7 to 10 and third
> temperature channel. We have a driver for it in the kernel:
> drivers/i2c/chips/pc87360. So if you have such a chip, this is actually
> someone you can use as a test for your superio subsystem.

Btw, they appeared almost the same time :)
Difference was about several days...

I have pc8736x logical devices in my TODO list, but they are currently 
preempted by acrypto, but I definitely will get it very soon.

> If you can provide a patch which adds your superio core driver and one
> which modifies the pc87360 driver to take make use of it, and only that,
> this would certainly be easier for everyone (and especially me) to
> review your superio code. Once this is in, incremental patches for the
> additional features should be easier for you to generate and for the
> rest of us to review.

pc87360.c can not be used with superio as is, it requires big rewrite, 
since you implemented it as part of i2c core, 
that is why I created parts that was not touched by your driver.
Since GPIO can be used with w1 it had greater priority.

Your driver is part of i2c core, it just not supposed to be used 
in superio, although many hardware routings could be used.

I will use it as a base for other superio logical devices.

> Thanks,
> -- 
> Jean Delvare
> http://khali.linux-fr.org/


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
                               ` (2 preceding siblings ...)
  2005-01-25 16:11             ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-25 22:42             ` Christoph Hellwig
  2005-01-26  8:31               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  3 siblings, 1 reply; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-25 22:42 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

> Zeroing can be found easily - the whole structure is NULL pointer, 
> and will always panic if accessed(from running superio code), 
> but redzoning is only happen on borders,
> and can catch writes over the boards, which is rarely in this case.

As I mentioned the redzoning was a brainfar on my side.  Slab debug
code memsets all code with an easily recognizable pattern (which 0 is _NOT_).

So this is totally useless, please don't do it - as all major subsystems
don't do it either.

> Each superio chip is registered with superio core without any devices.
> Each logical device is registered with superio core without any superio
> chip.
> 
> Then core checks if some chip is found in some superio device, and
> links 
> it to appropriate device.
> So if board has several superio chips(like soekris board) and several
> logical devices in it, then we only have 2 superio small drivers, and
> several 
> logical device drivers, but not
> number_of_superio_chips*number_of_logical_devices drivers.

That's how just about any bus driver works so far.

Now somewhere else in the thread I read the a single logical device
might belong to multiple superio devices.  Which is kinda odd, but in
that case it's indeed needed.

So please add a big comment explaining that properperty because it
is extemly uncommon, and make 'ptr' in the chain structure typed
instead of void *

> Yes, and it is better than removing module whose structures are in use.
> SuperIO core is asynchronous in it's nature, one can use logical device 
> through superio core and remove it's module on other CPU, above loop
> will
> wait untill all reference counters are dropped.

General rule is: increment module reference count while the hardware
is actually in use, and let device structures be allocated by the
bus core so drivers can be freed with them still allocated.  That's
how the driver model and thus about every other subsystem works.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 19:12     ` 2.6.11-rc2-mm1 Marcos D. Marado Torres
@ 2005-01-25 23:07       ` Barry K. Nathan
  0 siblings, 0 replies; 152+ messages in thread
From: Barry K. Nathan @ 2005-01-25 23:07 UTC (permalink / raw)
  To: Marcos D. Marado Torres; +Cc: Andrew Morton, linux-kernel

On Tue, Jan 25, 2005 at 07:12:55PM +0000, Marcos D. Marado Torres wrote:
> This acpi_power_off issue ( http://lkml.org/lkml/2005/1/11/88 ) still 
> happens.

http://bugme.osdl.org/show_bug.cgi?id=4041

Look at that bug report (especially toward the bottom) for the latest
information.

-Barry K. Nathan <barryn@pobox.com>


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 21:17                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26  2:20                     ` Jörn Engel
  0 siblings, 0 replies; 152+ messages in thread
From: Jörn Engel @ 2005-01-26  2:20 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Bartlomiej Zolnierkiewicz, Christoph Hellwig, Andrew Morton,
	greg, linux-kernel

On Wed, 26 January 2005 00:17:34 +0300, Evgeniy Polyakov wrote:
> 
> That will catch only simple cases - for the whole picture you need
> to run graph generator from all allowed code pathes, but that
> will require knowledge of the tested system, so it will not and 
> actually can not be absolutely generic.

Oh, we both agree on that, although we used different words.  The
design actually is as simple as outlined, the messy part is getting
the complete call graph of the kernel in the first place.

I have a good deal of that part done, but the code is ugly and there
are legal issues... but it shows that it's quite possible to do.

Jörn

-- 
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (19 preceding siblings ...)
  2005-01-25 19:12     ` 2.6.11-rc2-mm1 Marcos D. Marado Torres
@ 2005-01-26  2:40     ` William Lee Irwin III
  2005-01-26  4:44     ` [PATCH] ppc64: fix use kref for device_node refcounting Nathan Lynch
  2005-01-27  6:18     ` 2.6.11-rc2-mm1 William Lee Irwin III
  22 siblings, 0 replies; 152+ messages in thread
From: William Lee Irwin III @ 2005-01-26  2:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, linux-ia64

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

Someone who sent you a patch needs to learn how to use grep(1). There are
18 patches listed by grep -l it_timer patches/*; giving up.


-- wli

drivers/char/mmtimer.c: In function `reschedule_periodic_timer':
drivers/char/mmtimer.c:423: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:429: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:435: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_interrupt':
drivers/char/mmtimer.c:471: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `mmtimer_tasklet':
drivers/char/mmtimer.c:508: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:516: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_create':
drivers/char/mmtimer.c:527: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_del':
drivers/char/mmtimer.c:538: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:539: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:547: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:548: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_get':
drivers/char/mmtimer.c:561: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:569: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:570: error: structure has no member named `it_timer'
drivers/char/mmtimer.c: In function `sgi_timer_set':
drivers/char/mmtimer.c:643: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:644: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:645: error: structure has no member named `it_incr'
drivers/char/mmtimer.c:646: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:652: error: structure has no member named `it_timer'
drivers/char/mmtimer.c:655: error: structure has no member named `it_timer'
make[4]: *** [drivers/char/mmtimer.o] Error 1
make[3]: *** [drivers/char] Error 2
make[2]: *** [drivers] Error 2
make[2]: *** Waiting for unfinished jobs....

^ permalink raw reply	[flat|nested] 152+ messages in thread

* [PATCH] ppc64: fix use kref for device_node refcounting
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (20 preceding siblings ...)
  2005-01-26  2:40     ` 2.6.11-rc2-mm1 William Lee Irwin III
@ 2005-01-26  4:44     ` Nathan Lynch
  2005-01-27  6:18     ` 2.6.11-rc2-mm1 William Lee Irwin III
  22 siblings, 0 replies; 152+ messages in thread
From: Nathan Lynch @ 2005-01-26  4:44 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, paulus

On Mon, 2005-01-24 at 02:15 -0800, Andrew Morton wrote:
> ppc64-use-kref-for-device_node-refcounting.patch
>   ppc64: use kref for device_node refcounting

This introduced an unbalanced get/put in of_add_node which would cause
newly-added device nodes to be prematurely freed.  Sorry for the
screwup, a more rigorously tested fix follows.

Signed-off-by: Nathan Lynch <nathanl@austin.ibm.com>


---


diff -puN arch/ppc64/kernel/prom.c~fix-kref-devnode arch/ppc64/kernel/prom.c
--- linux-2.6.11-rc2-mm1/arch/ppc64/kernel/prom.c~fix-kref-devnode	2005-01-25 21:10:50.000000000 -0600
+++ linux-2.6.11-rc2-mm1-nathanl/arch/ppc64/kernel/prom.c	2005-01-25 21:14:02.000000000 -0600
@@ -1771,6 +1771,7 @@ int of_add_node(const char *path, struct
 	np->properties = proplist;
 	OF_MARK_DYNAMIC(np);
 	kref_init(&np->kref);
+	of_node_get(np);
 	np->parent = derive_parent(path);
 	if (!np->parent) {
 		kfree(np);

_



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 21:14               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26  4:57                 ` Dmitry Torokhov
  2005-01-26  8:25                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26  4:57 UTC (permalink / raw)
  To: johnpol
  Cc: dmitry.torokhov, Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Tuesday 25 January 2005 16:14, Evgeniy Polyakov wrote:
> On Tue, 25 Jan 2005 11:11:42 -0500
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > On Tue, 25 Jan 2005 18:24:50 +0300, Evgeniy Polyakov
> > <johnpol@2ka.mipt.ru> wrote:
> > > On Tue, 2005-01-25 at 14:23 +0000, Christoph Hellwig wrote:
> > > > > > +static void pc8736x_fini(void)
> > > > > > +{
> > > > > > + sc_del_sc_dev(&pc8736x_dev);
> > > > > > +
> > > > > > + while (atomic_read(&pc8736x_dev.refcnt)) {
> > > > > > +         printk(KERN_INFO "Waiting for %s to became free: refcnt=%d.\n",
> > > > > > +                         pc8736x_dev.name, atomic_read(&pc8736x_dev.refcnt));
> > > > > > +
> > > > > > +         set_current_state(TASK_INTERRUPTIBLE);
> > > > > > +         schedule_timeout(HZ);
> > > > > > +
> > > > > > +         if (current->flags & PF_FREEZE)
> > > > > > +                 refrigerator(PF_FREEZE);
> > > > > > +
> > > > > > +         if (signal_pending(current))
> > > > > > +                 flush_signals(current);
> > > > > > + }
> > > > > > +}
> > > > > >
> > > > > > And who gurantess this won't deadlock?  Please use a dynamically allocated
> > > > > > driver model device and it's refcounting, thanks.
> > > > >
> > > > > Sigh.
> > > > >
> > > > > Christoph, please read the code before doing such comments.
> > > > > I very respect your review and opinion, but only until you respect
> > > > > others.
> > > >
> > > > The code above pretty much means you can keep rmmod stalled forever.
> > > 
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > through superio core and remove it's module on other CPU, above loop
> > > will wait untill all reference counters are dropped.
> > 
> > I have a slightly different concern - the superio is a completely new
> > subsystem and it should be integtrated with the driver model
> > ("superio" bus?). Right now it looks like it is reimplementing most of
> > the abstractions (device lists, driver lists, matching, probing).
> > Moving to driver model significatntly affects lifetime rules for the
> > objects, etc. etc. and will definitely not allow code such as above.
> > 
> > It would be nice it we get things right from the start.
> 
> bus model is not good here - we need bus in each logical device and
> bus in each superio chip(or at least second case).
> Each bus bus have some crosslinking to devices in other buses, 
> and each new device
> must be checked in each bus and probably added to each device...
> 
> It is not like I see it.
> 
> Consider folowing example: 
> each device from set A belongs to each device from set B.
> n <-> n, it is not the case when one bus can handle all features.
> 
> That is why I did not use driver model there.
> It is specific design feature, which is proven to work.
>

Ok, I briefly looked over the patches and that is what I understand
(please correct me where I am wrong):

- you have superio chips which are containers providing set of interfaces;
- you have superio chip driver that detects superio chip and manages
  (enables/disables) individual interfaces.
- you have set of interface drivers (gpio, acb) that bind to individual
  superio interfaces and provide unified userspace interface that allows
  reading, writing and analog of ioctl.

So the question is why you can't have superio bus where superio chips
register their individual interfaces as individual devices. gpio, acb, etc
are drivers that bind to superio devices and create class devices gpio.

You could have:

sys
|-bus
| |-superio
| | |-devices
| | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
| | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
| | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
| | |-drivers
| | | |-gpio
| | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
| | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
| | | |-acb
| | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
|
|-class
| |-gpio
| | |-gpio0
| | |-gpio1

gpioX have control and data attributes that allow reading and writing...

Am I missing something?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26  4:57                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26  8:25                   ` Evgeniy Polyakov
  2005-01-26 13:46                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26  8:25 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: dmitry.torokhov, Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:

> > > I have a slightly different concern - the superio is a completely new
> > > subsystem and it should be integtrated with the driver model
> > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > the abstractions (device lists, driver lists, matching, probing).
> > > Moving to driver model significatntly affects lifetime rules for the
> > > objects, etc. etc. and will definitely not allow code such as above.
> > > 
> > > It would be nice it we get things right from the start.
> > 
> > bus model is not good here - we need bus in each logical device and
> > bus in each superio chip(or at least second case).
> > Each bus bus have some crosslinking to devices in other buses, 
> > and each new device
> > must be checked in each bus and probably added to each device...
> > 
> > It is not like I see it.
> > 
> > Consider folowing example: 
> > each device from set A belongs to each device from set B.
> > n <-> n, it is not the case when one bus can handle all features.
> > 
> > That is why I did not use driver model there.
> > It is specific design feature, which is proven to work.
> >
> 
> Ok, I briefly looked over the patches and that is what I understand
> (please correct me where I am wrong):
> 
> - you have superio chips which are containers providing set of interfaces;
> - you have superio chip driver that detects superio chip and manages
>   (enables/disables) individual interfaces.
> - you have set of interface drivers (gpio, acb) that bind to individual
>   superio interfaces and provide unified userspace interface that allows
>   reading, writing and analog of ioctl.
> 
> So the question is why you can't have superio bus where superio chips
> register their individual interfaces as individual devices. gpio, acb, etc
> are drivers that bind to superio devices and create class devices gpio.
> 
> You could have:
> 
> sys
> |-bus
> | |-superio
> | | |-devices
> | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | |-drivers
> | | | |-gpio
> | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> | | | |-acb
> | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> |
> |-class
> | |-gpio
> | | |-gpio0
> | | |-gpio1
> 
> gpioX have control and data attributes that allow reading and writing...
> 
> Am I missing something?

You try to create n <-> 1 relation, but superio by design supposed to be
n <-> n.
Above schema does not allow linking from each logical device to
appropriate superio chips
or vice versa - sc chips do not have link to it's logical devices.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-25 22:42             ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-26  8:31               ` Evgeniy Polyakov
  2005-01-26 13:32                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26  8:31 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, greg, linux-kernel

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

On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > Zeroing can be found easily - the whole structure is NULL pointer, 
> > and will always panic if accessed(from running superio code), 
> > but redzoning is only happen on borders,
> > and can catch writes over the boards, which is rarely in this case.
> 
> As I mentioned the redzoning was a brainfar on my side.  Slab debug
> code memsets all code with an easily recognizable pattern (which 0 is _NOT_).
> 
> So this is totally useless, please don't do it - as all major subsystems
> don't do it either.

Ok, I do not insist.

> > Each superio chip is registered with superio core without any devices.
> > Each logical device is registered with superio core without any superio
> > chip.
> > 
> > Then core checks if some chip is found in some superio device, and
> > links 
> > it to appropriate device.
> > So if board has several superio chips(like soekris board) and several
> > logical devices in it, then we only have 2 superio small drivers, and
> > several 
> > logical device drivers, but not
> > number_of_superio_chips*number_of_logical_devices drivers.
> 
> That's how just about any bus driver works so far.
> 
> Now somewhere else in the thread I read the a single logical device
> might belong to multiple superio devices.  Which is kinda odd, but in
> that case it's indeed needed.
> 
> So please add a big comment explaining that properperty because it
> is extemly uncommon, and make 'ptr' in the chain structure typed
> instead of void *

Ok.

> > Yes, and it is better than removing module whose structures are in use.
> > SuperIO core is asynchronous in it's nature, one can use logical device 
> > through superio core and remove it's module on other CPU, above loop
> > will
> > wait untill all reference counters are dropped.
> 
> General rule is: increment module reference count while the hardware
> is actually in use, and let device structures be allocated by the
> bus core so drivers can be freed with them still allocated.  That's
> how the driver model and thus about every other subsystem works.

It is not general rule - network stack does not have such mechanism,
which is 
very good, I doubt each block device module increment it's module
reference
when it catch a request...
It is internal structure that has reference counter, not module itself,
and this 
structure may be in use, when module is unloaded, thus unloading must
wait, 
untill all it's structures are freed.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: [PATCH] move common compat ioctls to hash
  2005-01-25  6:17       ` Andi Kleen
@ 2005-01-26  8:40         ` Michael S. Tsirkin
  0 siblings, 0 replies; 152+ messages in thread
From: Michael S. Tsirkin @ 2005-01-26  8:40 UTC (permalink / raw)
  To: Andi Kleen; +Cc: hch, linux-kernel, chrisw, davem

Quoting r. Andi Kleen <ak@suse.de>:
> Subject: Re: [PATCH] move common compat ioctls to hash
> 
> On Mon, Jan 24, 2005 at 10:26:09PM +0200, Michael S. Tsirkin wrote:
> > Hi!
> > The new ioctl code in fs/compat.c can be streamlined a little
> > using the compat hash instead of an explicit switch statement.
> > 
> > The attached patch is against 2.6.11-rc2-bk2.
> > Andi, could you please comment? Does this make sence?
> 
> Problem is that when a compat_ioctl handler returns -EINVAL
> instead of -ENOIOCTLCMD on unknown ioctl it won't check the common
> ones.
> 
> I fear this mistake would be common, that is why I put in the switch.
> 
> -Andi

Still, many drivers still need the compat hash lookup to work
properly, and these still require -ENOIOCTLCMD to work properly.
So is it worth it wasting CPU cycles working around only part of the problem?

How about:
1. Adding a comment in fs.h
2. Changing unlocked_ioctl to behave in the same way as compat_ioctl
 (this will help since unlocked_ioctl will be well tested),
 something along the lines of my old patch below [its against 2.6.11-rc1-bk5].

As a bonus, I expect a small speedup in code using unlocked_ioctl
(as well as compat_ioctl) for datapath things like usb transfers.

Andy, if this sounds convincing, let me know and I'll build a real patch.

MST

diff -rup linux-2.6.10-orig/fs/ioctl.c linux-2.6.10-ioctl-sym/fs/ioctl.c
--- linux-2.6.10-orig/fs/ioctl.c	2005-01-18 10:58:33.609880024 +0200
+++ linux-2.6.10-ioctl-sym/fs/ioctl.c	2005-01-18 10:51:55.690372984 +0200
@@ -24,12 +24,7 @@ static long do_ioctl(struct file *filp, 
 	if (!filp->f_op)
 		goto out;
 
-	if (filp->f_op->unlocked_ioctl) {
-		error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
-		if (error == -ENOIOCTLCMD)
-			error = -EINVAL;
-		goto out;
-	} else if (filp->f_op->ioctl) {
+	if (filp->f_op->ioctl) {
 		lock_kernel();
 		error = filp->f_op->ioctl(filp->f_dentry->d_inode,
 					  filp, cmd, arg);
@@ -93,6 +91,12 @@ asmlinkage long sys_ioctl(unsigned int f
  	if (error)
  		goto out_fput;
 
+	if (filp->f_op && filp->f_op->unlocked_ioctl) {
+		error = filp->f_op->unlocked_ioctl(filp, cmd, arg);
+		if (error != -ENOIOCTLCMD)
+			goto out_fput;
+	}
+
 	switch (cmd) {
 		case FIOCLEX:
 			set_close_on_exec(fd, 1);
-- 
I dont speak for Mellanox.

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25 22:35                   ` Evgeniy Polyakov
@ 2005-01-26  9:55                     ` Jean Delvare
  2005-01-26 10:55                       ` Evgeniy Polyakov
  2005-01-26 10:14                     ` Christoph Hellwig
  1 sibling, 1 reply; 152+ messages in thread
From: Jean Delvare @ 2005-01-26  9:55 UTC (permalink / raw)
  To: johnpol; +Cc: Greg KH, LKML


Hi Evgeniy,

> > So I suspect that this update at least was never reviewed by anyone (on
> > the sensors list at least).
>
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.

Broken rule IMHO. This might be fine for your own projects, but doesn't
work at all for the kernel. Silence might not mean that everyone agrees.
Rather, it could mean that either people are just not interested at all,
or they are too busy to review a whole new subsystem (or more) at the
moment. Believe me, kernel folks are very, very busy.

> I have pc8736x logical devices in my TODO list, but they are currently
> preempted by acrypto, but I definitely will get it very soon.

I don't think you get me. Your personal priorities are unimportant when
you are asking for code review and merge into the main kernel tree. What
matters is that parts are presented correctly and added in small chunks
and in the right order, so as to minimize the time it takes to Greg and
others to understand, review and accept it.

One year ago I learnt this the hard way myself. I realize how deep my
misunderstanding of the situation was back then, and now praise Greg for
the good lesson - however tough it was for me at that time - each time I
now send a kernel patch the right way and get it accepted.

So, make yourself a favor and comply with what the kernel folks expect
from you. They won't change for you.

> > If you can provide a patch which adds your superio core driver and one
> > which modifies the pc87360 driver to take make use of it, and only that,
> > this would certainly be easier for everyone (and especially me) to
> > review your superio code. Once this is in, incremental patches for the
> > additional features should be easier for you to generate and for the
> > rest of us to review.
>
> pc87360.c can not be used with superio as is, it requires big rewrite,
> since you implemented it as part of i2c core,
> that is why I created parts that was not touched by your driver.

Again, you clearly don't get it. The pc87360 driver does *not* require a
big rewrite. Without even looking at your superio code again, I can tell
that it is necessarily broken if every driver which accesses the superio
address space at the moment needs a big rewrite.

The pc87360 driver only really uses the superio for hardware
identification and then to get a couple configuration values (such as
subdevice I/O addresses) at startup, and then leaves it alone forever.
If we has a dedicated superio driver, it would need to provide an
interface to read, and eventually write, these values, as a replacement
for the savage direct accesses we do for now. Period. Anything else
might be nice or useful for other logical devices (such as GPIOs) but is
not strictly necessary at first.

I do not deny that these Super-I/O integrated sensors are not using the
SMBus and as such do not truly belong to the i2c subsystem. It just
happens that, for now and for historical reasons, the i2c subsystem is
also where all hardware monitoring drivers are. That might (hopefully)
change in the future, but this is a completely different problem. One
thing at a time please.

> Your driver is part of i2c core, it just not supposed to be used
> in superio, although many hardware routings could be used.

Again, some drivers in the i2c subsystem use ISA accesses; others need to
poke a couple PCI configuration registers. We did not move these drivers
to the ISA (is there even one?) or PCI subsystems. Before anything else,
these drivers are hardware monitoring drivers, and such drivers belong -
for now - to the i2c subsystem, until we can separate the i2c subsystem
from the hardware monitoring function more clearly.

So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to
move to the "superio subsystem", nor are they going to be rewritten
for it. Superio chips are only a new way to access the subdevices. What
we need for them is an extension of the request_region/release_region
mechanism, because superios introduce a two-level addressing scheme. And
this is about it.

Thanks,
--
Jean Delvare

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-25 22:35                   ` Evgeniy Polyakov
  2005-01-26  9:55                     ` Jean Delvare
@ 2005-01-26 10:14                     ` Christoph Hellwig
  2005-01-26 10:59                       ` Evgeniy Polyakov
  2005-01-26 13:12                       ` Russell King
  1 sibling, 2 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-26 10:14 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> I have one rule - if noone answers that it means noone objects,
> or it is not interesting for anyone, and thus noone objects.

That's simply not true.  The amount of patches submitted is extremly
huge and the reviewers don't have time to look at everythning.

If no one replies it simply means no one has looked at it in enough
detail to comment yet.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26  9:55                     ` Jean Delvare
@ 2005-01-26 10:55                       ` Evgeniy Polyakov
  2005-01-26 14:34                         ` Jean Delvare
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 10:55 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Greg KH, LKML

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

On Wed, 2005-01-26 at 10:55 +0100, Jean Delvare wrote:
> Hi Evgeniy,
> 
> > > So I suspect that this update at least was never reviewed by anyone (on
> > > the sensors list at least).
> >
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, and thus noone objects.
> 
> Broken rule IMHO. This might be fine for your own projects, but doesn't
> work at all for the kernel. Silence might not mean that everyone agrees.
> Rather, it could mean that either people are just not interested at all,
> or they are too busy to review a whole new subsystem (or more) at the
> moment. Believe me, kernel folks are very, very busy.

Sigh.
I presented the code.
Several times in special mail list.

Only problem that it was not sent to lkml, where there are 
too many noise and flood. That is why while digging through it several 
years ago I decided to drop this mail list.

> > I have pc8736x logical devices in my TODO list, but they are currently
> > preempted by acrypto, but I definitely will get it very soon.
> 
> I don't think you get me. Your personal priorities are unimportant when
> you are asking for code review and merge into the main kernel tree. What
> matters is that parts are presented correctly and added in small chunks
> and in the right order, so as to minimize the time it takes to Greg and
> others to understand, review and accept it.
> 
> One year ago I learnt this the hard way myself. I realize how deep my
> misunderstanding of the situation was back then, and now praise Greg for
> the good lesson - however tough it was for me at that time - each time I
> now send a kernel patch the right way and get it accepted.
> 
> So, make yourself a favor and comply with what the kernel folks expect
> from you. They won't change for you.

Mdee...

I do not understand you, what are you trying to say? Waht is wrong?
I wrote the code.
I presented it.
I presented it again.
I presented it yeat another again.

First time people answered, then - not.

I ask for inclusion. It is included, and ohh now people recall, 
that they wanted to complain.
Ok, I want to listen what technical problems do you see?

> > > If you can provide a patch which adds your superio core driver and one
> > > which modifies the pc87360 driver to take make use of it, and only that,
> > > this would certainly be easier for everyone (and especially me) to
> > > review your superio code. Once this is in, incremental patches for the
> > > additional features should be easier for you to generate and for the
> > > rest of us to review.
> >
> > pc87360.c can not be used with superio as is, it requires big rewrite,
> > since you implemented it as part of i2c core,
> > that is why I created parts that was not touched by your driver.
> 
> Again, you clearly don't get it. The pc87360 driver does *not* require a
> big rewrite. Without even looking at your superio code again, I can tell
> that it is necessarily broken if every driver which accesses the superio
> address space at the moment needs a big rewrite.
> 
> The pc87360 driver only really uses the superio for hardware
> identification and then to get a couple configuration values (such as
> subdevice I/O addresses) at startup, and then leaves it alone forever.
> If we has a dedicated superio driver, it would need to provide an
> interface to read, and eventually write, these values, as a replacement
> for the savage direct accesses we do for now. Period. Anything else
> might be nice or useful for other logical devices (such as GPIOs) but is
> not strictly necessary at first.
> 
> I do not deny that these Super-I/O integrated sensors are not using the
> SMBus and as such do not truly belong to the i2c subsystem. It just
> happens that, for now and for historical reasons, the i2c subsystem is
> also where all hardware monitoring drivers are. That might (hopefully)
> change in the future, but this is a completely different problem. One
> thing at a time please.

Sigh.
Jean, it looks like you forget how superio is designed.
Your pc87360 driver is all in one big piese of code, superio
is splitted into absolutely separated modules - _one_ for superio chip,
and _several_ for logical devices.

I need to split your driver into at least 5 parts - pc8736x 
initialisation(superio has it), i2c part(should be removed from superio
code),
fan logical device(separate part), voltage monitor logical device
(separate part)
and temperature monitor logical device(separate part).

They are just separate modules, it is design feature to use _the_
_same_, 
for example, voltage monitor module with _any_ number of existent
superio chips.

> > Your driver is part of i2c core, it just not supposed to be used
> > in superio, although many hardware routings could be used.
> 
> Again, some drivers in the i2c subsystem use ISA accesses; others need to
> poke a couple PCI configuration registers. We did not move these drivers
> to the ISA (is there even one?) or PCI subsystems. Before anything else,
> these drivers are hardware monitoring drivers, and such drivers belong -
> for now - to the i2c subsystem, until we can separate the i2c subsystem
> from the hardware monitoring function more clearly.
> 
> So, the pc87360, it87, smsc47m1 and w83627hf drivers are not going to
> move to the "superio subsystem", nor are they going to be rewritten
> for it. Superio chips are only a new way to access the subdevices. What
> we need for them is an extension of the request_region/release_region
> mechanism, because superios introduce a two-level addressing scheme. And
> this is about it.

And that will end up having tons of duplicated code in each driver:
temp monitor in A, temp monitor in B and so on...
volt monitor in A, volt monitor in B and so on...
...

Jean, we already discussed it a bit in lm_sensors mail list AFAR...

> Thanks,
> --
> Jean Delvare
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 10:14                     ` Christoph Hellwig
@ 2005-01-26 10:59                       ` Evgeniy Polyakov
  2005-01-26 14:00                         ` Dmitry Torokhov
  2005-01-26 18:06                         ` Adrian Bunk
  2005-01-26 13:12                       ` Russell King
  1 sibling, 2 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 10:59 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Jean Delvare, Greg KH, LKML

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

On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > I have one rule - if noone answers that it means noone objects,
> > or it is not interesting for anyone, and thus noone objects.
> 
> That's simply not true.  The amount of patches submitted is extremly
> huge and the reviewers don't have time to look at everythning.
> 
> If no one replies it simply means no one has looked at it in enough
> detail to comment yet.

That is why I resent it several times.
Then I asked for inclusion.

I never send it to lkml just because simple static/non static + module
name
discussion in lkml already overflowed into more than 20 messages...

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 10:14                     ` Christoph Hellwig
  2005-01-26 10:59                       ` Evgeniy Polyakov
@ 2005-01-26 13:12                       ` Russell King
  2005-01-26 20:01                         ` Christoph Hellwig
  1 sibling, 1 reply; 152+ messages in thread
From: Russell King @ 2005-01-26 13:12 UTC (permalink / raw)
  To: Christoph Hellwig, Evgeniy Polyakov, Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 10:14:34AM +0000, Christoph Hellwig wrote:
> That's simply not true.  The amount of patches submitted is extremly
> huge and the reviewers don't have time to look at everythning.
> 
> If no one replies it simply means no one has looked at it in enough
> detail to comment yet.

How do people get to know this?  Grape vines and crystal balls are
inherently unreliable.

I think that if someone overlooks the patches when they're on the mailing
lists and then complains when they're merged into the kernel, they have
very little justification when trying to make it the patch submitters
problem.  It's clearly an overall failing of the community to have enough
resources to review the patches before inclusion.

Frequently I end up with the situation where *NO* *ONE* seems interested
in my patches and I throw them at Linus anyway after months have gone by.
Maybe I'm just lucky that no one bothers to read my patches or everyone
is implicitly exstatic with them.  Nevertheless, I'm forced by the lack
of response from LKML to follow precisely the same rule - no response
implies people are happy.  In reality, not doing so would mean I'd never
get any patches merged which is unacceptable.

So, if the community has a problem with enough time to review patches,
the community must get more (good) patch reviewers.  We can't go around
blaming the patch submitters for a community failing.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26  8:31               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 13:32                 ` Dmitry Torokhov
  2005-01-26 14:44                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 13:32 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > > Yes, and it is better than removing module whose structures are in use.
> > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > through superio core and remove it's module on other CPU, above loop
> > > will
> > > wait untill all reference counters are dropped.
> >
> > General rule is: increment module reference count while the hardware
> > is actually in use, and let device structures be allocated by the
> > bus core so drivers can be freed with them still allocated.  That's
> > how the driver model and thus about every other subsystem works.
> 
> It is not general rule - network stack does not have such mechanism,
> which is
> very good, I doubt each block device module increment it's module
> reference
> when it catch a request...
> It is internal structure that has reference counter, not module itself,
> and this
> structure may be in use, when module is unloaded, thus unloading must
> wait,
> untill all it's structures are freed.
> 

No, it does not necessarily has to wait. You can unload driver at any
time if you care to mark all its devices as "dead" and you have
generic release function in a separate module that does not get
unloaded until last registered device has been destroyed. Look for
example at serio code. I think USB is about the same.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26  8:25                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 13:46                     ` Dmitry Torokhov
  2005-01-26 14:59                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 13:46 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> 
> > > > I have a slightly different concern - the superio is a completely new
> > > > subsystem and it should be integtrated with the driver model
> > > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > > the abstractions (device lists, driver lists, matching, probing).
> > > > Moving to driver model significatntly affects lifetime rules for the
> > > > objects, etc. etc. and will definitely not allow code such as above.
> > > >
> > > > It would be nice it we get things right from the start.
> > >
> > > bus model is not good here - we need bus in each logical device and
> > > bus in each superio chip(or at least second case).
> > > Each bus bus have some crosslinking to devices in other buses,
> > > and each new device
> > > must be checked in each bus and probably added to each device...
> > >
> > > It is not like I see it.
> > >
> > > Consider folowing example:
> > > each device from set A belongs to each device from set B.
> > > n <-> n, it is not the case when one bus can handle all features.
> > >
> > > That is why I did not use driver model there.
> > > It is specific design feature, which is proven to work.
> > >
> >
> > Ok, I briefly looked over the patches and that is what I understand
> > (please correct me where I am wrong):
> >
> > - you have superio chips which are containers providing set of interfaces;
> > - you have superio chip driver that detects superio chip and manages
> >   (enables/disables) individual interfaces.
> > - you have set of interface drivers (gpio, acb) that bind to individual
> >   superio interfaces and provide unified userspace interface that allows
> >   reading, writing and analog of ioctl.
> >
> > So the question is why you can't have superio bus where superio chips
> > register their individual interfaces as individual devices. gpio, acb, etc
> > are drivers that bind to superio devices and create class devices gpio.
> >
> > You could have:
> >
> > sys
> > |-bus
> > | |-superio
> > | | |-devices
> > | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > | | |-drivers
> > | | | |-gpio
> > | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > | | | |-acb
> > | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > |
> > |-class
> > | |-gpio
> > | | |-gpio0
> > | | |-gpio1
> >
> > gpioX have control and data attributes that allow reading and writing...
> >
> > Am I missing something?
> 
> You try to create n <-> 1 relation, but superio by design supposed to be
> n <-> n.

What design? Hardware design or present implementation design?

> Above schema does not allow linking from each logical device to
> appropriate superio chips
> or vice versa - sc chips do not have link to it's logical devices.
>

sc chip does have a link to its logical devices - look at 0000:02:03.0
PCI device in the picture above - that your SuperIO chip with 2
interfaces. Interface, when bound to a superio driver creates gpio
class device which in turn has link to physical device (here one of
the SuperIO interfaces).


Yes, I am trying to do 1 - n relationship. I do not understand why
logical device has to span across several physical devices. With the
exception of device mapper/raid you don't have a logical device span
several physical devices, with everything else there is a parent that
has several children.

You have a PCI bus that has several PCI devices, one of them happens
to be a IDE host controller with 2 channels connected to it. The other
is your SuperIO chip with 2 GPIO pins and something else, and another
SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors
temperature in the case and the second interfaces wth some custom
equipment measuring some thersholds in some chemical process. Are you
saying that all 5 GPIO pins should be presented as one logical device
that provides 5 outputs not related to each other? No, you have 5
distinct devices with similar interfaces providing 5 distinct reads.
Userspace may chose to group them somehow, based on external
information that kernel does not have, but that's it. Kernel only
provides uniform interface.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 10:59                       ` Evgeniy Polyakov
@ 2005-01-26 14:00                         ` Dmitry Torokhov
  2005-01-26 16:38                           ` Evgeniy Polyakov
  2005-01-26 18:06                         ` Adrian Bunk
  1 sibling, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 14:00 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Jean Delvare, Greg KH, LKML

On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is not interesting for anyone, and thus noone objects.
> >
> > That's simply not true.  The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> >
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
> 
> That is why I resent it several times.
> Then I asked for inclusion.
> 
> I never send it to lkml just because simple static/non static + module
> name
> discussion in lkml already overflowed into more than 20 messages...

Well, not everyone is subscribed to lm_sensors mailing list but
nonetheless are interested when a new subsystem is introduced into the
kernel. There several established subsystems (network, USB, ide) whose
maintainers people trust either because of the good track record or
because it affects small number of people so the main discussion is
kept on special lists. But even then most patches are presented on
LKML when issues ironed out on special list.

With a new subsystem it is wise to present it to LKML so it gets wider coverage.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 10:55                       ` Evgeniy Polyakov
@ 2005-01-26 14:34                         ` Jean Delvare
  2005-01-26 16:10                           ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Jean Delvare @ 2005-01-26 14:34 UTC (permalink / raw)
  To: johnpol; +Cc: Greg KH, LKML


Hi Evgeniy,

> I presented the code.
> Several times in special mail list.

That's true. Except that the second time (at least) you didn't find
anyone to review it. Also note that your patches are about superio, gpio
and now access bus. The list is dedicated to hardware monitoring. This
is no exact match, although it happens that some superio chips include
hardware monitoring logical devices. So I reviewed the part I think I
could help with, and skipped the rest (and I did tell the you, and the
list, that I had).

> Only problem that it was not sent to lkml, where there are 
> too many noise and flood. That is why while digging through it several 
> years ago I decided to drop this mail list.

I agree that there is a heavy traffic on LKML - I am not subscribed
myself just because of that. However, when one introduces a completely
new subsystem, it definitely needs review by folks that have way more
knowledge about the kernel internals than I do - expecially about the
(bus) driver model.

> I do not understand you, what are you trying to say? Waht is wrong?
> I wrote the code.
> I presented it.
> I presented it again.
> I presented it yeat another again.
>
> First time people answered, then - not.

OK, blame me for having a day job, a girlfriend and a family. Blame me
for not having the necessary time and knowledge to review your code.

And then think about it again. Maybe you did not present it to the right
person(s). Maybe you did not present it in the correct form. Maybe you
didn't properly explain what problem you were trying to solve - and
failed to catch people's attention because of that. And maybe you
should not have ignored some of my comments - and others'. I would
invite you to read your own recent posts to the LKML again. Most
objections you have received about your code - some of which were so
blantantly valid (several drivers with the same name is fine, no
kidding) - you first denied that there were any problem, then grumbled,
then accepted to change but just not to make any trouble - not because
you were wrong. You are not going anywhere here with this attitude.

Sure, we, kernel developers as a whole, lack time to properly review all
the code that is sent to us. Even me, and I probably receive one
hundredth of what Greg, Andrew or Linus receive. And now what? That's
the way it is and we (and you) have to live with it. If you want the
situation to improve, you can volunteer to review some code. Andrew's
broken-out directories and LKML are full of patches that need review. Or
pick one subsystem and track the patches applied to it. Really, do not
hesitate to help. You certainly will learn much about kernel code review
by doing so, and your own submissions are likely to be significantly
better thanks to that. My story exactly.

> I ask for inclusion. It is included, and ohh now people recall, 
> that they wanted to complain.

What other choice do they have at this point? Ignore or complain. I
definitely prefer them to complain if they have a reason to - and the
same would apply if it was my code and not yours.

Note that I don't blame Greg for pushing the code into Andrew's tree.
This is what this tree is for, and now your patches got some exposure
and you have objections to work on, to say the least. I also admit that
some people here are being a little harsh, but I believe that each one
of us is doing his/her best to improve the kernel. It just happens that
our best isn't always as good as one would want.

> Ok, I want to listen what technical problems do you see?

As I explained before, I would like to see your superio subsystem
integrate properly with existing drivers that need it before you attempt
to add more functions on top of it. And I want a full documentation of
your superio subsystem to be part of the patchset. It seems that most
people here didn't get what you were doing and why you were doing it
(at least I wasn't alone ;)), so obviously a complete documentation
would be more than welcome - needed would in fact be the appropriate
term.


> Jean, it looks like you forget how superio is designed.
> Your pc87360 driver is all in one big piese of code, superio
> is splitted into absolutely separated modules - _one_ for superio chip,
> and _several_ for logical devices.
>
> I need to split your driver into at least 5 parts - pc8736x 
> initialisation(superio has it), i2c part(should be removed from superio
> code), fan logical device(separate part), voltage monitor logical device
> (separate part) and temperature monitor logical device (separate part).

The whole thing is a single driver because it achieves one goal. The fact
that National Semiconductor decided to use three different logical
devices for temperatures, voltages and fans is an implementation detail.
This alone doesn't justify a split of the source code. The "superio
chip" part is what you have been working on and I agree it was needed.
And I agree that the superio access has to be moved from my pc87360
driver (and other similar drivers) to your superio driver.

You do not *have* to separate all the parts. One single driver can
request several logical devices, and this is precisely what I want us to
do here. I agree that it could make sense to separate the logical
devices on a per device (and driver) basis, if it allows us to reuse the
code more easily. It is however not a requirement, that I can see.

> They are just separate modules, it is design feature to use _the_ _same_,
> for example, voltage monitor module with _any_ number of existent superio
> chips.

It isn't the first time you say that, and I have to say I don't much
get where you want to go. The hardware monitoring logical devices are
completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx
superio devices, just like the various other hardware monitoring chips
are different. There is no code to be shared here, so nothing is
duplicated.

Maybe it is different with gpio or access bus? Is there some standard
register organization among the various chip makers? I don't know
these, so I cannot tell.

> And that will end up having tons of duplicated code in each driver:
> temp monitor in A, temp monitor in B and so on...
> volt monitor in A, volt monitor in B and so on...

There is no logical device-based duplicated code in the superio hardware
monitoring drivers at the moment, unless you see things I do not (if you
do please let me know). The only thing that is duplicated accross the
drivers is the superio accesses, agreed, and I am glad that your unified
superio driver will put an end to this.

> Jean, we already discussed it a bit in lm_sensors mail list AFAR...

Yes, 5 months ago, and we did not exactly agree. And we obviously still
do not agree.

Don't get me wrong, I am not saying that I don't want your code in the
kernel. I am actually interested in it (the base superio part, in fact).
All I am asking for is that you put some efforts in presenting your code
correctly, splitting it the way it has to be, and getting it into the
kernel step by step. You are not going to get any support from me by
pretending that the superio hardware monitoring drivers need a full
rewrite to accomodate with your unified superio driver - because I know
it cannot be true. If you can provide a first patchset with core superio
driver, documentation of it, and *minimum* updates of the pc87360 driver
to make use of it, you can be sure I will review it with great care.

Thanks,
--
Jean Delvare

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 13:32                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 14:44                   ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 14:44 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Wed, 2005-01-26 at 08:32 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:31:07 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Tue, 2005-01-25 at 22:42 +0000, Christoph Hellwig wrote:
> > > > Yes, and it is better than removing module whose structures are in use.
> > > > SuperIO core is asynchronous in it's nature, one can use logical device
> > > > through superio core and remove it's module on other CPU, above loop
> > > > will
> > > > wait untill all reference counters are dropped.
> > >
> > > General rule is: increment module reference count while the hardware
> > > is actually in use, and let device structures be allocated by the
> > > bus core so drivers can be freed with them still allocated.  That's
> > > how the driver model and thus about every other subsystem works.
> > 
> > It is not general rule - network stack does not have such mechanism,
> > which is
> > very good, I doubt each block device module increment it's module
> > reference
> > when it catch a request...
> > It is internal structure that has reference counter, not module itself,
> > and this
> > structure may be in use, when module is unloaded, thus unloading must
> > wait,
> > untill all it's structures are freed.
> > 
> 
> No, it does not necessarily has to wait. You can unload driver at any
> time if you care to mark all its devices as "dead" and you have
> generic release function in a separate module that does not get
> unloaded until last registered device has been destroyed. Look for
> example at serio code. I think USB is about the same.
> 

It is only because those structures can live outside the driver.
Like skb can live without even any network driver loaded.
Above case is similar, but structure is binded to the module, and can
be 
requested outside the world.

Consider as example network stack:
netdev_wait_allrefs() waits until all references are gone, it is
called  
when device has NETREG_UNREGISTERING state.

Very clean example is virtual devices here(tunnels, vlan) - it is
exactly the same
as logical/superio devices in superio core.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 13:46                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 14:59                       ` Evgeniy Polyakov
  2005-01-26 15:26                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 14:59 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Wed, 2005-01-26 at 08:46 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 11:25:02 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Tue, 2005-01-25 at 23:57 -0500, Dmitry Torokhov wrote:
> > 
> > > > > I have a slightly different concern - the superio is a completely new
> > > > > subsystem and it should be integtrated with the driver model
> > > > > ("superio" bus?). Right now it looks like it is reimplementing most of
> > > > > the abstractions (device lists, driver lists, matching, probing).
> > > > > Moving to driver model significatntly affects lifetime rules for the
> > > > > objects, etc. etc. and will definitely not allow code such as above.
> > > > >
> > > > > It would be nice it we get things right from the start.
> > > >
> > > > bus model is not good here - we need bus in each logical device and
> > > > bus in each superio chip(or at least second case).
> > > > Each bus bus have some crosslinking to devices in other buses,
> > > > and each new device
> > > > must be checked in each bus and probably added to each device...
> > > >
> > > > It is not like I see it.
> > > >
> > > > Consider folowing example:
> > > > each device from set A belongs to each device from set B.
> > > > n <-> n, it is not the case when one bus can handle all features.
> > > >
> > > > That is why I did not use driver model there.
> > > > It is specific design feature, which is proven to work.
> > > >
> > >
> > > Ok, I briefly looked over the patches and that is what I understand
> > > (please correct me where I am wrong):
> > >
> > > - you have superio chips which are containers providing set of interfaces;
> > > - you have superio chip driver that detects superio chip and manages
> > >   (enables/disables) individual interfaces.
> > > - you have set of interface drivers (gpio, acb) that bind to individual
> > >   superio interfaces and provide unified userspace interface that allows
> > >   reading, writing and analog of ioctl.
> > >
> > > So the question is why you can't have superio bus where superio chips
> > > register their individual interfaces as individual devices. gpio, acb, etc
> > > are drivers that bind to superio devices and create class devices gpio.
> > >
> > > You could have:
> > >
> > > sys
> > > |-bus
> > > | |-superio
> > > | | |-devices
> > > | | | |-sio0 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > > | | | |-sio1 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > > | | | |-sio2 -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > > | | |-drivers
> > > | | | |-gpio
> > > | | | | |-sio1 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio1
> > > | | | | |-sio2 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:04.0/sio2
> > > | | | |-acb
> > > | | | | |-sio0 -> ../../../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/sio0
> > > |
> > > |-class
> > > | |-gpio
> > > | | |-gpio0
> > > | | |-gpio1
> > >
> > > gpioX have control and data attributes that allow reading and writing...
> > >
> > > Am I missing something?
> > 
> > You try to create n <-> 1 relation, but superio by design supposed to be
> > n <-> n.
> 
> What design? Hardware design or present implementation design?

Hardware: each superio chip can have exactly the same logical devices
like any 
other(actually it is standard, which is not always followed). I mean not
the same device 
set, but logical devices itself - voltage monitors are the same for any
standard superio chip.
So we have many chips with the same set of the similar hardware.

Reverse relation is created when we want to keep only 
number_od_superio_chips + number_of_logical_device number of drivers,
but not it's multiplication.

> > Above schema does not allow linking from each logical device to
> > appropriate superio chips
> > or vice versa - sc chips do not have link to it's logical devices.
> >
> 
> sc chip does have a link to its logical devices - look at 0000:02:03.0
> PCI device in the picture above - that your SuperIO chip with 2
> interfaces. Interface, when bound to a superio driver creates gpio
> class device which in turn has link to physical device (here one of
> the SuperIO interfaces).
> 
> 
> Yes, I am trying to do 1 - n relationship. I do not understand why
> logical device has to span across several physical devices. With the
> exception of device mapper/raid you don't have a logical device span
> several physical devices, with everything else there is a parent that
> has several children.
> 
> You have a PCI bus that has several PCI devices, one of them happens
> to be a IDE host controller with 2 channels connected to it. The other
> is your SuperIO chip with 2 GPIO pins and something else, and another
> SuperIO chip with 3 GIPO pins. Let's say you 1st chip monitors
> temperature in the case and the second interfaces wth some custom
> equipment measuring some thersholds in some chemical process. Are you
> saying that all 5 GPIO pins should be presented as one logical device
> that provides 5 outputs not related to each other? No, you have 5
> distinct devices with similar interfaces providing 5 distinct reads.
> Userspace may chose to group them somehow, based on external
> information that kernel does not have, but that's it. Kernel only
> provides uniform interface.
> 

Each superio chip has the same logical devices inside.
With your approach we will have following schema:

bus:
superio1 - voltage, temp, gpio, rtc, wdt, acb
superio2 - voltage, temp, gpio, rtc, wdt, acb
superio3 - voltage, temp, gpio, rtc, wdt, acb
superio4 - voltage, temp, gpio, rtc, wdt, acb

Each logical device driver (for existing superio schema)
is about(more than) 150 lines of code.
With your approach above example will be 150*6*4 +
4*superio_chip_driver_size bytes
of the code.
With my - only 150*6 + 4*superio_chip_driver_size.

And not the code size is matter, but that fact, that changing one driver
(for example add feature to more precise temperature conversation) will
end up fixing huge amount of driver, but not the one file.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 14:59                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 15:26                         ` Dmitry Torokhov
  2005-01-26 15:54                           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 15:26 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:

> Each superio chip has the same logical devices inside.
> With your approach we will have following schema:
> 
> bus:
> superio1 - voltage, temp, gpio, rtc, wdt, acb
> superio2 - voltage, temp, gpio, rtc, wdt, acb
> superio3 - voltage, temp, gpio, rtc, wdt, acb
> superio4 - voltage, temp, gpio, rtc, wdt, acb
> 
> Each logical device driver (for existing superio schema)
> is about(more than) 150 lines of code.
> With your approach above example will be 150*6*4 +
> 4*superio_chip_driver_size bytes
> of the code.

????? Let's count again, shall we? Suppose we have:
> superio1 - voltage, temp, gpio, rtc, wdt, acb
> superio2 - voltage, temp, gpio, rtc, wdt, acb
superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
or whatever. So here, you have 2 drivers to manage chips. Plus you
have 6 superio interface drivers - gpio, acb, etc...
It is exactly the same as your cheme size-wise.

There is no need to many-to-many relationship. Each chip is bound to
only one chip driver which registers several interfaces. Each
interface is bound to only one interface driver. Interface driver is
not chip specific, it knows how to run a specific interface (gpio,
temp) and relies on chip driver to properly manage access to the
hardware. Each combination of inetrface + interface driver produce one
class_device (call it sio, serio, whatever). Class device provides
unified view of the interface to the userspace.

What am I missing?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 15:26                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 15:54                           ` Evgeniy Polyakov
  2005-01-26 16:25                             ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 15:54 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> 
> > Each superio chip has the same logical devices inside.
> > With your approach we will have following schema:
> > 
> > bus:
> > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > 
> > Each logical device driver (for existing superio schema)
> > is about(more than) 150 lines of code.
> > With your approach above example will be 150*6*4 +
> > 4*superio_chip_driver_size bytes
> > of the code.
> 
> ????? Let's count again, shall we? Suppose we have:
> > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > superio2 - voltage, temp, gpio, rtc, wdt, acb
> superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> or whatever. So here, you have 2 drivers to manage chips. Plus you
> have 6 superio interface drivers - gpio, acb, etc...
> It is exactly the same as your cheme size-wise.
> 
> There is no need to many-to-many relationship. Each chip is bound to
> only one chip driver which registers several interfaces. Each
> interface is bound to only one interface driver. Interface driver is
> not chip specific, it knows how to run a specific interface (gpio,
> temp) and relies on chip driver to properly manage access to the
> hardware. Each combination of inetrface + interface driver produce one
> class_device (call it sio, serio, whatever). Class device provides
> unified view of the interface to the userspace.
> 
> What am I missing?

Since each logical device does not know who use it, it can not be,
for example, removed optimally.
You need to run through whole superio device set to find those one that 
has reference to logical device being removed.
And situation become much worse, when we have so called logical device
clones - 
it is virtual logical device that emulates standard one, but inside
performs
in a different way. Clone creates inside superio device(for example such
device
can live at different address).
When you do not have ldev->sc relation, you must traverse through each
logical device 
in each superio chip to find clones.
Thus you will need to traverse through each superio chip, 
then through each logical device it references, just to remove one
logical device.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 14:34                         ` Jean Delvare
@ 2005-01-26 16:10                           ` Evgeniy Polyakov
  2005-01-26 19:20                             ` Jean Delvare
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 16:10 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Greg KH, LKML

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

On Wed, 2005-01-26 at 15:34 +0100, Jean Delvare wrote:
> Hi Evgeniy,
> 
> > I presented the code.
> > Several times in special mail list.
> 
> That's true. Except that the second time (at least) you didn't find
> anyone to review it. Also note that your patches are about superio, gpio
> and now access bus. The list is dedicated to hardware monitoring. This
> is no exact match, although it happens that some superio chips include
> hardware monitoring logical devices. So I reviewed the part I think I
> could help with, and skipped the rest (and I did tell the you, and the
> list, that I had).

It is the most closest to the superio subsystem mail list,
and all comments presented there about superio code were always right
and 
indeed usefull.
I believe I addressed them all(except function prefixes :) )

> > Only problem that it was not sent to lkml, where there are 
> > too many noise and flood. That is why while digging through it several 
> > years ago I decided to drop this mail list.
> 
> I agree that there is a heavy traffic on LKML - I am not subscribed
> myself just because of that. However, when one introduces a completely
> new subsystem, it definitely needs review by folks that have way more
> knowledge about the kernel internals than I do - expecially about the
> (bus) driver model.

A bit offtopic: the reason why we have such long discussion about
superio 
is not that it is new, and you can see it if you dig the archive from
the 
beginning.

> > I do not understand you, what are you trying to say? Waht is wrong?
> > I wrote the code.
> > I presented it.
> > I presented it again.
> > I presented it yeat another again.
> >
> > First time people answered, then - not.
> 
> OK, blame me for having a day job, a girlfriend and a family. Blame me
> for not having the necessary time and knowledge to review your code.

:) You misunderstand me, sorry.
I absolutely did not want to blame anyone and 
even did not have it in my thoughts :)

> And then think about it again. Maybe you did not present it to the right
> person(s). Maybe you did not present it in the correct form. Maybe you
> didn't properly explain what problem you were trying to solve - and
> failed to catch people's attention because of that. And maybe you
> should not have ignored some of my comments - and others'. I would
> invite you to read your own recent posts to the LKML again. Most
> objections you have received about your code - some of which were so
> blantantly valid (several drivers with the same name is fine, no
> kidding) - you first denied that there were any problem, then grumbled,
> then accepted to change but just not to make any trouble - not because
> you were wrong. You are not going anywhere here with this attitude.

<not personal to you reasonings...>
Most objections are so small, that is can not be called problems.
I will fix it soon.

And I still do not see any problems there, I just do not want to spend
my time in such meaningless dispute about module names.
I'm not religious fanatic which will with foam at the mouth try to
make it's word latest.
I prefer to do interesting things and it is much easier to change the
module 
name than try to convince army of opponents :)

Superio design as actually another isssue, although I still do not
understand
why break well written working code just to what?
As I said, talk is cheap, if only discuss design notes, nothing can be
created.
</not personal to you reasonings...>

> Sure, we, kernel developers as a whole, lack time to properly review all
> the code that is sent to us. Even me, and I probably receive one
> hundredth of what Greg, Andrew or Linus receive. And now what? That's
> the way it is and we (and you) have to live with it. If you want the
> situation to improve, you can volunteer to review some code. Andrew's
> broken-out directories and LKML are full of patches that need review. Or
> pick one subsystem and track the patches applied to it. Really, do not
> hesitate to help. You certainly will learn much about kernel code review
> by doing so, and your own submissions are likely to be significantly
> better thanks to that. My story exactly.

And do I blame anyone?
Did I said that all you are fscking monsters that do not like my baby?

No, I presented the code and appreciate anyone's comments.
Thank you.

> > I ask for inclusion. It is included, and ohh now people recall, 
> > that they wanted to complain.
> 
> What other choice do they have at this point? Ignore or complain. I
> definitely prefer them to complain if they have a reason to - and the
> same would apply if it was my code and not yours.

I do not say it to your personally, but in general:
Let's discuss the code, let's discuss the design, but do not try to
say, 
that code is bad just because one never see it before and it was just 
appeared here, and one do not understand something...

Most of the thread is not discussion...

> Note that I don't blame Greg for pushing the code into Andrew's tree.
> This is what this tree is for, and now your patches got some exposure
> and you have objections to work on, to say the least. I also admit that
> some people here are being a little harsh, but I believe that each one
> of us is doing his/her best to improve the kernel. It just happens that
> our best isn't always as good as one would want.
> 
> > Ok, I want to listen what technical problems do you see?
> 
> As I explained before, I would like to see your superio subsystem
> integrate properly with existing drivers that need it before you attempt
> to add more functions on top of it. And I want a full documentation of
> your superio subsystem to be part of the patchset. It seems that most
> people here didn't get what you were doing and why you were doing it
> (at least I wasn't alone ;)), so obviously a complete documentation
> would be more than welcome - needed would in fact be the appropriate
> term.

Sure, I definitely will devote much time to document all pieces.

> 
> > Jean, it looks like you forget how superio is designed.
> > Your pc87360 driver is all in one big piese of code, superio
> > is splitted into absolutely separated modules - _one_ for superio chip,
> > and _several_ for logical devices.
> >
> > I need to split your driver into at least 5 parts - pc8736x 
> > initialisation(superio has it), i2c part(should be removed from superio
> > code), fan logical device(separate part), voltage monitor logical device
> > (separate part) and temperature monitor logical device (separate part).
> 
> The whole thing is a single driver because it achieves one goal. The fact
> that National Semiconductor decided to use three different logical
> devices for temperatures, voltages and fans is an implementation detail.
> This alone doesn't justify a split of the source code. The "superio
> chip" part is what you have been working on and I agree it was needed.
> And I agree that the superio access has to be moved from my pc87360
> driver (and other similar drivers) to your superio driver.
> 
> You do not *have* to separate all the parts. One single driver can
> request several logical devices, and this is precisely what I want us to
> do here. I agree that it could make sense to separate the logical
> devices on a per device (and driver) basis, if it allows us to reuse the
> code more easily. It is however not a requirement, that I can see.

I mean above that we need to separate them logically from superio
access 
and i2c part.
But it is really better to have each logical device driver be a separate
module, 
it is just easier to search and handle.

> > They are just separate modules, it is design feature to use _the_ _same_,
> > for example, voltage monitor module with _any_ number of existent superio
> > chips.
> 
> It isn't the first time you say that, and I have to say I don't much
> get where you want to go. The hardware monitoring logical devices are
> completely different between PC8736x, IT87xxF, W836x7(T)HF and 47M1xx
> superio devices, just like the various other hardware monitoring chips
> are different. There is no code to be shared here, so nothing is
> duplicated.
> 
> Maybe it is different with gpio or access bus? Is there some standard
> register organization among the various chip makers? I don't know
> these, so I cannot tell.

As I saw from different documentation - logical devices itself are the
same.

And it is the same for superio standard.

For example sc1100 and pc87366 superio chips have the same logical
inside, 
although different logical device set.

> > And that will end up having tons of duplicated code in each driver:
> > temp monitor in A, temp monitor in B and so on...
> > volt monitor in A, volt monitor in B and so on...
> 
> There is no logical device-based duplicated code in the superio hardware
> monitoring drivers at the moment, unless you see things I do not (if you
> do please let me know). The only thing that is duplicated accross the
> drivers is the superio accesses, agreed, and I am glad that your unified
> superio driver will put an end to this.

Not only access.
Logic inside superio chip is submitted to superio standard.
I designed(at least tried to) superio subsistem
that it can handle all differencies using per device callbacks.

> > Jean, we already discussed it a bit in lm_sensors mail list AFAR...
> 
> Yes, 5 months ago, and we did not exactly agree. And we obviously still
> do not agree.
> 
> Don't get me wrong, I am not saying that I don't want your code in the
> kernel. I am actually interested in it (the base superio part, in fact).
> All I am asking for is that you put some efforts in presenting your code
> correctly, splitting it the way it has to be, and getting it into the
> kernel step by step. You are not going to get any support from me by
> pretending that the superio hardware monitoring drivers need a full
> rewrite to accomodate with your unified superio driver - because I know
> it cannot be true. If you can provide a first patchset with core superio
> driver, documentation of it, and *minimum* updates of the pc87360 driver
> to make use of it, you can be sure I will review it with great care.

I definitely will do it.
Just get me time :)

Thank you.

> Thanks,
> --
> Jean Delvare
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 15:54                           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 16:25                             ` Dmitry Torokhov
  2005-01-26 16:46                               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 16:25 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > <johnpol@2ka.mipt.ru> wrote:
> >
> > > Each superio chip has the same logical devices inside.
> > > With your approach we will have following schema:
> > >
> > > bus:
> > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > >
> > > Each logical device driver (for existing superio schema)
> > > is about(more than) 150 lines of code.
> > > With your approach above example will be 150*6*4 +
> > > 4*superio_chip_driver_size bytes
> > > of the code.
> >
> > ????? Let's count again, shall we? Suppose we have:
> > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > have 6 superio interface drivers - gpio, acb, etc...
> > It is exactly the same as your cheme size-wise.
> >
> > There is no need to many-to-many relationship. Each chip is bound to
> > only one chip driver which registers several interfaces. Each
> > interface is bound to only one interface driver. Interface driver is
> > not chip specific, it knows how to run a specific interface (gpio,
> > temp) and relies on chip driver to properly manage access to the
> > hardware. Each combination of inetrface + interface driver produce one
> > class_device (call it sio, serio, whatever). Class device provides
> > unified view of the interface to the userspace.
> >
> > What am I missing?
> 
> Since each logical device does not know who use it, it can not be,
> for example, removed optimally.
> You need to run through whole superio device set to find those one that
> has reference to logical device being removed.

What do you mean by removing optimally? Consider teher 2 scenarios:
 - you unload logical device driver which knows all the logical
devices (interfaces) it is bound to and it releases those devices.
- you unload chip driver which knows what logical devices it has
registered and removes them. Logical devices in turn unbind themselves
from the logical drivers thay are bound to (only one for each device
and they have link).
Seems pretty clean to me.

> And situation become much worse, when we have so called logical device
> clones -
> it is virtual logical device that emulates standard one, but inside
> performs
> in a different way. Clone creates inside superio device(for example such
> device
> can live at different address).
> When you do not have ldev->sc relation, you must traverse through each
> logical device
> in each superio chip to find clones.
> Thus you will need to traverse through each superio chip,
> then through each logical device it references, just to remove one
> logical device.

I am confused and need a concrete example. I would think that cases
such as these should not require eny special handling, hardware access
should be hidden from logical drivers by the chip driver. Or if only
difference is the port address then it probably should be set by the
chip driver as attribute of logical device.

Look at the serio system again. psmouse module knows how to talk to
i8042-type ports. It does not rellay matter to it whther the port is
on actual i8042 controller or somewhere else. What matters that it is
PS/2 port and it supports writes and reads and that is it. How exactly
read is performed (what port address, locking, etc) is of no concern
to psmouse. The same I think should be happening here.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 14:00                         ` Dmitry Torokhov
@ 2005-01-26 16:38                           ` Evgeniy Polyakov
  2005-01-26 18:19                             ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 16:38 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Jean Delvare, Greg KH, LKML

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

On Wed, 2005-01-26 at 09:00 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 13:59:17 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > > I have one rule - if noone answers that it means noone objects,
> > > > or it is not interesting for anyone, and thus noone objects.
> > >
> > > That's simply not true.  The amount of patches submitted is extremly
> > > huge and the reviewers don't have time to look at everythning.
> > >
> > > If no one replies it simply means no one has looked at it in enough
> > > detail to comment yet.
> > 
> > That is why I resent it several times.
> > Then I asked for inclusion.
> > 
> > I never send it to lkml just because simple static/non static + module
> > name
> > discussion in lkml already overflowed into more than 20 messages...
> 
> Well, not everyone is subscribed to lm_sensors mailing list but
> nonetheless are interested when a new subsystem is introduced into the
> kernel. There several established subsystems (network, USB, ide) whose
> maintainers people trust either because of the good track record or
> because it affects small number of people so the main discussion is
> kept on special lists. But even then most patches are presented on
> LKML when issues ironed out on special list.
> 
> With a new subsystem it is wise to present it to LKML so it gets wider coverage.
> 

Khm-khm, if we will always wait untill everyone will comment the code or
even initial
design, then nothing will be created at all.

Btw, where was comments about w1, kernel connector and acrypto? 
They were presented several times in lkml and all are completely new
subsystems.
Should I stop developing just because I did not get comments?

Above discussion was not borned because it is new subsystem, btw...


Ok, I want to thank everyone for discussion.
I believe that new subsystem must be discussed in specific mail lists
before
it goes mainstream, but not necessarily in lkml.
But if it really changes a lot of things, then of course it should be
presented 
in lkml.

Thank you.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 16:25                             ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 16:46                               ` Evgeniy Polyakov
  2005-01-26 16:55                                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 16:46 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > <johnpol@2ka.mipt.ru> wrote:
> > >
> > > > Each superio chip has the same logical devices inside.
> > > > With your approach we will have following schema:
> > > >
> > > > bus:
> > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > >
> > > > Each logical device driver (for existing superio schema)
> > > > is about(more than) 150 lines of code.
> > > > With your approach above example will be 150*6*4 +
> > > > 4*superio_chip_driver_size bytes
> > > > of the code.
> > >
> > > ????? Let's count again, shall we? Suppose we have:
> > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > have 6 superio interface drivers - gpio, acb, etc...
> > > It is exactly the same as your cheme size-wise.
> > >
> > > There is no need to many-to-many relationship. Each chip is bound to
> > > only one chip driver which registers several interfaces. Each
> > > interface is bound to only one interface driver. Interface driver is
> > > not chip specific, it knows how to run a specific interface (gpio,
> > > temp) and relies on chip driver to properly manage access to the
> > > hardware. Each combination of inetrface + interface driver produce one
> > > class_device (call it sio, serio, whatever). Class device provides
> > > unified view of the interface to the userspace.
> > >
> > > What am I missing?
> > 
> > Since each logical device does not know who use it, it can not be,
> > for example, removed optimally.
> > You need to run through whole superio device set to find those one that
> > has reference to logical device being removed.
> 
> What do you mean by removing optimally? Consider teher 2 scenarios:
>  - you unload logical device driver which knows all the logical
> devices (interfaces) it is bound to and it releases those devices.

It does not know chip drivers, which reference it.
We need to scan all superio chips to find that.

> - you unload chip driver which knows what logical devices it has
> registered and removes them. Logical devices in turn unbind themselves
> from the logical drivers thay are bound to (only one for each device
> and they have link).
> Seems pretty clean to me.

Yes, since there is sc->ldev relation.

> > And situation become much worse, when we have so called logical device
> > clones -
> > it is virtual logical device that emulates standard one, but inside
> > performs
> > in a different way. Clone creates inside superio device(for example such
> > device
> > can live at different address).
> > When you do not have ldev->sc relation, you must traverse through each
> > logical device
> > in each superio chip to find clones.
> > Thus you will need to traverse through each superio chip,
> > then through each logical device it references, just to remove one
> > logical device.
> 
> I am confused and need a concrete example. I would think that cases
> such as these should not require eny special handling, hardware access
> should be hidden from logical drivers by the chip driver. Or if only
> difference is the port address then it probably should be set by the
> chip driver as attribute of logical device.

Consider sc.c and GPIO logical device in SC1100 (scx driver).

 		/*
		 * SuperIO core is registering logical device. 
		 * SuperIO chip knows where it must live.
		 * If logical device being registered lives at the different location
		 * (for example when it was registered for all devices, 
		 * but has address(index) corresponding to only one SuperIO chip) 
		 * then we will register new logical device with the same name 
		 * but with the different location(index).
		 *
		 * It is called clone.
		 */


> Look at the serio system again. psmouse module knows how to talk to
> i8042-type ports. It does not rellay matter to it whther the port is
> on actual i8042 controller or somewhere else. What matters that it is
> PS/2 port and it supports writes and reads and that is it. How exactly
> read is performed (what port address, locking, etc) is of no concern
> to psmouse. The same I think should be happening here.

psmouse and sport are completely different example.

Consider you have mouse, that is shared between several users.
Should it have reference to each user?

Consider directory that is bind-mounted, should it have reference to
it's 
original parent tree?

Consider page, that must be swapped, should it have access to all
processes
that share it?

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 16:46                               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 16:55                                 ` Dmitry Torokhov
  2005-01-26 17:39                                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 16:55 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > <johnpol@2ka.mipt.ru> wrote:
> > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > <johnpol@2ka.mipt.ru> wrote:
> > > >
> > > > > Each superio chip has the same logical devices inside.
> > > > > With your approach we will have following schema:
> > > > >
> > > > > bus:
> > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > >
> > > > > Each logical device driver (for existing superio schema)
> > > > > is about(more than) 150 lines of code.
> > > > > With your approach above example will be 150*6*4 +
> > > > > 4*superio_chip_driver_size bytes
> > > > > of the code.
> > > >
> > > > ????? Let's count again, shall we? Suppose we have:
> > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > It is exactly the same as your cheme size-wise.
> > > >
> > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > only one chip driver which registers several interfaces. Each
> > > > interface is bound to only one interface driver. Interface driver is
> > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > temp) and relies on chip driver to properly manage access to the
> > > > hardware. Each combination of inetrface + interface driver produce one
> > > > class_device (call it sio, serio, whatever). Class device provides
> > > > unified view of the interface to the userspace.
> > > >
> > > > What am I missing?
> > >
> > > Since each logical device does not know who use it, it can not be,
> > > for example, removed optimally.
> > > You need to run through whole superio device set to find those one that
> > > has reference to logical device being removed.
> >
> > What do you mean by removing optimally? Consider teher 2 scenarios:
> >  - you unload logical device driver which knows all the logical
> > devices (interfaces) it is bound to and it releases those devices.
> 
> It does not know chip drivers, which reference it.

Of course it does, every logical device has one parent. Individual
GPIO pins are not spread across your motherboard. Every one of them
lives on some chip. They can all be driven by the same driver but they
are different devices. It is like all your IDE drives are driven by
the same driver but (unless LVM which is diffrent layer comes to play)
they are still different drives.

> We need to scan all superio chips to find that.
> 
> > - you unload chip driver which knows what logical devices it has
> > registered and removes them. Logical devices in turn unbind themselves
> > from the logical drivers thay are bound to (only one for each device
> > and they have link).
> > Seems pretty clean to me.
> 
> Yes, since there is sc->ldev relation.
> 
> > > And situation become much worse, when we have so called logical device
> > > clones -
> > > it is virtual logical device that emulates standard one, but inside
> > > performs
> > > in a different way. Clone creates inside superio device(for example such
> > > device
> > > can live at different address).
> > > When you do not have ldev->sc relation, you must traverse through each
> > > logical device
> > > in each superio chip to find clones.
> > > Thus you will need to traverse through each superio chip,
> > > then through each logical device it references, just to remove one
> > > logical device.
> >
> > I am confused and need a concrete example. I would think that cases
> > such as these should not require eny special handling, hardware access
> > should be hidden from logical drivers by the chip driver. Or if only
> > difference is the port address then it probably should be set by the
> > chip driver as attribute of logical device.
> 
> Consider sc.c and GPIO logical device in SC1100 (scx driver).
> 
>                /*
>                 * SuperIO core is registering logical device.
>                 * SuperIO chip knows where it must live.
>                 * If logical device being registered lives at the different location
>                 * (for example when it was registered for all devices,
>                 * but has address(index) corresponding to only one SuperIO chip)
>                 * then we will register new logical device with the same name
>                 * but with the different location(index).
>                 *
>                 * It is called clone.
>                 */
> 

In this sense every device is a clone. Consider I have 2 EtherExpress
cards in my box. They surely live at different addresses but PCI
system does not mess with "clones". And network layer does not care
whether both of them driven by e100 or one is e100 and the other is
RTL.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 16:55                                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 17:39                                   ` Evgeniy Polyakov
  2005-01-26 18:26                                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 17:39 UTC (permalink / raw)
  To: dtor_core; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

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

On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > <johnpol@2ka.mipt.ru> wrote:
> > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > <johnpol@2ka.mipt.ru> wrote:
> > > > >
> > > > > > Each superio chip has the same logical devices inside.
> > > > > > With your approach we will have following schema:
> > > > > >
> > > > > > bus:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > >
> > > > > > Each logical device driver (for existing superio schema)
> > > > > > is about(more than) 150 lines of code.
> > > > > > With your approach above example will be 150*6*4 +
> > > > > > 4*superio_chip_driver_size bytes
> > > > > > of the code.
> > > > >
> > > > > ????? Let's count again, shall we? Suppose we have:
> > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > It is exactly the same as your cheme size-wise.
> > > > >
> > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > only one chip driver which registers several interfaces. Each
> > > > > interface is bound to only one interface driver. Interface driver is
> > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > temp) and relies on chip driver to properly manage access to the
> > > > > hardware. Each combination of inetrface + interface driver produce one
> > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > unified view of the interface to the userspace.
> > > > >
> > > > > What am I missing?
> > > >
> > > > Since each logical device does not know who use it, it can not be,
> > > > for example, removed optimally.
> > > > You need to run through whole superio device set to find those one that
> > > > has reference to logical device being removed.
> > >
> > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > >  - you unload logical device driver which knows all the logical
> > > devices (interfaces) it is bound to and it releases those devices.
> > 
> > It does not know chip drivers, which reference it.
> 
> Of course it does, every logical device has one parent. Individual
> GPIO pins are not spread across your motherboard. Every one of them
> lives on some chip. They can all be driven by the same driver but they
> are different devices. It is like all your IDE drives are driven by
> the same driver but (unless LVM which is diffrent layer comes to play)
> they are still different drives.

No, there is no "parent".
Each logical device is "shared" between several superio chips.
It is presented design.
More below.

> > We need to scan all superio chips to find that.
> > 
> > > - you unload chip driver which knows what logical devices it has
> > > registered and removes them. Logical devices in turn unbind themselves
> > > from the logical drivers thay are bound to (only one for each device
> > > and they have link).
> > > Seems pretty clean to me.
> > 
> > Yes, since there is sc->ldev relation.
> > 
> > > > And situation become much worse, when we have so called logical device
> > > > clones -
> > > > it is virtual logical device that emulates standard one, but inside
> > > > performs
> > > > in a different way. Clone creates inside superio device(for example such
> > > > device
> > > > can live at different address).
> > > > When you do not have ldev->sc relation, you must traverse through each
> > > > logical device
> > > > in each superio chip to find clones.
> > > > Thus you will need to traverse through each superio chip,
> > > > then through each logical device it references, just to remove one
> > > > logical device.
> > >
> > > I am confused and need a concrete example. I would think that cases
> > > such as these should not require eny special handling, hardware access
> > > should be hidden from logical drivers by the chip driver. Or if only
> > > difference is the port address then it probably should be set by the
> > > chip driver as attribute of logical device.
> > 
> > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > 
> >                /*
> >                 * SuperIO core is registering logical device.
> >                 * SuperIO chip knows where it must live.
> >                 * If logical device being registered lives at the different location
> >                 * (for example when it was registered for all devices,
> >                 * but has address(index) corresponding to only one SuperIO chip)
> >                 * then we will register new logical device with the same name
> >                 * but with the different location(index).
> >                 *
> >                 * It is called clone.
> >                 */
> > 
> 
> In this sense every device is a clone. Consider I have 2 EtherExpress
> cards in my box. They surely live at different addresses but PCI
> system does not mess with "clones". And network layer does not care
> whether both of them driven by e100 or one is e100 and the other is
> RTL.

It is not the same as two different devices on the bus.

Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
superio lives.
(And it is actully not logical device in this case, but it fits well
into design).


You skipped my examples, but presented design is very convenient to the
situation,
when you have two different sets of devices, or classes of devices, each
of which
can have link to any device from the other set.

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 10:59                       ` Evgeniy Polyakov
  2005-01-26 14:00                         ` Dmitry Torokhov
@ 2005-01-26 18:06                         ` Adrian Bunk
  1 sibling, 0 replies; 152+ messages in thread
From: Adrian Bunk @ 2005-01-26 18:06 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Christoph Hellwig, Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 01:59:17PM +0300, Evgeniy Polyakov wrote:
> On Wed, 2005-01-26 at 10:14 +0000, Christoph Hellwig wrote:
> > On Wed, Jan 26, 2005 at 01:35:56AM +0300, Evgeniy Polyakov wrote:
> > > I have one rule - if noone answers that it means noone objects,
> > > or it is not interesting for anyone, and thus noone objects.
> > 
> > That's simply not true.  The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> > 
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
> 
> That is why I resent it several times.
> Then I asked for inclusion.
> 
> I never send it to lkml just because simple static/non static + module
> name
> discussion in lkml already overflowed into more than 20 messages...

Your opinion on some things are different than the opinions of other 
people on some issues. That's normal.

Then a discussion arises.
That's normal and part of a review of some code.
E.g. the "module name discussion" covered a real problem.

Be it 1 email or be it 100 emails - the main point is simply that all 
code in the kernel should be as good as possible and as near as possible 
to kernel standards.

The Linux kernel is a big project with _many_ people involved.
I've also had people telling me that this or that I sent in a patch was 
nonsense. That's normal (and a criticism of your code is not meant as a 
personal insult) and leads to better code in the kernel.

>         Evgeniy Polyakov

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 16:38                           ` Evgeniy Polyakov
@ 2005-01-26 18:19                             ` Adrian Bunk
  2005-01-26 19:27                               ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-26 18:19 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: dtor_core, Christoph Hellwig, Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
>...
> Btw, where was comments about w1, kernel connector and acrypto? 
> They were presented several times in lkml and all are completely new
> subsystems.
> Should I stop developing just because I did not get comments?
>...

I sent you comments regarding w1 two months ago regarding:
- the unneeded dscore -> ds9490r rename in the Makefile
- completely unused EXPORT_SYMBOL's (that seem to be still unused today)

Being honest, I have to admit that your reactions didn't sound as if you 
were waiting for comments.

> Thank you.
> 
>         Evgeniy Polyakov

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 17:39                                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 18:26                                     ` Dmitry Torokhov
  2005-01-26 20:07                                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 18:26 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 20:39:36 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> On Wed, 2005-01-26 at 11:55 -0500, Dmitry Torokhov wrote:
> > On Wed, 26 Jan 2005 19:46:14 +0300, Evgeniy Polyakov
> > <johnpol@2ka.mipt.ru> wrote:
> > > On Wed, 2005-01-26 at 11:25 -0500, Dmitry Torokhov wrote:
> > > > On Wed, 26 Jan 2005 18:54:08 +0300, Evgeniy Polyakov
> > > > <johnpol@2ka.mipt.ru> wrote:
> > > > > On Wed, 2005-01-26 at 10:26 -0500, Dmitry Torokhov wrote:
> > > > > > On Wed, 26 Jan 2005 17:59:07 +0300, Evgeniy Polyakov
> > > > > > <johnpol@2ka.mipt.ru> wrote:
> > > > > >
> > > > > > > Each superio chip has the same logical devices inside.
> > > > > > > With your approach we will have following schema:
> > > > > > >
> > > > > > > bus:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio3 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio4 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > >
> > > > > > > Each logical device driver (for existing superio schema)
> > > > > > > is about(more than) 150 lines of code.
> > > > > > > With your approach above example will be 150*6*4 +
> > > > > > > 4*superio_chip_driver_size bytes
> > > > > > > of the code.
> > > > > >
> > > > > > ????? Let's count again, shall we? Suppose we have:
> > > > > > > superio1 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > > superio2 - voltage, temp, gpio, rtc, wdt, acb
> > > > > > superio1 is driven by scx200 hardware, superio2 is driven by pc8736x
> > > > > > or whatever. So here, you have 2 drivers to manage chips. Plus you
> > > > > > have 6 superio interface drivers - gpio, acb, etc...
> > > > > > It is exactly the same as your cheme size-wise.
> > > > > >
> > > > > > There is no need to many-to-many relationship. Each chip is bound to
> > > > > > only one chip driver which registers several interfaces. Each
> > > > > > interface is bound to only one interface driver. Interface driver is
> > > > > > not chip specific, it knows how to run a specific interface (gpio,
> > > > > > temp) and relies on chip driver to properly manage access to the
> > > > > > hardware. Each combination of inetrface + interface driver produce one
> > > > > > class_device (call it sio, serio, whatever). Class device provides
> > > > > > unified view of the interface to the userspace.
> > > > > >
> > > > > > What am I missing?
> > > > >
> > > > > Since each logical device does not know who use it, it can not be,
> > > > > for example, removed optimally.
> > > > > You need to run through whole superio device set to find those one that
> > > > > has reference to logical device being removed.
> > > >
> > > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > >  - you unload logical device driver which knows all the logical
> > > > devices (interfaces) it is bound to and it releases those devices.
> > >
> > > It does not know chip drivers, which reference it.
> >
> > Of course it does, every logical device has one parent. Individual
> > GPIO pins are not spread across your motherboard. Every one of them
> > lives on some chip. They can all be driven by the same driver but they
> > are different devices. It is like all your IDE drives are driven by
> > the same driver but (unless LVM which is diffrent layer comes to play)
> > they are still different drives.
> 
> No, there is no "parent".
> Each logical device is "shared" between several superio chips.
> It is presented design.

Ok, I presume that userspace although you saying that logical device
is "shared" between chips different GPIO pins still visible to
userspace as separate entities (correct me if I am wrong). That means
that you chose in your implementation not to abstract out individual
parts of SuperIO container as individual devices and instead have
several logical drivers bound directly to a same chip. And that is why
you need n-m relationship and inability to fit to the driver model and
potential issues with power management. Instead of this

                                                      / <ldev>
 <base-dev (PCI|ISA|other)> - <sdev> - <ldev>
                                                     \ <ldev>

you need this

                                        /<sdev> - <ldev>
<base-dev (PCI|ISA|other)> - <sdev> - <ldev>
                                        \ <sdev> - <ldev>

This will decouple chip drivers from the logical drivers.

I argue that present design is sub-optimal and will hurt in the long run.

> 
> > > We need to scan all superio chips to find that.
> > >
> > > > - you unload chip driver which knows what logical devices it has
> > > > registered and removes them. Logical devices in turn unbind themselves
> > > > from the logical drivers thay are bound to (only one for each device
> > > > and they have link).
> > > > Seems pretty clean to me.
> > >
> > > Yes, since there is sc->ldev relation.
> > >
> > > > > And situation become much worse, when we have so called logical device
> > > > > clones -
> > > > > it is virtual logical device that emulates standard one, but inside
> > > > > performs
> > > > > in a different way. Clone creates inside superio device(for example such
> > > > > device
> > > > > can live at different address).
> > > > > When you do not have ldev->sc relation, you must traverse through each
> > > > > logical device
> > > > > in each superio chip to find clones.
> > > > > Thus you will need to traverse through each superio chip,
> > > > > then through each logical device it references, just to remove one
> > > > > logical device.
> > > >
> > > > I am confused and need a concrete example. I would think that cases
> > > > such as these should not require eny special handling, hardware access
> > > > should be hidden from logical drivers by the chip driver. Or if only
> > > > difference is the port address then it probably should be set by the
> > > > chip driver as attribute of logical device.
> > >
> > > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > >
> > >                /*
> > >                 * SuperIO core is registering logical device.
> > >                 * SuperIO chip knows where it must live.
> > >                 * If logical device being registered lives at the different location
> > >                 * (for example when it was registered for all devices,
> > >                 * but has address(index) corresponding to only one SuperIO chip)
> > >                 * then we will register new logical device with the same name
> > >                 * but with the different location(index).
> > >                 *
> > >                 * It is called clone.
> > >                 */
> > >
> >
> > In this sense every device is a clone. Consider I have 2 EtherExpress
> > cards in my box. They surely live at different addresses but PCI
> > system does not mess with "clones". And network layer does not care
> > whether both of them driven by e100 or one is e100 and the other is
> > RTL.
> 
> It is not the same as two different devices on the bus.
> 
> Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
> superio lives.
> (And it is actully not logical device in this case, but it fits well
> into design).

It does not matter where it "lives". The chip driver should not expose
these details to interface driver. Although you said serio examples
are not applicable here let's take another look there: i8042 and
pcips2 modules. One provides serio ports that live in legacy IO space,
the other is PCI-based. psmouse would not care less which one is
behind the port it is bound to.

> 
> You skipped my examples, but presented design is very convenient to the
> situation,
> when you have two different sets of devices, or classes of devices, each
> of which
> can have link to any device from the other set.

They were from different domains so irrelevant.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 16:10                           ` Evgeniy Polyakov
@ 2005-01-26 19:20                             ` Jean Delvare
  2005-01-26 20:21                               ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Jean Delvare @ 2005-01-26 19:20 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: Greg KH, LKML

[Voluntarily skipping a large part of the discussion so as to stop
wasting everyone's time and focus on the one technical point I am
interested in.]

Hi Evgeniy,

> As I saw from different documentation - logical devices itself are the
> same.
> 
> And it is the same for superio standard.
> 
> For example sc1100 and pc87366 superio chips have the same logical
> inside, although different logical device set.
> 
> (...)
> 
> Not only access.
> Logic inside superio chip is submitted to superio standard.
> I designed(at least tried to) superio subsistem
> that it can handle all differencies using per device callbacks.

I would like to ensure that we agree on what is common to all Super-I/O
chips (as per Intel's LPC specification).

1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
addresses 0x4e+0x4f.

2* These addresses give access to a 256 byte addressing space.

3* Super-I/O chips are divided in logical devices, which can be selected
by writing its id to 0x07. What each logical device does is not
standardized (depends of the chip).

4* Range 0x00-0x2f is common to all logical devices, while range
0x30-0xff is logical-device specific.

5* Range 0x20-0x2f contains chip-wide identification and configuration
registers. Definition of these registers is not standardized.

6* 0x31 controls the activation of each logical device, 0x60-0x63 its
base address, 0x70-0x73 its interrupts. Definition of these registers is
standardized.

7* Range 0xf0-0xff contains logical device-specific configuration
registers. Definition of these registers is not standardized.

And that's about it. The way each logical device works (how registers
are mapped from the base address) is completely chip-specific.

Do we agree on all this, or did I miss somthing? I would like to make
sure that, when you refer to sharing as much code as possible between
the various Super-I/O chips, you really mean the organization of logical
devices within the Super-I/O (selection, retrieval of base address and
interrupt configuration) and not the logical devices themselves.

Thanks,
-- 
Jean Delvare
http://khali.linux-fr.org/

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 18:19                             ` Adrian Bunk
@ 2005-01-26 19:27                               ` Evgeniy Polyakov
  2005-01-27 10:20                                 ` Adrian Bunk
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 19:27 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: dtor_core, Christoph Hellwig, Jean Delvare, Greg KH, LKML

On Wed, 26 Jan 2005 19:19:41 +0100
Adrian Bunk <bunk@stusta.de> wrote:

> On Wed, Jan 26, 2005 at 07:38:48PM +0300, Evgeniy Polyakov wrote:
> >...
> > Btw, where was comments about w1, kernel connector and acrypto? 
> > They were presented several times in lkml and all are completely new
> > subsystems.
> > Should I stop developing just because I did not get comments?
> >...
> 
> I sent you comments regarding w1 two months ago regarding:
> - the unneeded dscore -> ds9490r rename in the Makefile
> - completely unused EXPORT_SYMBOL's (that seem to be still unused today)
> 
> Being honest, I have to admit that your reactions didn't sound as if you 
> were waiting for comments.
> 
> > Thank you.

I greatly appreciate your comments, and they were addressed.
Part of exported symbols are unexported, patch is just waiting to be sent,
but I do not agree with dscore rename. I just do not understand it's advantage.

> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 13:12                       ` Russell King
@ 2005-01-26 20:01                         ` Christoph Hellwig
  0 siblings, 0 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-26 20:01 UTC (permalink / raw)
  To: Christoph Hellwig, Evgeniy Polyakov, Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 01:12:34PM +0000, Russell King wrote:
> On Wed, Jan 26, 2005 at 10:14:34AM +0000, Christoph Hellwig wrote:
> > That's simply not true.  The amount of patches submitted is extremly
> > huge and the reviewers don't have time to look at everythning.
> > 
> > If no one replies it simply means no one has looked at it in enough
> > detail to comment yet.
> 
> How do people get to know this?  Grape vines and crystal balls are
> inherently unreliable.

If someone had looked and considered it good he'd have replied and
said that.  Simple ACK/NACK scheme - if neither returns consider it
lost.

> So, if the community has a problem with enough time to review patches,
> the community must get more (good) patch reviewers.  We can't go around
> blaming the patch submitters for a community failing.

Absolutely.  I think the major problem is that no one pays people for
doing reviews so this is purely a spare-time job.  And that spare time
is limited due to real life issues for most people.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 18:26                                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-26 20:07                                       ` Evgeniy Polyakov
  2005-01-26 20:22                                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 20:07 UTC (permalink / raw)
  To: dtor_core
  Cc: dmitry.torokhov, Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 13:26:38 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > > > > > Since each logical device does not know who use it, it can not be,
> > > > > > for example, removed optimally.
> > > > > > You need to run through whole superio device set to find those one that
> > > > > > has reference to logical device being removed.
> > > > >
> > > > > What do you mean by removing optimally? Consider teher 2 scenarios:
> > > > >  - you unload logical device driver which knows all the logical
> > > > > devices (interfaces) it is bound to and it releases those devices.
> > > >
> > > > It does not know chip drivers, which reference it.
> > >
> > > Of course it does, every logical device has one parent. Individual
> > > GPIO pins are not spread across your motherboard. Every one of them
> > > lives on some chip. They can all be driven by the same driver but they
> > > are different devices. It is like all your IDE drives are driven by
> > > the same driver but (unless LVM which is diffrent layer comes to play)
> > > they are still different drives.
> > 
> > No, there is no "parent".
> > Each logical device is "shared" between several superio chips.
> > It is presented design.
> 
> Ok, I presume that userspace although you saying that logical device
> is "shared" between chips different GPIO pins still visible to
> userspace as separate entities (correct me if I am wrong). That means
> that you chose in your implementation not to abstract out individual
> parts of SuperIO container as individual devices and instead have
> several logical drivers bound directly to a same chip. And that is why
> you need n-m relationship and inability to fit to the driver model and
> potential issues with power management. Instead of this

Userspace has access to GPIO logical device by it's name 
and name of the superio chip it is connected to.
 
>                                                       / <ldev>
>  <base-dev (PCI|ISA|other)> - <sdev> - <ldev>
>                                                      \ <ldev>
> 
> you need this
> 
>                                         /<sdev> - <ldev>
> <base-dev (PCI|ISA|other)> - <sdev> - <ldev>
>                                         \ <sdev> - <ldev>
> 
> This will decouple chip drivers from the logical drivers.
> 
> I argue that present design is sub-optimal and will hurt in the long run.


This picture is somewhat better presents superio design:

sdev           sdev
  |-----| |-----|
ldev   ldev   ldev

Where |---| links are bidirectional.

Probably you are right, but I doubt :)

> > > > We need to scan all superio chips to find that.
> > > >
> > > > > - you unload chip driver which knows what logical devices it has
> > > > > registered and removes them. Logical devices in turn unbind themselves
> > > > > from the logical drivers thay are bound to (only one for each device
> > > > > and they have link).
> > > > > Seems pretty clean to me.
> > > >
> > > > Yes, since there is sc->ldev relation.
> > > >
> > > > > > And situation become much worse, when we have so called logical device
> > > > > > clones -
> > > > > > it is virtual logical device that emulates standard one, but inside
> > > > > > performs
> > > > > > in a different way. Clone creates inside superio device(for example such
> > > > > > device
> > > > > > can live at different address).
> > > > > > When you do not have ldev->sc relation, you must traverse through each
> > > > > > logical device
> > > > > > in each superio chip to find clones.
> > > > > > Thus you will need to traverse through each superio chip,
> > > > > > then through each logical device it references, just to remove one
> > > > > > logical device.
> > > > >
> > > > > I am confused and need a concrete example. I would think that cases
> > > > > such as these should not require eny special handling, hardware access
> > > > > should be hidden from logical drivers by the chip driver. Or if only
> > > > > difference is the port address then it probably should be set by the
> > > > > chip driver as attribute of logical device.
> > > >
> > > > Consider sc.c and GPIO logical device in SC1100 (scx driver).
> > > >
> > > >                /*
> > > >                 * SuperIO core is registering logical device.
> > > >                 * SuperIO chip knows where it must live.
> > > >                 * If logical device being registered lives at the different location
> > > >                 * (for example when it was registered for all devices,
> > > >                 * but has address(index) corresponding to only one SuperIO chip)
> > > >                 * then we will register new logical device with the same name
> > > >                 * but with the different location(index).
> > > >                 *
> > > >                 * It is called clone.
> > > >                 */
> > > >
> > >
> > > In this sense every device is a clone. Consider I have 2 EtherExpress
> > > cards in my box. They surely live at different addresses but PCI
> > > system does not mess with "clones". And network layer does not care
> > > whether both of them driven by e100 or one is e100 and the other is
> > > RTL.
> > 
> > It is not the same as two different devices on the bus.
> > 
> > Consider sc1100 - GPIO lives in PCI aperture, absolutely not where
> > superio lives.
> > (And it is actully not logical device in this case, but it fits well
> > into design).
> 
> It does not matter where it "lives". The chip driver should not expose
> these details to interface driver. Although you said serio examples
> are not applicable here let's take another look there: i8042 and
> pcips2 modules. One provides serio ports that live in legacy IO space,
> the other is PCI-based. psmouse would not care less which one is
> behind the port it is bound to.

Chip driver provides access methods to the attached logical devices.
It probes and activates them, if appropriate module is loaded.

Your example again is not suitable for superio case.

With superio you have several identical logical devices, access to which
is absolutely standard in second level(logic befind access), 
but in first one(physicall access) it can differ.

So here is the real example of superio usage:

     userspace
        |
    superio core
      ......

       GPIO
  |----|  |--|
pc87366     sc1100
  |----| |---|
       WDT

Logical device GPIO is accessed by read/write methods, which only have
pin number(it is not how this methods are exactly implemeted though)
as parameter.

For example userspace accesses GPIO at sc1100 - it will be translated
into read methods called from appropriate superio chip with appropriate
parameters.

When we have multiple GPIO logical devices(each in it's own superio chip)
it is more convenient to use just the same object.


I did not understand you from the beginning...
It can be turned into device model quite well, only individual objects
should have backward references to allow easier manipulation with it's
"owners". Your above schema with device model is quite right, just add
invisible links from each device to/from it's "masters".

> 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 19:20                             ` Jean Delvare
@ 2005-01-26 20:21                               ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-26 20:21 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Greg KH, LKML

On Wed, 26 Jan 2005 20:20:27 +0100
Jean Delvare <khali@linux-fr.org> wrote:

> [Voluntarily skipping a large part of the discussion so as to stop
> wasting everyone's time and focus on the one technical point I am
> interested in.]
> 
> Hi Evgeniy,
> 
> > As I saw from different documentation - logical devices itself are the
> > same.
> > 
> > And it is the same for superio standard.
> > 
> > For example sc1100 and pc87366 superio chips have the same logical
> > inside, although different logical device set.
> > 
> > (...)
> > 
> > Not only access.
> > Logic inside superio chip is submitted to superio standard.
> > I designed(at least tried to) superio subsistem
> > that it can handle all differencies using per device callbacks.
> 
> I would like to ensure that we agree on what is common to all Super-I/O
> chips (as per Intel's LPC specification).
> 
> 1* Super-I/O are accessed at I/O addresses 0x2e+0x2f or alternate
> addresses 0x4e+0x4f.
> 
> 2* These addresses give access to a 256 byte addressing space.
> 
> 3* Super-I/O chips are divided in logical devices, which can be selected
> by writing its id to 0x07. What each logical device does is not
> standardized (depends of the chip).
> 
> 4* Range 0x00-0x2f is common to all logical devices, while range
> 0x30-0xff is logical-device specific.
> 
> 5* Range 0x20-0x2f contains chip-wide identification and configuration
> registers. Definition of these registers is not standardized.
> 
> 6* 0x31 controls the activation of each logical device, 0x60-0x63 its
> base address, 0x70-0x73 its interrupts. Definition of these registers is
> standardized.
> 
> 7* Range 0xf0-0xff contains logical device-specific configuration
> registers. Definition of these registers is not standardized.
> 
> And that's about it. The way each logical device works (how registers
> are mapped from the base address) is completely chip-specific.
> 
> Do we agree on all this, or did I miss somthing? I would like to make
> sure that, when you refer to sharing as much code as possible between
> the various Super-I/O chips, you really mean the organization of logical
> devices within the Super-I/O (selection, retrieval of base address and
> interrupt configuration) and not the logical devices themselves.

You are absolutely right, I just want to add following note:

Most of the logical devices inside superio chips has standardized access methods.
One just need base address and index, that is all.
For such devices all infrastructure already exists in the provided superio core.
One just need to provide one logical device driver for it(like sc_gpio.c).

But, sometimes it really can be the situation, when logical device is not
obeyed to rules in the existing logical device driver(like GPIO in sc1100, which is
not superio logical device but is fitted design quite well), for such
cases there is also infrastructure in superio driver. For example scx.c -
it has it's own private GPIO logical device, which is "cloned" from the
"standard"(described in sc_gpio.c) logical device(clones actully have 
almost nothing in common).

Situation with device cloning is very unlikely according to various superio
chips I saw and read datasheets.
 
> Thanks,
> -- 
> Jean Delvare
> http://khali.linux-fr.org/


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 20:07                                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
@ 2005-01-26 20:22                                         ` Dmitry Torokhov
  2005-01-27 17:33                                           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Dmitry Torokhov @ 2005-01-26 20:22 UTC (permalink / raw)
  To: johnpol; +Cc: Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
<johnpol@2ka.mipt.ru> wrote:
> 
> Chip driver provides access methods to the attached logical devices.
> It probes and activates them, if appropriate module is loaded.
> 
> Your example again is not suitable for superio case.
> 
> With superio you have several identical logical devices, access to which
> is absolutely standard in second level(logic befind access),
> but in first one(physicall access) it can differ.
> 
> So here is the real example of superio usage:
> 
>     userspace
>        |
>    superio core
>      ......
> 
>       GPIO
>  |----|  |--|
> pc87366     sc1100
>  |----| |---|
>       WDT
> 
> Logical device GPIO is accessed by read/write methods, which only have
> pin number(it is not how this methods are exactly implemeted though)
> as parameter.
> 
> For example userspace accesses GPIO at sc1100 - it will be translated
> into read methods called from appropriate superio chip with appropriate
> parameters.
> 
> When we have multiple GPIO logical devices(each in it's own superio chip)
> it is more convenient to use just the same object.

I take an exception to that. I think useroace is not concerned with
topology and ownership of logical devices, the data is more important.
I.e. you need to know that some pin respons to CPU temperature but you
don't really care that it connected to it87 as opposed to some other
chip. Therefore I think that ldev should translate to exactly the same
underlying object. Consider the picture below:

        GPIO0     GPIO1   GPIO2 GPIO3
          |         |       |     |
       pc87266   sc1100     blah123
          |         |
         WDT0      WDT1

This will allow:
- map every hardware piece (not entire chip, separate functions) to a
device file to userspace can use standard read/write/select/poll if
choses so.
- easily represent them in sysfs and also allow userspace access to
individual bits through sysfs attributes.
- will not give headaches with poer management when half of device is
powered down and half is active.
- provided that there are alternative interfaces outlined above
superio can be decoupled from the connector.

I wonder if it should be called "gpio" bus as opposed to superio
because only chips are "super", the bus consists of very simple
devices and drivers.

> I did not understand you from the beginning...

We are getting there I believe ;) 

-- 
Dmitry

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
                       ` (21 preceding siblings ...)
  2005-01-26  4:44     ` [PATCH] ppc64: fix use kref for device_node refcounting Nathan Lynch
@ 2005-01-27  6:18     ` William Lee Irwin III
  2005-01-27  9:14       ` 2.6.11-rc2-mm1 William Lee Irwin III
  22 siblings, 1 reply; 152+ messages in thread
From: William Lee Irwin III @ 2005-01-27  6:18 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc1/2.6.11-rc1-mm1/
> - Lots of updates and fixes all over the place.
> - On my test box there is no flashing cursor on the vga console.  Known bug,
>   please don't report it.
>   Binary searching shows that the bug was introduced by
>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

autofs has exploded far, far beyond complete nonfunctionality, where
in prior 2.6.x it was not quite so blatantly a doorstop preventing all
logins on the machine, and, in fact, multiuser mode altogether.

Whoever's responsible, prepare to be flamed to a crisp the likes of
which has never been witnessed before by observers of solar probes, nor
conceived of by the most visionary and imaginative of eschatologists.


-- wli

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-27  6:18     ` 2.6.11-rc2-mm1 William Lee Irwin III
@ 2005-01-27  9:14       ` William Lee Irwin III
  0 siblings, 0 replies; 152+ messages in thread
From: William Lee Irwin III @ 2005-01-27  9:14 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel

On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
>> - Lots of updates and fixes all over the place.
>> - On my test box there is no flashing cursor on the vga console.  Known bug,
>>   please don't report it.
>>   Binary searching shows that the bug was introduced by
>>   cleanup-vc-array-access.patch but that patch is, unfortunately, huge.

On Wed, Jan 26, 2005 at 10:18:57PM -0800, William Lee Irwin III wrote:
> autofs has exploded far, far beyond complete nonfunctionality, where
> in prior 2.6.x it was not quite so blatantly a doorstop preventing all
> logins on the machine, and, in fact, multiuser mode altogether.
> Whoever's responsible, prepare to be flamed to a crisp the likes of
> which has never been witnessed before by observers of solar probes, nor
> conceived of by the most visionary and imaginative of eschatologists.

Looks like I just need to smack the hands of whoever blew away modutils.
I worked around this properly, by fully demodularizing the kernel.
Anyway, thus far ppc64 comes up clean with no patches, ia64 comes up
clean with clameter's mmtimer patch. Other arches pending.


-- wli

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-26 19:27                               ` Evgeniy Polyakov
@ 2005-01-27 10:20                                 ` Adrian Bunk
  2005-01-27 11:53                                   ` Evgeniy Polyakov
  0 siblings, 1 reply; 152+ messages in thread
From: Adrian Bunk @ 2005-01-27 10:20 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: dtor_core, Christoph Hellwig, Jean Delvare, Greg KH, LKML

On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
>...
> I greatly appreciate your comments, and they were addressed.
> Part of exported symbols are unexported, patch is just waiting to be sent,

Ah, sorry. I only saw that the patch I sent two months ago still 
applies completely (except for an unrelated context change).

> but I do not agree with dscore rename. I just do not understand it's advantage.

It is only a small cosmetic thing:
If there's only one object file in a module, a renaming in the Makefile 
is superfluous - you can simply rename the source file

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-27 10:20                                 ` Adrian Bunk
@ 2005-01-27 11:53                                   ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-27 11:53 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: dtor_core, Christoph Hellwig, Jean Delvare, Greg KH, LKML

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

On Thu, 2005-01-27 at 11:20 +0100, Adrian Bunk wrote:
> On Wed, Jan 26, 2005 at 10:27:43PM +0300, Evgeniy Polyakov wrote:
> >...
> > I greatly appreciate your comments, and they were addressed.
> > Part of exported symbols are unexported, patch is just waiting to be sent,
> 
> Ah, sorry. I only saw that the patch I sent two months ago still 
> applies completely (except for an unrelated context change).

Patch is alredy sent, but probably it will not apper in the nearest -mm
release.

> > but I do not agree with dscore rename. I just do not understand it's advantage.
> 
> It is only a small cosmetic thing:
> If there's only one object file in a module, a renaming in the Makefile 
> is superfluous - you can simply rename the source file

Most of it's exports are preparation for EEPROM driver, which will
require
some changes in w1 core(it needs to export additional callbacks).

I'm currently review DS device set to find any dependency upon ds2490
chip - 
but it looks like there is no one, so it is alredy not core, but device
driver
itlself.

I'm not too religious about it's name...

> cu
> Adrian
> 
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

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

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-24 18:43       ` Evgeniy Polyakov
  2005-01-24 18:29         ` Adrian Bunk
  2005-01-24 18:41         ` Jurriaan
@ 2005-01-27 15:19         ` Bill Davidsen
  2005-01-27 16:21           ` Evgeniy Polyakov
  2 siblings, 1 reply; 152+ messages in thread
From: Bill Davidsen @ 2005-01-27 15:19 UTC (permalink / raw)
  To: johnpol; +Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

Evgeniy Polyakov wrote:
> On Mon, 24 Jan 2005 18:54:49 +0100
> Adrian Bunk <bunk@stusta.de> wrote:
> 
> 
>>It seems noone who reviewed the SuperIO patches noticed that there are 
>>now two modules "scx200" in the kernel...
> 
> 
> They are almost mutually exlusive(SuperIO contains more advanced), 
> so I do not see any problem here.
> Only one of them can be loaded in a time.
> 
> So what does exactly bother you?
>
That I don't know how to select loading between modules with the same 
name. What's the trick?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
  2005-01-25  7:31       ` Miklos Szeredi
@ 2005-01-27 15:45       ` Bill Davidsen
  2005-01-27 15:56         ` Sytse Wielinga
  2005-01-27 18:09       ` Christoph Hellwig
  2 siblings, 1 reply; 152+ messages in thread
From: Bill Davidsen @ 2005-01-27 15:45 UTC (permalink / raw)
  To: Sytse Wielinga; +Cc: Andrew Morton, linux-kernel

Sytse Wielinga wrote:
> Hi Andrew,
> 
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> 
>>fuse-transfer-readdir-data-through-device.patch
>>  fuse: transfer readdir data through device
> 
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:
> 
> open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> not implemented)
> 
> As I personally like for my ls to keep on working, and I assume others will,
> too, I would appreciate it if you could add a warning to your announcements the
> following one or two weeks or so, so that people can remove this patch if they
> don't want to update their libs.

By any chance would this also break perl programs which readdir?

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-27 15:45       ` Bill Davidsen
@ 2005-01-27 15:56         ` Sytse Wielinga
  2005-01-27 16:11           ` Miklos Szeredi
  0 siblings, 1 reply; 152+ messages in thread
From: Sytse Wielinga @ 2005-01-27 15:56 UTC (permalink / raw)
  To: Bill Davidsen; +Cc: Andrew Morton, linux-kernel

On Thu, Jan 27, 2005 at 10:45:09AM -0500, Bill Davidsen wrote:
> Sytse Wielinga wrote:
> >It is great that this is fixed, don't remove it, but it does require the fuse
> >libs to be updated at the same time, or opening dirs for listings will break
> >like this:
> >
> >open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOSYS (Function
> >not implemented)
> >
> >As I personally like for my ls to keep on working, and I assume others will,
> >too, I would appreciate it if you could add a warning to your announcements the
> >following one or two weeks or so, so that people can remove this patch if they
> >don't want to update their libs.
> 
> By any chance would this also break perl programs which readdir?

Of course; I haven't tested it, but the actual ioctls aren't working anymore,
so it's not even _possible_ to get them to work with this patch and an old
version of the fuse libs, even with perl bindings, which go through the fuse
libs anyway.

    Sytse

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-27 15:56         ` Sytse Wielinga
@ 2005-01-27 16:11           ` Miklos Szeredi
  0 siblings, 0 replies; 152+ messages in thread
From: Miklos Szeredi @ 2005-01-27 16:11 UTC (permalink / raw)
  To: s.b.wielinga; +Cc: davidsen, akpm, linux-kernel


> > >As I personally like for my ls to keep on working, and I assume
> > >others will, too, I would appreciate it if you could add a
> > >warning to your announcements the following one or two weeks or
> > >so, so that people can remove this patch if they don't want to
> > >update their libs.
> > 
> > By any chance would this also break perl programs which readdir?
> 
> Of course; I haven't tested it, but the actual ioctls aren't working
> anymore, so it's not even _possible_ to get them to work with this
> patch and an old version of the fuse libs, even with perl bindings,
> which go through the fuse libs anyway.

First, a little clarification: FUSE doesn't use ioctl() for
communication between the kernel and userspace.  It uses read() and
write().

That aside, you are right, that this change breaks any kind of FUSE
based filesystem.  However the fix is trivial: install FUSE version
2.2-pre5 or later.  The filesystems themselves don't need to be
rebuilt, since the fix in the shared library will automatically get
used.

Thanks,
Miklos


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-27 15:19         ` Bill Davidsen
@ 2005-01-27 16:21           ` Evgeniy Polyakov
  2005-01-27 23:12             ` Bill Davidsen
  0 siblings, 1 reply; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-27 16:21 UTC (permalink / raw)
  To: Bill Davidsen
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Thu, 27 Jan 2005 10:19:51 -0500
Bill Davidsen <davidsen@tmr.com> wrote:

> Evgeniy Polyakov wrote:
> > On Mon, 24 Jan 2005 18:54:49 +0100
> > Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > 
> >>It seems noone who reviewed the SuperIO patches noticed that there are 
> >>now two modules "scx200" in the kernel...
> > 
> > 
> > They are almost mutually exlusive(SuperIO contains more advanced), 
> > so I do not see any problem here.
> > Only one of them can be loaded in a time.
> > 
> > So what does exactly bother you?
> >
> That I don't know how to select loading between modules with the same 
> name. What's the trick?

Use full path.
Please see discussion in this thread related to module names.
 
> -- 
>     -bill davidsen (davidsen@tmr.com)
> "The secret to procrastination is to put things off until the
>   last possible moment - but no longer"  -me


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-26 20:22                                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
@ 2005-01-27 17:33                                           ` Evgeniy Polyakov
  0 siblings, 0 replies; 152+ messages in thread
From: Evgeniy Polyakov @ 2005-01-27 17:33 UTC (permalink / raw)
  To: dtor_core
  Cc: dmitry.torokhov, Christoph Hellwig, Andrew Morton, greg, linux-kernel

On Wed, 26 Jan 2005 15:22:52 -0500
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> On Wed, 26 Jan 2005 23:07:12 +0300, Evgeniy Polyakov
> <johnpol@2ka.mipt.ru> wrote:
> > 
> > Chip driver provides access methods to the attached logical devices.
> > It probes and activates them, if appropriate module is loaded.
> > 
> > Your example again is not suitable for superio case.
> > 
> > With superio you have several identical logical devices, access to which
> > is absolutely standard in second level(logic befind access),
> > but in first one(physicall access) it can differ.
> > 
> > So here is the real example of superio usage:
> > 
> >     userspace
> >        |
> >    superio core
> >      ......
> > 
> >       GPIO
> >  |----|  |--|
> > pc87366     sc1100
> >  |----| |---|
> >       WDT
> > 
> > Logical device GPIO is accessed by read/write methods, which only have
> > pin number(it is not how this methods are exactly implemeted though)
> > as parameter.
> > 
> > For example userspace accesses GPIO at sc1100 - it will be translated
> > into read methods called from appropriate superio chip with appropriate
> > parameters.
> > 
> > When we have multiple GPIO logical devices(each in it's own superio chip)
> > it is more convenient to use just the same object.
> 
> I take an exception to that. I think useroace is not concerned with
> topology and ownership of logical devices, the data is more important.
> I.e. you need to know that some pin respons to CPU temperature but you
> don't really care that it connected to it87 as opposed to some other
> chip. Therefore I think that ldev should translate to exactly the same
> underlying object. Consider the picture below:
> 
>         GPIO0     GPIO1   GPIO2 GPIO3
>           |         |       |     |
>        pc87266   sc1100     blah123
>           |         |
>          WDT0      WDT1
> 
> This will allow:
> - map every hardware piece (not entire chip, separate functions) to a
> device file to userspace can use standard read/write/select/poll if
> choses so.
> - easily represent them in sysfs and also allow userspace access to
> individual bits through sysfs attributes.
> - will not give headaches with poer management when half of device is
> powered down and half is active.
> - provided that there are alternative interfaces outlined above
> superio can be decoupled from the connector.

With presented design we already have above links.
Each superio chip has a list of chain objects, each of which points to
the connected logical device.
Logical device usage must be done using provided logical device methods
(like read/write/control).
>From that point of view noone even knows, that above GPIO0 and GPIO1 
(on the picture) are actually the same object(if they are not clones,
but if they are, then picture becomes 100% real).

> I wonder if it should be called "gpio" bus as opposed to superio
> because only chips are "super", the bus consists of very simple
> devices and drivers.

I can not agree that it is a bus.
Bus abstraction can be _only_ applied to hierarchy in the only one
superio chip.

> > I did not understand you from the beginning...
> 
> We are getting there I believe ;) 
> 
> -- 
> Dmitry


	Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: fuse patch needs new libs
  2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
  2005-01-25  7:31       ` Miklos Szeredi
  2005-01-27 15:45       ` Bill Davidsen
@ 2005-01-27 18:09       ` Christoph Hellwig
  2 siblings, 0 replies; 152+ messages in thread
From: Christoph Hellwig @ 2005-01-27 18:09 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel

On Tue, Jan 25, 2005 at 01:03:39AM +0100, Sytse Wielinga wrote:
> Hi Andrew,
> 
> On Mon, Jan 24, 2005 at 02:15:16AM -0800, Andrew Morton wrote:
> > fuse-transfer-readdir-data-through-device.patch
> >   fuse: transfer readdir data through device
> It is great that this is fixed, don't remove it, but it does require the fuse
> libs to be updated at the same time, or opening dirs for listings will break
> like this:

fuse is a new feature, so we'll sort out all issues before it goes to mainline.

I'm sure once it's under review there will be a few more changes in the
kernel <-> userland interface.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1: SuperIO scx200 breakage
  2005-01-27 16:21           ` Evgeniy Polyakov
@ 2005-01-27 23:12             ` Bill Davidsen
  0 siblings, 0 replies; 152+ messages in thread
From: Bill Davidsen @ 2005-01-27 23:12 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Adrian Bunk, Andrew Morton, Greg Kroah-Hartman, linux-kernel

On Thu, 27 Jan 2005, Evgeniy Polyakov wrote:

> On Thu, 27 Jan 2005 10:19:51 -0500
> Bill Davidsen <davidsen@tmr.com> wrote:
> 
> > Evgeniy Polyakov wrote:
> > > On Mon, 24 Jan 2005 18:54:49 +0100
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > 
> > > 
> > >>It seems noone who reviewed the SuperIO patches noticed that there are 
> > >>now two modules "scx200" in the kernel...
> > > 
> > > 
> > > They are almost mutually exlusive(SuperIO contains more advanced), 
> > > so I do not see any problem here.
> > > Only one of them can be loaded in a time.
> > > 
> > > So what does exactly bother you?
> > >
> > That I don't know how to select loading between modules with the same 
> > name. What's the trick?
> 
> Use full path.
> Please see discussion in this thread related to module names.

Ah-ha! I looked at the man page instead of the code. It's not obvious the
"modulename" can be a full path, but the (possibly old) man page I have
for modprobe.conf could be out of date. I'll go look at the code.

Thanks.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


^ permalink raw reply	[flat|nested] 152+ messages in thread

* [patch] generic notification layer
  2005-01-24 12:17     ` 2.6.11-rc2-mm1 Christoph Hellwig
@ 2005-01-31 22:42       ` Robert Love
  2005-02-07 11:57       ` 2.6.11-rc2-mm1 Ingo Molnar
  1 sibling, 0 replies; 152+ messages in thread
From: Robert Love @ 2005-01-31 22:42 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Andrew Morton, linux-kernel

On Mon, 2005-01-24 at 12:17 +0000, Christoph Hellwig wrote:

> Haven't had time to look at the current implementation, but the in-kernel
> interface is still horrible as it duplicates the dnotify calls all over the
> place, using IN_FOO instead of DN_FOO.  Please add a layer of notify_foo
> wrappers that calls into both.

Hi, Christoph!

I went ahead and wrote a generic notification layer, wrapping inotify,
dnotify, and some related work behind nice, clean interfaces such as
"fsnotify_move()".

The patch is a net gain of -125 lines ignoring the new
<linux/fsnotify.h>, so it does remove a bit of code from fs/, which is
nice.

Compile tested, but not yet booted.  Find an interdiff below, so you can
get an idea of the interfaces, at least.

If this is really an issue for you, I think that this should be a step
in the right direction.

Best,

	Robert Love


Signed-off-by: Robert Love <rml@novell.com>

diff -u linux/fs/attr.c linux/fs/attr.c
--- linux/fs/attr.c	2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/attr.c	2005-01-31 15:52:37.756482208 -0500
@@ -10,8 +10,7 @@
 #include <linux/mm.h>
 #include <linux/string.h>
 #include <linux/smp_lock.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
 #include <linux/fcntl.h>
 #include <linux/quotaops.h>
 #include <linux/security.h>
@@ -106,51 +105,6 @@
 }
 EXPORT_SYMBOL(inode_setattr);
 
-void setattr_mask (unsigned int ia_valid, int *dn_mask, u32 *in_mask)
-{
-	int dnmask;
-	u32 inmask;
-
-	inmask = 0;
-	dnmask = 0;
-
-	if (!dn_mask || !in_mask) {
-		return;
-	}
-        if (ia_valid & ATTR_UID) {
-                inmask |= IN_ATTRIB;
-		dnmask |= DN_ATTRIB;
-	}
-        if (ia_valid & ATTR_GID) {
-                inmask |= IN_ATTRIB;
-		dnmask |= DN_ATTRIB;
-	}
-        if (ia_valid & ATTR_SIZE) {
-                inmask |= IN_MODIFY;
-		dnmask |= DN_MODIFY;
-	}
-        /* both times implies a utime(s) call */
-        if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME)) {
-                inmask |= IN_ATTRIB;
-		dnmask |= DN_ATTRIB;
-	}
-        else if (ia_valid & ATTR_ATIME) {
-                inmask |= IN_ACCESS;
-		dnmask |= DN_ACCESS;
-	}
-        else if (ia_valid & ATTR_MTIME) {
-                inmask |= IN_MODIFY;
-		dnmask |= DN_MODIFY;
-	}
-        if (ia_valid & ATTR_MODE) {
-                inmask |= IN_ATTRIB;
-		dnmask |= DN_ATTRIB;
-	}
-
-	*in_mask = inmask;
-	*dn_mask = dnmask;
-}
-
 int notify_change(struct dentry * dentry, struct iattr * attr)
 {
 	struct inode *inode = dentry->d_inode;
@@ -206,21 +160,10 @@
 				error = inode_setattr(inode, attr);
 		}
 	}
-	if (!error) {
-		int dn_mask;
-		u32 in_mask;
 
-		setattr_mask (ia_valid, &dn_mask, &in_mask);
+	if (!error)
+		fsnotify_change(dentry, ia_valid);
 
-		if (dn_mask)
-			dnotify_parent(dentry, dn_mask);
-		if (in_mask) {
-			inotify_inode_queue_event(dentry->d_inode, in_mask, 0,
-						  NULL);
-			inotify_dentry_parent_queue_event(dentry, in_mask, 0,
-							  dentry->d_name.name);
-		}
-	}
 	return error;
 }
 
diff -u linux/fs/file_table.c linux/fs/file_table.c
--- linux/fs/file_table.c	2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/file_table.c	2005-01-31 15:46:49.248463480 -0500
@@ -16,7 +16,7 @@
 #include <linux/eventpoll.h>
 #include <linux/mount.h>
 #include <linux/cdev.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
 
 /* sysctl tunables... */
 struct files_stat_struct files_stat = {
@@ -121,12 +121,9 @@
 	struct dentry *dentry = file->f_dentry;
 	struct vfsmount *mnt = file->f_vfsmnt;
 	struct inode *inode = dentry->d_inode;
-	u32 mask;
 
 
-	mask = (file->f_mode & FMODE_WRITE) ? IN_CLOSE_WRITE : IN_CLOSE_NOWRITE;
-	inotify_dentry_parent_queue_event(dentry, mask, 0, dentry->d_name.name);
-	inotify_inode_queue_event(inode, mask, 0, NULL);
+	fsnotify_close(dentry, inode, file->f_mode, dentry->d_name.name);
 
 	might_sleep();
 	/*
diff -u linux/fs/namei.c linux/fs/namei.c
--- linux/fs/namei.c	2005-01-20 15:32:24.000000000 -0500
+++ linux/fs/namei.c	2005-01-31 17:24:21.870729656 -0500
@@ -21,8 +21,7 @@
 #include <linux/namei.h>
 #include <linux/quotaops.h>
 #include <linux/pagemap.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
 #include <linux/smp_lock.h>
 #include <linux/personality.h>
 #include <linux/security.h>
@@ -1242,9 +1241,7 @@
 	DQUOT_INIT(dir);
 	error = dir->i_op->create(dir, dentry, mode, nd);
 	if (!error) {
-		inode_dir_notify(dir, DN_CREATE);
-		inotify_inode_queue_event(dir, IN_CREATE_FILE,
-				0, dentry->d_name.name);
+		fsnotify_create(dir, dentry->d_name.name);
 		security_inode_post_create(dir, dentry, mode);
 	}
 	return error;
@@ -1558,9 +1555,7 @@
 	DQUOT_INIT(dir);
 	error = dir->i_op->mknod(dir, dentry, mode, dev);
 	if (!error) {
-		inode_dir_notify(dir, DN_CREATE);
-		inotify_inode_queue_event(dir, IN_CREATE_FILE, 0,
-				dentry->d_name.name);
+		fsnotify_create(dir, dentry->d_name.name);
 		security_inode_post_mknod(dir, dentry, mode, dev);
 	}
 	return error;
@@ -1633,9 +1628,7 @@
 	DQUOT_INIT(dir);
 	error = dir->i_op->mkdir(dir, dentry, mode);
 	if (!error) {
-		inode_dir_notify(dir, DN_CREATE);
-		inotify_inode_queue_event(dir, IN_CREATE_SUBDIR, 0,
-				dentry->d_name.name);
+		fsnotify_mkdir(dir, dentry->d_name.name);
 		security_inode_post_mkdir(dir,dentry, mode);
 	}
 	return error;
@@ -1729,15 +1722,8 @@
 		}
 	}
 	up(&dentry->d_inode->i_sem);
-	if (!error) {
-		inode_dir_notify(dir, DN_DELETE);
-		inotify_inode_queue_event(dir, IN_DELETE_SUBDIR, 0,
-				dentry->d_name.name);
-		inotify_inode_queue_event(dentry->d_inode, IN_DELETE_SELF, 0,
-				NULL);
-		inotify_inode_is_dead (dentry->d_inode);
-		d_delete(dentry);
-	}
+	if (!error)
+		fsnotify_rmdir(dentry, dentry->d_inode, dir);
 	dput(dentry);
 
 	return error;
@@ -1807,15 +1793,9 @@
 	up(&dentry->d_inode->i_sem);
 
 	/* We don't d_delete() NFS sillyrenamed files--they still exist. */
-	if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) {
-		inode_dir_notify(dir, DN_DELETE);
-		inotify_inode_queue_event(dir, IN_DELETE_FILE, 0,
-				dentry->d_name.name);
-		inotify_inode_queue_event(dentry->d_inode, IN_DELETE_SELF, 0,
-				NULL);
-		inotify_inode_is_dead (dentry->d_inode);
-		d_delete(dentry);
-	}
+	if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED))
+		fsnotify_unlink(dentry->d_inode, dir, dentry);
+
 	return error;
 }
 
@@ -1889,9 +1869,7 @@
 	DQUOT_INIT(dir);
 	error = dir->i_op->symlink(dir, dentry, oldname);
 	if (!error) {
-		inode_dir_notify(dir, DN_CREATE);
-		inotify_inode_queue_event(dir, IN_CREATE_FILE, 0,
-				dentry->d_name.name);
+		fsnotify_create(dir, dentry->d_name.name);
 		security_inode_post_symlink(dir, dentry, oldname);
 	}
 	return error;
@@ -1964,9 +1942,7 @@
 	error = dir->i_op->link(old_dentry, dir, new_dentry);
 	up(&old_dentry->d_inode->i_sem);
 	if (!error) {
-		inode_dir_notify(dir, DN_CREATE);
-		inotify_inode_queue_event(dir, IN_CREATE_FILE, 0, 
-					new_dentry->d_name.name);
+		fsnotify_create(dir, new_dentry->d_name.name);
 		security_inode_post_link(old_dentry, dir, new_dentry);
 	}
 	return error;
@@ -2131,7 +2107,6 @@
 	int error;
 	int is_dir = S_ISDIR(old_dentry->d_inode->i_mode);
 	char *old_name;
-	u32 cookie;
 
 	if (old_dentry->d_inode == new_dentry->d_inode)
  		return 0;
@@ -2153,28 +2128,17 @@
 	DQUOT_INIT(old_dir);
 	DQUOT_INIT(new_dir);
 
-	old_name = inotify_oldname_init(old_dentry);
+	old_name = fsnotify_oldname_init(old_dentry);
 
 	if (is_dir)
 		error = vfs_rename_dir(old_dir,old_dentry,new_dir,new_dentry);
 	else
 		error = vfs_rename_other(old_dir,old_dentry,new_dir,new_dentry);
 	if (!error) {
-		if (old_dir == new_dir)
-			inode_dir_notify(old_dir, DN_RENAME);
-		else {
-			inode_dir_notify(old_dir, DN_DELETE);
-			inode_dir_notify(new_dir, DN_CREATE);
-		}
-
-		cookie = inotify_get_cookie();
-
-		inotify_inode_queue_event(old_dir, IN_MOVED_FROM, cookie,
-					  old_name);
-		inotify_inode_queue_event(new_dir, IN_MOVED_TO, cookie,
-					  old_dentry->d_name.name);
+		const char *new_name = old_dentry->d_name.name;
+		fsnotify_move(old_dir, new_dir, old_name, new_name);
 	}
-	inotify_oldname_free(old_name);
+	fsnotify_oldname_free(old_name);
 
 	return error;
 }
diff -u linux/fs/open.c linux/fs/open.c
--- linux/fs/open.c	2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/open.c	2005-01-31 16:28:33.478762608 -0500
@@ -10,8 +10,7 @@
 #include <linux/file.h>
 #include <linux/smp_lock.h>
 #include <linux/quotaops.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
 #include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/tty.h>
@@ -954,13 +953,13 @@
 		fd = get_unused_fd();
 		if (fd >= 0) {
 			struct file *f = filp_open(tmp, flags, mode);
+			struct dentry *dentry = f->f_dentry;
+
 			error = PTR_ERR(f);
 			if (IS_ERR(f))
 				goto out_error;
-			inotify_inode_queue_event(f->f_dentry->d_inode,
-					IN_OPEN, 0, NULL);
-			inotify_dentry_parent_queue_event(f->f_dentry, IN_OPEN,
-					0, f->f_dentry->d_name.name);
+			fsnotify_open(dentry, dentry->d_inode,
+				      dentry->d_name.name);
 			fd_install(fd, f);
 		}
 out:
@@ -1012,7 +1011,7 @@
 			retval = err;
 	}
 
-	dnotify_flush(filp, id);
+	fsnotify_flush(filp, id);
 	locks_remove_posix(filp, id);
 	fput(filp);
 	return retval;
diff -u linux/fs/read_write.c linux/fs/read_write.c
--- linux/fs/read_write.c	2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/read_write.c	2005-01-31 16:35:05.270201256 -0500
@@ -10,8 +10,7 @@
 #include <linux/file.h>
 #include <linux/uio.h>
 #include <linux/smp_lock.h>
-#include <linux/dnotify.h>
-#include <linux/inotify.h>
+#include <linux/fsnotify.h>
 #include <linux/security.h>
 #include <linux/module.h>
 #include <linux/syscalls.h>
@@ -219,11 +218,8 @@
 				ret = do_sync_read(file, buf, count, pos);
 			if (ret > 0) {
 				struct dentry *dentry = file->f_dentry;
-				dnotify_parent(dentry, DN_ACCESS);
-				inotify_dentry_parent_queue_event(dentry,
-						IN_ACCESS, 0, dentry->d_name.name);
-				inotify_inode_queue_event(inode, IN_ACCESS, 0,
-						NULL);
+				fsnotify_access(dentry, inode,
+						dentry->d_name.name);
 			}
 		}
 	}
@@ -269,11 +265,8 @@
 				ret = do_sync_write(file, buf, count, pos);
 			if (ret > 0) {
 				struct dentry *dentry = file->f_dentry;
-				dnotify_parent(dentry, DN_MODIFY);
-				inotify_dentry_parent_queue_event(dentry,
-						IN_MODIFY, 0, dentry->d_name.name);
-				inotify_inode_queue_event(inode, IN_MODIFY, 0,
-						NULL);
+				fsnotify_modify(dentry, inode,
+						dentry->d_name.name);
 			}
 		}
 	}
@@ -508,12 +501,12 @@
 		kfree(iov);
 	if ((ret + (type == READ)) > 0) {
 		struct dentry *dentry = file->f_dentry;
-		dnotify_parent(dentry, (type == READ) ? DN_ACCESS : DN_MODIFY);
-		inotify_dentry_parent_queue_event(dentry,
-				(type == READ) ? IN_ACCESS : IN_MODIFY, 0,
-				dentry->d_name.name);
-		inotify_inode_queue_event (dentry->d_inode,
-				(type == READ) ? IN_ACCESS : IN_MODIFY, 0, NULL);
+		struct inode *inode = dentry->d_inode;
+
+		if (type == READ)
+			fsnotify_access(dentry, inode, dentry->d_name.name);
+		else
+			fsnotify_modify(dentry, inode, dentry->d_name.name);
 	}
 	return ret;
 }
diff -u linux/fs/super.c linux/fs/super.c
--- linux/fs/super.c	2005-01-18 16:11:08.000000000 -0500
+++ linux/fs/super.c	2005-01-31 14:53:38.828481040 -0500
@@ -37,9 +37,8 @@
 #include <linux/writeback.h>		/* for the emergency remount stuff */
 #include <linux/idr.h>
 #include <linux/kobject.h>
+#include <linux/fsnotify.h>
 #include <asm/uaccess.h>
-#include <linux/inotify.h>
-
 
 void get_filesystem(struct file_system_type *fs);
 void put_filesystem(struct file_system_type *fs);
@@ -228,7 +227,7 @@
 
 	if (root) {
 		sb->s_root = NULL;
-		inotify_super_block_umount(sb);
+		fsnotify_sb_umount(sb);
 		shrink_dcache_parent(root);
 		shrink_dcache_anon(&sb->s_anon);
 		dput(root);
diff -u linux/include/linux/inotify.h linux/include/linux/inotify.h
--- linux/include/linux/inotify.h	2005-01-18 16:11:12.000000000 -0500
+++ linux/include/linux/inotify.h	2005-01-31 17:22:43.129740568 -0500
@@ -84,23 +84,6 @@
 extern void inotify_super_block_umount(struct super_block *);
 extern void inotify_inode_is_dead(struct inode *);
 extern __u32 inotify_get_cookie(void);
-extern __u32 setattr_mask_inotify(unsigned int);
-
-/* this could be kstrdup if only we could add that to lib/string.c */
-static inline char * inotify_oldname_init(struct dentry *old_dentry)
-{
-	char *old_name;
-
-	old_name = kmalloc(strlen(old_dentry->d_name.name) + 1, GFP_KERNEL);
-	if (old_name)
-		strcpy(old_name, old_dentry->d_name.name);
-	return old_name;
-}
-
-static inline void inotify_oldname_free(const char *old_name)
-{
-	kfree(old_name);
-}
 
 #else
 
@@ -124,25 +107,11 @@
 {
 }
 
-static inline char * inotify_oldname_init(struct dentry *old_dentry)
-{
-	return NULL;
-}
-
 static inline __u32 inotify_get_cookie(void)
 {
 	return 0;
 }
 
-static inline void inotify_oldname_free(const char *old_name)
-{
-}
-
-static inline int setattr_mask_inotify(unsigned int ia_mask)
-{
-	return 0;
-}
-
 #endif	/* CONFIG_INOTIFY */
 
 #endif	/* __KERNEL __ */
only in patch2:
unchanged:
--- linux-2.6.10/fs/compat.c	2004-12-24 16:34:44.000000000 -0500
+++ linux/fs/compat.c	2005-01-31 17:08:03.561455272 -0500
@@ -1192,9 +1192,15 @@
 out:
 	if (iov != iovstack)
 		kfree(iov);
-	if ((ret + (type == READ)) > 0)
-		dnotify_parent(file->f_dentry,
-				(type == READ) ? DN_ACCESS : DN_MODIFY);
+	if ((ret + (type == READ)) > 0) {
+		struct dentry *dentry = file->f_dentry;
+		if (type == READ)
+			fsnotify_access(dentry, dentry->d_inode,
+					dentry->d_name.name);
+		else
+			fsnotify_modify(dentry, dentry->d_inode,
+					dentry->d_name.name);
+	}
 	return ret;
 }
 
only in patch2:
unchanged:
--- linux-2.6.10/include/linux/fsnotify.h	1969-12-31 19:00:00.000000000 -0500
+++ linux/include/linux/fsnotify.h	2005-01-31 17:24:54.486771264 -0500
@@ -0,0 +1,225 @@
+#ifndef _LINUX_FS_NOTIFY_H
+#define _LINUX_FS_NOTIFY_H
+
+/*
+ * include/linux/fs_notify.h - generic hooks for filesystem notification, to
+ * reduce in-source duplication from both dnotify and inotify.
+ *
+ * We don't compile any of this away in some complicated menagerie of ifdefs.
+ * Instead, we rely on the code inside to optimize away as needed.
+ *
+ * (C) Copyright 2005 Robert Love
+ */
+
+#ifdef __KERNEL__
+
+#include <linux/dnotify.h>
+#include <linux/inotify.h>
+
+/*
+ * fsnotify_move - file old_name at old_dir was moved to new_name at new_dir
+ */
+static inline void fsnotify_move(struct inode *old_dir, struct inode *new_dir,
+				 const char *old_name, const char *new_name)
+{
+	u32 cookie;
+
+	if (old_dir == new_dir)
+		inode_dir_notify(old_dir, DN_RENAME);
+	else {
+		inode_dir_notify(old_dir, DN_DELETE);
+		inode_dir_notify(new_dir, DN_CREATE);
+	}
+
+	cookie = inotify_get_cookie();
+
+	inotify_inode_queue_event(old_dir, IN_MOVED_FROM, cookie, old_name);
+	inotify_inode_queue_event(new_dir, IN_MOVED_TO, cookie, new_name);
+}
+
+/*
+ * fsnotify_unlink - file was unlinked
+ */
+static inline void fsnotify_unlink(struct inode *inode, struct inode *dir,
+				   struct dentry *dentry)
+{
+	inode_dir_notify(dir, DN_DELETE);
+	inotify_inode_queue_event(dir, IN_DELETE_FILE, 0, dentry->d_name.name);
+	inotify_inode_queue_event(inode, IN_DELETE_SELF, 0, NULL);
+
+	inotify_inode_is_dead(inode);
+	d_delete(dentry);
+}
+
+/*
+ * fsnotify_rmdir - directory was removed
+ */
+static inline void fsnotify_rmdir(struct dentry *dentry, struct inode *inode,
+				  struct inode *dir)
+{
+	inode_dir_notify(dir, DN_DELETE);
+	inotify_inode_queue_event(dir, IN_DELETE_SUBDIR,0,dentry->d_name.name);
+	inotify_inode_queue_event(inode, IN_DELETE_SELF, 0, NULL);
+
+	inotify_inode_is_dead(inode);
+	d_delete(dentry);
+}
+
+/*
+ * fsnotify_create - filename was linked in
+ */
+static inline void fsnotify_create(struct inode *inode, const char *filename)
+{
+	inode_dir_notify(inode, DN_CREATE);
+	inotify_inode_queue_event(inode, IN_CREATE_FILE, 0, filename);
+}
+
+/*
+ * fsnotify_mkdir - directory 'name' was created
+ */
+static inline void fsnotify_mkdir(struct inode *inode, const char *name)
+{
+	inode_dir_notify(inode, DN_CREATE);
+	inotify_inode_queue_event(inode, IN_CREATE_SUBDIR, 0, name);
+}
+
+/*
+ * fsnotify_access - file was read
+ */
+static inline void fsnotify_access(struct dentry *dentry, struct inode *inode,
+				   const char *filename)
+{
+	dnotify_parent(dentry, DN_ACCESS);
+	inotify_dentry_parent_queue_event(dentry, IN_ACCESS, 0,
+					  dentry->d_name.name);
+	inotify_inode_queue_event(inode, IN_ACCESS, 0, NULL);
+}
+
+/*
+ * fsnotify_modify - file was modified
+ */
+static inline void fsnotify_modify(struct dentry *dentry, struct inode *inode,
+				   const char *filename)
+{
+	dnotify_parent(dentry, DN_MODIFY);
+	inotify_dentry_parent_queue_event(dentry, IN_MODIFY, 0, filename);
+	inotify_inode_queue_event(inode, IN_MODIFY, 0, NULL);
+}
+
+/*
+ * fsnotify_open - file was opened
+ */
+static inline void fsnotify_open(struct dentry *dentry, struct inode *inode,
+				 const char *filename)
+{
+	inotify_inode_queue_event(inode, IN_OPEN, 0, NULL);
+	inotify_dentry_parent_queue_event(dentry, IN_OPEN, 0, filename);
+}
+
+/*
+ * fsnotify_close - file was closed
+ */
+static inline void fsnotify_close(struct dentry *dentry, struct inode *inode,
+				  mode_t mode, const char *filename)
+{
+	u32 mask;
+
+	mask = (mode & FMODE_WRITE) ? IN_CLOSE_WRITE : IN_CLOSE_NOWRITE;
+	inotify_dentry_parent_queue_event(dentry, mask, 0, filename);
+	inotify_inode_queue_event(inode, mask, 0, NULL);
+}
+
+/*
+ * fsnotify_change - notify_change event.  file was modified and/or metadata
+ * was changed.
+ */
+static inline void fsnotify_change(struct dentry *dentry, unsigned int ia_valid)
+{
+	int dn_mask = 0;
+	u32 in_mask = 0;
+
+        if (ia_valid & ATTR_UID) {
+                in_mask |= IN_ATTRIB;
+		dn_mask |= DN_ATTRIB;
+	}
+        if (ia_valid & ATTR_GID) {
+                in_mask |= IN_ATTRIB;
+		dn_mask |= DN_ATTRIB;
+	}
+        if (ia_valid & ATTR_SIZE) {
+                in_mask |= IN_MODIFY;
+		dn_mask |= DN_MODIFY;
+	}
+        /* both times implies a utime(s) call */
+        if ((ia_valid & (ATTR_ATIME|ATTR_MTIME)) == (ATTR_ATIME|ATTR_MTIME)) {
+                in_mask |= IN_ATTRIB;
+		dn_mask |= DN_ATTRIB;
+	}
+        else if (ia_valid & ATTR_ATIME) {
+                in_mask |= IN_ACCESS;
+		dn_mask |= DN_ACCESS;
+	}
+        else if (ia_valid & ATTR_MTIME) {
+                in_mask |= IN_MODIFY;
+		dn_mask |= DN_MODIFY;
+	}
+        if (ia_valid & ATTR_MODE) {
+                in_mask |= IN_ATTRIB;
+		dn_mask |= DN_ATTRIB;
+	}
+
+	if (dn_mask)
+		dnotify_parent(dentry, dn_mask);
+	if (in_mask) {
+		inotify_inode_queue_event(dentry->d_inode, in_mask, 0, NULL);
+		inotify_dentry_parent_queue_event(dentry, in_mask, 0,
+						  dentry->d_name.name);
+	}
+}
+
+/*
+ * fsnotify_sb_umount - filesystem unmount
+ */
+static inline void fsnotify_sb_umount(struct super_block *sb)
+{
+	inotify_super_block_umount(sb);
+}
+
+/*
+ * fsnotify_flush - flush time!
+ */
+static inline void fsnotify_flush(struct file *filp, fl_owner_t id)
+{
+	dnotify_flush(filp, id);
+}
+
+#ifdef CONFIG_INOTIFY	/* inotify helpers */
+
+/*
+ * fsnotify_oldname_init - save off the old filename before we change it
+ *
+ * this could be kstrdup if only we could add that to lib/string.c
+ */
+static inline char * fsnotify_oldname_init(struct dentry *old_dentry)
+{
+	char *old_name;
+
+	old_name = kmalloc(strlen(old_dentry->d_name.name) + 1, GFP_KERNEL);
+	if (old_name)
+		strcpy(old_name, old_dentry->d_name.name);
+	return old_name;
+}
+
+/*
+ * fsnotify_oldname_free - free the name we got from fsnotify_oldname_init
+ */
+static inline void fsnotify_oldname_free(const char *old_name)
+{
+	kfree(old_name);
+}
+
+#endif	/* CONFIG_INOTIFY */
+
+#endif	/* __KERNEL__ */
+
+#endif	/* _LINUX_FS_NOTIFY_H */



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-01-24 12:17     ` 2.6.11-rc2-mm1 Christoph Hellwig
  2005-01-31 22:42       ` [patch] generic notification layer Robert Love
@ 2005-02-07 11:57       ` Ingo Molnar
  2005-02-07 17:30         ` 2.6.11-rc2-mm1 Robert Love
  1 sibling, 1 reply; 152+ messages in thread
From: Ingo Molnar @ 2005-02-07 11:57 UTC (permalink / raw)
  To: Christoph Hellwig, Andrew Morton, rml, linux-kernel


* Christoph Hellwig <hch@infradead.org> wrote:

> > inotify.patch
> >   inotify

> Also ioctl is not an acceptable interface for adding new core
> functionality.

seconded. Robert?

	Ingo

^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-02-07 11:57       ` 2.6.11-rc2-mm1 Ingo Molnar
@ 2005-02-07 17:30         ` Robert Love
  2005-02-07 21:02           ` 2.6.11-rc2-mm1 John McCutchan
  0 siblings, 1 reply; 152+ messages in thread
From: Robert Love @ 2005-02-07 17:30 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: Christoph Hellwig, Andrew Morton, linux-kernel, ttb

On Mon, 2005-02-07 at 12:57 +0100, Ingo Molnar wrote:

Hello, Ingo.

> > Also ioctl is not an acceptable interface for adding new core
> > functionality.
> 
> seconded. Robert?

Well, I don't share the hatred for ioctl, at least compared to another
type unsafe interface like write().

But John and I are open to doing whatever is the consensus.  If there is
an agreed alternative, and that is the requirement for merging, I'll do
it.

I'd like to keep the user-space interface and simple, and absolutely
want to keep the single file descriptor approach.  How the fd is
obtained is up for discussion.

Ingo, what do you prefer?

Best,

	Robert Love



^ permalink raw reply	[flat|nested] 152+ messages in thread

* Re: 2.6.11-rc2-mm1
  2005-02-07 17:30         ` 2.6.11-rc2-mm1 Robert Love
@ 2005-02-07 21:02           ` John McCutchan
  0 siblings, 0 replies; 152+ messages in thread
From: John McCutchan @ 2005-02-07 21:02 UTC (permalink / raw)
  To: Robert Love; +Cc: Ingo Molnar, Christoph Hellwig, Andrew Morton, linux-kernel

On Mon, 2005-02-07 at 12:30 -0500, Robert Love wrote:
> Well, I don't share the hatred for ioctl, at least compared to another
> type unsafe interface like write().
> 
> But John and I are open to doing whatever is the consensus.  If there is
> an agreed alternative, and that is the requirement for merging, I'll do
> it.

Yes, if ioctl is unacceptable, then providing a write() interface is
what we will do.

> 
> I'd like to keep the user-space interface and simple, and absolutely
> want to keep the single file descriptor approach.  How the fd is
> obtained is up for discussion.

I would still like to keep the character device as the interface for
getting the fd. I don't see what benefit could be gained by converting
to a syscall based interface for getting the fd.

-- 
John McCutchan <ttb@tentacle.dhs.org>

^ permalink raw reply	[flat|nested] 152+ messages in thread

end of thread, other threads:[~2005-02-07 21:02 UTC | newest]

Thread overview: 152+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-01-18  7:21 [PATCH] Some fixes for compat ioctl Andi Kleen
2005-01-18 10:34 ` Michael S. Tsirkin
2005-01-18 10:45   ` [PATCH 1/5] compat_ioctl call seems to miss a security hook Michael S. Tsirkin
2005-01-18 19:22     ` Chris Wright
2005-01-20  0:28       ` Michael S. Tsirkin
2005-01-20  0:43         ` Chris Wright
2005-01-20  1:06           ` Michael S. Tsirkin
2005-01-20  1:16             ` Chris Wright
2005-01-20  1:42               ` Michael S. Tsirkin
2005-01-18 10:48 ` [PATCH 2/5] socket ioctl fix (from Andi) Michael S. Tsirkin
2005-01-18 10:55   ` Christoph Hellwig
2005-01-18 11:01     ` Andi Kleen
2005-01-18 10:52 ` [PATCH 3/5] make common ioctls apply for compat Michael S. Tsirkin
2005-01-18 10:57 ` [PATCH 4/5] reminder comment about register_ioctl32_conversion Michael S. Tsirkin
2005-01-18 11:04 ` [PATCH 5/5] symmetry between compat_ioctl and unlocked_ioctl Michael S. Tsirkin
2005-01-24 10:15   ` 2.6.11-rc2-mm1 Andrew Morton
2005-01-24 10:36     ` 2.6.11-rc2-mm1 Adrian Bunk
2005-01-24 11:17     ` 2.6.11-rc2-mm1: v4l-saa7134-module compile error Adrian Bunk
2005-01-24 13:57       ` Gerd Knorr
2005-01-24 17:45         ` Adrian Bunk
2005-01-25 10:15           ` Gerd Knorr
2005-01-25 10:38             ` Adrian Bunk
2005-01-24 11:56     ` 2.6.11-rc2-mm1 Brice Goglin
2005-01-24 13:41       ` 2.6.11-rc2-mm1 Brice Goglin
2005-01-24 14:35         ` 2.6.11-rc2-mm1 Florian Bohrer
2005-01-24 18:52       ` 2.6.11-rc2-mm1 Dave Jones
2005-01-24 20:44         ` 2.6.11-rc2-mm1 Dave Jones
2005-01-24 21:31           ` 2.6.11-rc2-mm1 Brice Goglin
2005-01-25 19:38             ` 2.6.11-rc2-mm1 Dave Jones
2005-01-25 19:58               ` 2.6.11-rc2-mm1 Brice Goglin
2005-01-25 20:29                 ` 2.6.11-rc2-mm1 Dave Jones
2005-01-24 12:12     ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-24 20:36       ` 2.6.11-rc2-mm1 Karsten Keil
2005-01-24 23:26         ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-25  0:35           ` 2.6.11-rc2-mm1 Karsten Keil
2005-01-24 23:32         ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
2005-01-24 21:03       ` 2.6.11-rc2-mm1 Andrew Morton
2005-01-24 12:17     ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-31 22:42       ` [patch] generic notification layer Robert Love
2005-02-07 11:57       ` 2.6.11-rc2-mm1 Ingo Molnar
2005-02-07 17:30         ` 2.6.11-rc2-mm1 Robert Love
2005-02-07 21:02           ` 2.6.11-rc2-mm1 John McCutchan
2005-01-24 12:25     ` [-mm patch] fix SuperIO compilation Adrian Bunk
2005-01-24 12:34       ` Christoph Hellwig
2005-01-24 13:04         ` Evgeniy Polyakov
2005-01-24 13:56           ` Evgeniy Polyakov
2005-01-24 14:14             ` [1/1] superio: remove unneded exports and make some functions static Evgeniy Polyakov
2005-01-25  6:19               ` Greg KH
2005-01-24 12:48     ` 2.6.11-rc2-mm1: DVB compile error Adrian Bunk
2005-01-24 23:56       ` [linux-dvb-maintainer] " Johannes Stezenbach
2005-01-24 13:52     ` 2.6.11-rc2-mm1 Roman Zippel
2005-01-24 14:24     ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-24 14:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
2005-01-24 15:11     ` 2.6.11-rc2-mm1 [compile fix] Benoit Boissinot
2005-01-24 17:25       ` Adrian Bunk
2005-01-24 17:54     ` 2.6.11-rc2-mm1: SuperIO scx200 breakage Adrian Bunk
2005-01-24 18:43       ` Evgeniy Polyakov
2005-01-24 18:29         ` Adrian Bunk
2005-01-24 19:19           ` Evgeniy Polyakov
2005-01-24 19:03             ` Adrian Bunk
2005-01-24 19:46               ` Evgeniy Polyakov
2005-01-24 18:41         ` Jurriaan
2005-01-24 19:23           ` Evgeniy Polyakov
2005-01-24 19:05             ` Adrian Bunk
2005-01-24 19:39               ` Evgeniy Polyakov
2005-01-24 19:32                 ` Dmitry Torokhov
2005-01-24 20:28                   ` Evgeniy Polyakov
2005-01-27 15:19         ` Bill Davidsen
2005-01-27 16:21           ` Evgeniy Polyakov
2005-01-27 23:12             ` Bill Davidsen
2005-01-24 20:33       ` Christoph Hellwig
2005-01-24 21:10         ` Evgeniy Polyakov
2005-01-24 21:34       ` Greg KH
2005-01-24 21:47         ` Christoph Hellwig
2005-01-25  6:02           ` Greg KH
2005-01-25  7:11             ` Christoph Hellwig
2005-01-25 18:59             ` Jean Delvare
2005-01-25 21:39               ` Evgeniy Polyakov
2005-01-25 21:40                 ` Jean Delvare
2005-01-25 22:35                   ` Evgeniy Polyakov
2005-01-26  9:55                     ` Jean Delvare
2005-01-26 10:55                       ` Evgeniy Polyakov
2005-01-26 14:34                         ` Jean Delvare
2005-01-26 16:10                           ` Evgeniy Polyakov
2005-01-26 19:20                             ` Jean Delvare
2005-01-26 20:21                               ` Evgeniy Polyakov
2005-01-26 10:14                     ` Christoph Hellwig
2005-01-26 10:59                       ` Evgeniy Polyakov
2005-01-26 14:00                         ` Dmitry Torokhov
2005-01-26 16:38                           ` Evgeniy Polyakov
2005-01-26 18:19                             ` Adrian Bunk
2005-01-26 19:27                               ` Evgeniy Polyakov
2005-01-27 10:20                                 ` Adrian Bunk
2005-01-27 11:53                                   ` Evgeniy Polyakov
2005-01-26 18:06                         ` Adrian Bunk
2005-01-26 13:12                       ` Russell King
2005-01-26 20:01                         ` Christoph Hellwig
2005-01-24 18:58     ` 2.6.11-rc2-mm1 Benoit Boissinot
2005-01-24 19:09       ` 2.6.11-rc2-mm1 Adrian Bunk
2005-01-24 19:44     ` 2.6.11-rc2-mm1 - fix a typo in nfs3proc.c Benoit Boissinot
2005-01-24 20:24     ` 2.6.11-rc2-mm1 - compile fix Benoit Boissinot
2005-01-24 20:26     ` [PATCH] move common compat ioctls to hash Michael S. Tsirkin
2005-01-25  6:17       ` Andi Kleen
2005-01-26  8:40         ` Michael S. Tsirkin
2005-01-25  0:03     ` 2.6.11-rc2-mm1: fuse patch needs new libs Sytse Wielinga
2005-01-25  7:31       ` Miklos Szeredi
2005-01-27 15:45       ` Bill Davidsen
2005-01-27 15:56         ` Sytse Wielinga
2005-01-27 16:11           ` Miklos Szeredi
2005-01-27 18:09       ` Christoph Hellwig
2005-01-25  1:01     ` 2.6.11-rc2-mm1 Brice Goglin
2005-01-25  1:30       ` 2.6.11-rc2-mm1 (AE_AML_NO_OPERAND) Len Brown
2005-01-25 18:41       ` 2.6.11-rc2-mm1 Pavel Machek
2005-01-25 19:10         ` 2.6.11-rc2-mm1 Espen Fjellvær Olsen
2005-01-25 12:53     ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-25 14:11       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 14:23         ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-25 15:24           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 15:34             ` 2.6.11-rc2-mm1 Bartlomiej Zolnierkiewicz
2005-01-25 16:04               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 18:21                 ` 2.6.11-rc2-mm1 Jörn Engel
2005-01-25 21:17                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26  2:20                     ` 2.6.11-rc2-mm1 Jörn Engel
2005-01-25 15:36             ` 2.6.11-rc2-mm1 Paulo Marques
2005-01-25 21:08               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 16:11             ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-25 21:14               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26  4:57                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26  8:25                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 13:46                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 14:59                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 15:26                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 15:54                           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 16:25                             ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 16:46                               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 16:55                                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 17:39                                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 18:26                                     ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 20:07                                       ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 20:22                                         ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-27 17:33                                           ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 22:42             ` 2.6.11-rc2-mm1 Christoph Hellwig
2005-01-26  8:31               ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-26 13:32                 ` 2.6.11-rc2-mm1 Dmitry Torokhov
2005-01-26 14:44                   ` 2.6.11-rc2-mm1 Evgeniy Polyakov
2005-01-25 19:35       ` 2.6.11-rc2-mm1 Pavel Machek
2005-01-25 19:12     ` 2.6.11-rc2-mm1 Marcos D. Marado Torres
2005-01-25 23:07       ` 2.6.11-rc2-mm1 Barry K. Nathan
2005-01-26  2:40     ` 2.6.11-rc2-mm1 William Lee Irwin III
2005-01-26  4:44     ` [PATCH] ppc64: fix use kref for device_node refcounting Nathan Lynch
2005-01-27  6:18     ` 2.6.11-rc2-mm1 William Lee Irwin III
2005-01-27  9:14       ` 2.6.11-rc2-mm1 William Lee Irwin III

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).