Re: [PATCH] epoll: stop comparing pointers with 0 in self-test app
I don't see anything obviously wrong here...
Reviewed-By: Daniel Hazelton
On 12/20/2012 02:11 PM, Sasha Levin wrote:
Signed-off-by: Sasha Levin
---
tools/testing/selftests/epoll/test_epoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/epoll/test_epoll.c
b/tools/testing/selftests/epoll/test_epoll.c
index 4a14a7f..1034ed4 100644
--- a/tools/testing/selftests/epoll/test_epoll.c
+++ b/tools/testing/selftests/epoll/test_epoll.c
@@ -199,8 +199,8 @@ int main(int argc, char **argv)
epoll_items = malloc(n_epoll_items * sizeof(struct epoll_item_private));
- if (epoll_set < 0 || epoll_items == 0 || write_thread_data.fds == 0 ||
- read_thread_data == 0 || read_threads == 0)
+ if (epoll_set < 0 || !epoll_items || write_thread_data.fds == NULL ||
+ !read_thread_data || !read_threads)
goto error;
if (sysconf(_SC_NPROCESSORS_ONLN) < 2) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] epoll: stop comparing pointers with 0 in self-test app
I don't see anything obviously wrong here...
Reviewed-By: Daniel Hazelton dshadoww...@gmail.com
On 12/20/2012 02:11 PM, Sasha Levin wrote:
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
tools/testing/selftests/epoll/test_epoll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/epoll/test_epoll.c
b/tools/testing/selftests/epoll/test_epoll.c
index 4a14a7f..1034ed4 100644
--- a/tools/testing/selftests/epoll/test_epoll.c
+++ b/tools/testing/selftests/epoll/test_epoll.c
@@ -199,8 +199,8 @@ int main(int argc, char **argv)
epoll_items = malloc(n_epoll_items * sizeof(struct epoll_item_private));
- if (epoll_set 0 || epoll_items == 0 || write_thread_data.fds == 0 ||
- read_thread_data == 0 || read_threads == 0)
+ if (epoll_set 0 || !epoll_items || write_thread_data.fds == NULL ||
+ !read_thread_data || !read_threads)
goto error;
if (sysconf(_SC_NPROCESSORS_ONLN) 2) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UAPI: Fix tools/vm/page-types.c
On 10/23/12 09:20, David Howells wrote: Fix tools/vm/page-types.c to use the UAPI variant of linux/kernel-page-flags.h lest the following error appear: In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory Reported-by: Daniel Hazelton Signed-off-by: David Howells cc: Fengguang Wu --- tools/vm/page-types.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/vm/page-types.c b/tools/vm/page-types.c index cd1b03e..b76edf2 100644 --- a/tools/vm/page-types.c +++ b/tools/vm/page-types.c @@ -35,7 +35,7 @@ #include #include #include "../../include/uapi/linux/magic.h" -#include "../../include/linux/kernel-page-flags.h" +#include "../../include/uapi/linux/kernel-page-flags.h" #ifndef MAX_PATH FWIW: Tested-by: Daniel Hazelton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] UAPI: Fix tools/vm/page-types.c
On 10/23/12 09:20, David Howells wrote: Fix tools/vm/page-types.c to use the UAPI variant of linux/kernel-page-flags.h lest the following error appear: In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory Reported-by: Daniel Hazelton dshadoww...@gmail.com Signed-off-by: David Howells dhowe...@redhat.com cc: Fengguang Wu fengguang...@intel.com --- tools/vm/page-types.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/vm/page-types.c b/tools/vm/page-types.c index cd1b03e..b76edf2 100644 --- a/tools/vm/page-types.c +++ b/tools/vm/page-types.c @@ -35,7 +35,7 @@ #include sys/mount.h #include sys/statfs.h #include ../../include/uapi/linux/magic.h -#include ../../include/linux/kernel-page-flags.h +#include ../../include/uapi/linux/kernel-page-flags.h #ifndef MAX_PATH FWIW: Tested-by: Daniel Hazelton dshadoww...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tools/vm build fails
After doing any build in the kernel (last attempt was an allmodconfig) I've tried to build the 'vm' tool in tools/vm and the build fails - looks to be fallout from the uapi header work. [madman@localhost tools]$ make V=1 vm make -C vm/ make[1]: Entering directory `/home/madman/sources/linux-2.6/tools/vm' gcc -Wall -Wextra -o page-types page-types.c In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory compilation terminated. make[1]: *** [page-types] Error 1 make[1]: Leaving directory `/home/madman/sources/linux-2.6/tools/vm' make: *** [vm] Error 2 I'm not a kernel developer (I've tried and been unable to wrap my head around any part that I was going to try working on :( )and was just trying bits in tools/ at random to see what, exactly, they were and this kept happening, no matter the state of the tree. I updated my git tree about 3 hours ago to mirror the latest Linus from git.kernel.org after having run into this error yesterday and deciding I must have done something wrong. This looks like it might be a missing -I or similar since the file does exist and is at that exact path from the file that is directly including it. DRH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
tools/vm build fails
After doing any build in the kernel (last attempt was an allmodconfig) I've tried to build the 'vm' tool in tools/vm and the build fails - looks to be fallout from the uapi header work. [madman@localhost tools]$ make V=1 vm make -C vm/ make[1]: Entering directory `/home/madman/sources/linux-2.6/tools/vm' gcc -Wall -Wextra -o page-types page-types.c In file included from page-types.c:38:0: ../../include/linux/kernel-page-flags.h:4:42: fatal error: uapi/linux/kernel-page-flags.h: No such file or directory compilation terminated. make[1]: *** [page-types] Error 1 make[1]: Leaving directory `/home/madman/sources/linux-2.6/tools/vm' make: *** [vm] Error 2 I'm not a kernel developer (I've tried and been unable to wrap my head around any part that I was going to try working on :( )and was just trying bits in tools/ at random to see what, exactly, they were and this kept happening, no matter the state of the tree. I updated my git tree about 3 hours ago to mirror the latest Linus from git.kernel.org after having run into this error yesterday and deciding I must have done something wrong. This looks like it might be a missing -I or similar since the file does exist and is at that exact path from the file that is directly including it. DRH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] staging: ccg: print MAC addresses via %pM
On 07/06/2012 11:32 AM, Kyungmin Park wrote:
> Acked-by: Kyungmin Park
>
> On Sat, Jul 7, 2012 at 12:28 AM, Andy Shevchenko
> wrote:
>> Signed-off-by: Andy Shevchenko
>> Cc: Kyungmin Park
>> ---
>> drivers/staging/ccg/ccg.c |8 ++--
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/ccg/ccg.c b/drivers/staging/ccg/ccg.c
>> index a5b36a9..62f5d92 100644
>> --- a/drivers/staging/ccg/ccg.c
>> +++ b/drivers/staging/ccg/ccg.c
>> @@ -564,9 +564,7 @@ static int rndis_function_bind_config(struct
>> ccg_usb_function *f,
>> return -1;
>> }
>>
>> - pr_info("%s MAC: %02X:%02X:%02X:%02X:%02X:%02X\n", __func__,
>> - rndis->ethaddr[0], rndis->ethaddr[1], rndis->ethaddr[2],
>> - rndis->ethaddr[3], rndis->ethaddr[4], rndis->ethaddr[5]);
>> + pr_info("%s MAC: pM\n", __func__, rndis->ethaddr);
You lost a % there - it should be "%s MAC: %pM\n", no ?
DRH
>>
>> ret = gether_setup_name(c->cdev->gadget, rndis->ethaddr, "rndis");
>> if (ret) {
>> @@ -654,9 +652,7 @@ static ssize_t rndis_ethaddr_show(struct device *dev,
>> {
>> struct ccg_usb_function *f = dev_get_drvdata(dev);
>> struct rndis_function_config *rndis = f->config;
>> - return sprintf(buf, "%02x:%02x:%02x:%02x:%02x:%02x\n",
>> - rndis->ethaddr[0], rndis->ethaddr[1], rndis->ethaddr[2],
>> - rndis->ethaddr[3], rndis->ethaddr[4], rndis->ethaddr[5]);
>> + return sprintf(buf, "%pM\n", rndis->ethaddr);
>> }
>>
>> static ssize_t rndis_ethaddr_store(struct device *dev,
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] staging: ccg: print MAC addresses via %pM
On 07/06/2012 11:32 AM, Kyungmin Park wrote:
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Sat, Jul 7, 2012 at 12:28 AM, Andy Shevchenko
andriy.shevche...@linux.intel.com wrote:
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/staging/ccg/ccg.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ccg/ccg.c b/drivers/staging/ccg/ccg.c
index a5b36a9..62f5d92 100644
--- a/drivers/staging/ccg/ccg.c
+++ b/drivers/staging/ccg/ccg.c
@@ -564,9 +564,7 @@ static int rndis_function_bind_config(struct
ccg_usb_function *f,
return -1;
}
- pr_info(%s MAC: %02X:%02X:%02X:%02X:%02X:%02X\n, __func__,
- rndis-ethaddr[0], rndis-ethaddr[1], rndis-ethaddr[2],
- rndis-ethaddr[3], rndis-ethaddr[4], rndis-ethaddr[5]);
+ pr_info(%s MAC: pM\n, __func__, rndis-ethaddr);
You lost a % there - it should be %s MAC: %pM\n, no ?
DRH
ret = gether_setup_name(c-cdev-gadget, rndis-ethaddr, rndis);
if (ret) {
@@ -654,9 +652,7 @@ static ssize_t rndis_ethaddr_show(struct device *dev,
{
struct ccg_usb_function *f = dev_get_drvdata(dev);
struct rndis_function_config *rndis = f-config;
- return sprintf(buf, %02x:%02x:%02x:%02x:%02x:%02x\n,
- rndis-ethaddr[0], rndis-ethaddr[1], rndis-ethaddr[2],
- rndis-ethaddr[3], rndis-ethaddr[4], rndis-ethaddr[5]);
+ return sprintf(buf, %pM\n, rndis-ethaddr);
}
static ssize_t rndis_ethaddr_store(struct device *dev,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?
On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
> On Mon, 25 Feb 2008, Jan Kara wrote:
> > Yes, exactly two of them. One is non-trivial to get rid of - it's
> > used for encoding of filename before we write it,
>
> Why can't we do just
>
>
>
> UDF: Optimize stack usage
>
> Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
>
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index 112a5fb..706a2b5 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -336,7 +336,7 @@ static struct fileIdentDesc *udf_add_entry(struct inode
> *dir, {
> struct super_block *sb = dir->i_sb;
> struct fileIdentDesc *fi = NULL;
> - char name[UDF_NAME_LEN], fname[UDF_NAME_LEN];
> + char *name, *fname;
> int namelen;
> loff_t f_pos;
> int flen;
> @@ -352,6 +352,14 @@ static struct fileIdentDesc *udf_add_entry(struct
> inode *dir, struct extent_position epos = {};
> struct udf_inode_info *dinfo;
>
> + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> +
> + if (!name || !fname) {
> + *err = -ENOMEM;
> + return NULL;
> + }
> +
Wouldn't it be better to check each individually, so you do wind up leaking a
buffer here if one gets allocated and the other doesn't ?
> if (dentry) {
> if (!dentry->d_name.len) {
> *err = -EINVAL;
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index f3ac4ab..42e3ba8 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -1345,7 +1345,7 @@ static void udf_load_logicalvolint(struct super_block
> *sb, kernel_extent_ad loc) * July 1, 1997 - Andrew E. Mileski
> * Written, tested, and released.
> */
> -static int udf_process_sequence(struct super_block *sb, long block,
> +static int noinline udf_process_sequence(struct super_block *sb, long
> block, long lastblock, kernel_lb_addr *fileset)
> {
> struct buffer_head *bh = NULL;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount - stack overflow: ide-cd related? dm-related?
On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
On Mon, 25 Feb 2008, Jan Kara wrote:
Yes, exactly two of them. One is non-trivial to get rid of - it's
used for encoding of filename before we write it,
Why can't we do just
UDF: Optimize stack usage
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index 112a5fb..706a2b5 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -336,7 +336,7 @@ static struct fileIdentDesc *udf_add_entry(struct inode
*dir, {
struct super_block *sb = dir-i_sb;
struct fileIdentDesc *fi = NULL;
- char name[UDF_NAME_LEN], fname[UDF_NAME_LEN];
+ char *name, *fname;
int namelen;
loff_t f_pos;
int flen;
@@ -352,6 +352,14 @@ static struct fileIdentDesc *udf_add_entry(struct
inode *dir, struct extent_position epos = {};
struct udf_inode_info *dinfo;
+ name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+ fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+
+ if (!name || !fname) {
+ *err = -ENOMEM;
+ return NULL;
+ }
+
Wouldn't it be better to check each individually, so you do wind up leaking a
buffer here if one gets allocated and the other doesn't ?
if (dentry) {
if (!dentry-d_name.len) {
*err = -EINVAL;
diff --git a/fs/udf/super.c b/fs/udf/super.c
index f3ac4ab..42e3ba8 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@ -1345,7 +1345,7 @@ static void udf_load_logicalvolint(struct super_block
*sb, kernel_extent_ad loc) * July 1, 1997 - Andrew E. Mileski
* Written, tested, and released.
*/
-static int udf_process_sequence(struct super_block *sb, long block,
+static int noinline udf_process_sequence(struct super_block *sb, long
block, long lastblock, kernel_lb_addr *fileset)
{
struct buffer_head *bh = NULL;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 06:20:45 Alan Cox wrote: > > Why? Because the pre-processor is what is including any GPL'd code in my > > application and expanding any macros. That is a purely mechanical process > > and > > And its not pirating Windows because Norton Ghost put Microsoft copyright > material in your hard disk either - thats a mechanical process too. Right > - no. Nor can the gcc compiler hold the copyright as you suggest as it is > not a legal person. It takes someone telling the program to do it. The act of instructing the program is the actual "criminal" act. This is a 'Straw Man'. Next ? > The compiler might perform a process which combines your creative work > with another and thus creates a derivative work. It might do that with > libgcc. In many cases the FSF is being careful when it makes sure > specific things don't happen just as Linus did with the kernel. Sometimes > it is best to make sure no judge got a bit carried away and instead to > create certainty in advance. Yes, of course, and I'll never argue otherwise. However, what I was saying is that it is the claim of the FSF that, in no uncertain terms, a C program that uses the standard C library interface and is linked to glibc instead of, say, the old Borland libc, is automatically GPL because it's been linked to GPL code. And in the case of the "Bison Exception", lets think of it this way... A company writes a configuration file parser and is selling the software to other companies for use on their Solaris and SysV machines. The board decides to sell the software for linux and the employee in charge of the linux build uses the standard GNU tools for the entire process, including Bison. Even without the exception it wouldn't make the program a derivative of Bison or even come close to putting the code under the GPL. > If you really think what you claim then I'll #include your entire work, > flog it binary only and assure you it can't be derivative as you said so. > That's entirely mechanical - in fact I can clain a defence of 'estoppel' > given your previous statement, so you probably wouldn't be able to sue me > for it even if it was otherwise a violation. Straw man. Again. But... You'd have fallen afoul of the "intent". Action follows intent, and so does the law. (At least in the US) > There is btw lots of possibly useful caselaw in the area of books. People > have spent time litigating and thus established some clearer answers to > questions like whether you need copyright owners permission for And I've actually read almost all the court cases that have a bearing on this. (I don't step into a discussion unprepared) If the process of linking could create a derivative work, the *EVERY* program that runs on *ANY* OS would be a derivative of that OS, because the program is linked to the OS at run-time. DRH PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I tend to get very combative and come off like a troll. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 06:20:45 Alan Cox wrote: Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and And its not pirating Windows because Norton Ghost put Microsoft copyright material in your hard disk either - thats a mechanical process too. Right - no. Nor can the gcc compiler hold the copyright as you suggest as it is not a legal person. It takes someone telling the program to do it. The act of instructing the program is the actual criminal act. This is a 'Straw Man'. Next ? The compiler might perform a process which combines your creative work with another and thus creates a derivative work. It might do that with libgcc. In many cases the FSF is being careful when it makes sure specific things don't happen just as Linus did with the kernel. Sometimes it is best to make sure no judge got a bit carried away and instead to create certainty in advance. Yes, of course, and I'll never argue otherwise. However, what I was saying is that it is the claim of the FSF that, in no uncertain terms, a C program that uses the standard C library interface and is linked to glibc instead of, say, the old Borland libc, is automatically GPL because it's been linked to GPL code. And in the case of the Bison Exception, lets think of it this way... A company writes a configuration file parser and is selling the software to other companies for use on their Solaris and SysV machines. The board decides to sell the software for linux and the employee in charge of the linux build uses the standard GNU tools for the entire process, including Bison. Even without the exception it wouldn't make the program a derivative of Bison or even come close to putting the code under the GPL. If you really think what you claim then I'll #include your entire work, flog it binary only and assure you it can't be derivative as you said so. That's entirely mechanical - in fact I can clain a defence of 'estoppel' given your previous statement, so you probably wouldn't be able to sue me for it even if it was otherwise a violation. Straw man. Again. But... You'd have fallen afoul of the intent. Action follows intent, and so does the law. (At least in the US) There is btw lots of possibly useful caselaw in the area of books. People have spent time litigating and thus established some clearer answers to questions like whether you need copyright owners permission for And I've actually read almost all the court cases that have a bearing on this. (I don't step into a discussion unprepared) If the process of linking could create a derivative work, the *EVERY* program that runs on *ANY* OS would be a derivative of that OS, because the program is linked to the OS at run-time. DRH PS: It is time for me to shut up now. I'm sick (bronchitis) and when sick, I tend to get very combative and come off like a troll. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 00:43:49 Marcel Holtmann wrote: > Hi Daniel, > > > > > > It makes no difference if you > > > > > distribute the GPL library with it or not. > > > > > > > > If you do not distribute the GPL library, the library is simply being > > > > used in the intended, ordinary way. You do not need to agree to, nor > > > > can you violate, the GPL simply by using a work in its ordinary > > > > intended way. > > > > > > > > If the application contains insufficient copyrightable expression > > > > from the library to be considered a derivative work (and purely > > > > functional things do not count), then it cannot be a derivative work. > > > > The library is not being copied or distributed. So how can its > > > > copyright be infringed? > > > > > > go ahead and create an application that uses a GPL only library. Then > > > ask a lawyer if it is okay to distribute your application in binary > > > only form without making the source code available (according to the > > > GPL). > > > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGP > > >L > > > > > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGP > > >L > > > > In the US, at least, the belief that "Linking", in *ANY* form, with a GPL > > library creates a derivative work, is fallacious. > > that is how FSF states it and it seems that most legal departments of > big companies (US and EU based) are not taking any risk on this. So it > seems that someone actually has to prove in court that these assumptions > for the GPL case are wrong. The FSF is making a claim that can be traced back to the beliefs of one person - RMS - and that propagate their views. As I stated in the original, this is not just my opinion, but that of two different lawyers I've spoken to and also the stated belief of numerous people on LKML. The fact is that the GPL only affects a "derivative work" in a viral manner. Merely using a GPL'd libraries API is not enough to make a program a "derivative work". > > Were I to create an > > application that uses, say, GTK for the interface the protected > > expression is my "unique and creative" use of the GTK API for creating > > the specific interface and any other code I have written using the API. I > > hold sole license to the copyright on that code and am able to license > > said code under the specific license of my choice. > > Not even getting into this one since GTK+ is a LGPL based library. Get > your examples straight. And the LGPL was created because of the FSF propagated belief that using a GPL'd library means your application is automatically a "derivative work" and hence must be released under the GPL. So the LGPL was created with the "automatic" 'linking' exemption. It is not necessary and never has been. This is why, even if the FSF claims what I've said above (that linking code with the GPL doesn't propagate the GPL into the non-GPL code) most companies won't risk it... Because the FSF has taken actions that are the exact opposite of their words. > > Why? Because the pre-processor is what is including any GPL'd code in my > > application and expanding any macros. That is a purely mechanical process > > and hence the output is not able to be separately copyrighted - if it > > could be, then the copyright would be held by the *COMPILER*, and I am > > *NOT* bound by the license on that code. The same applies if GPL'd code > > is included in my application during the linking process. QED: The > > "Linking" argument used by most people is wholly fallacious in at least > > one major country - and if I'm not mistaken, the output from an automated > > process is similarly not considered as carrying a separate copyright in > > all nations that are signatories of or follow the Bern Convention. > > The GPL is a license. Nobody is talking about the copyright of your code > here. You always have the copyright on your code. The point is that you > have to license your code under GPL (when using a GPL library) and you > are distributing your code. Yes, It is "my" code and "my" copyright. However, by the absolutely *common* belief that "linking to GPL libraries makes a program a derivative work" it would mean that I no longer have the freedom to license my code under the license of my choosing, because the *mechanical* process of linking has caused the GPL's "viral" clause to spread to cover my code. And you're absolutely wrong. It doesn't matter that the library is GPL'd at all. My code *cannot*, under any circumstances, be affected by the GPL license on the library. Because the libraries API *cannot* be copyrighted and any GPL'd code which winds up in the final binary got there via a "mechanical process" and doesn't affect my right to release the code under a license of my choosing. Any other belief is fallacious. Claiming otherwise would mean that any program that uses any library on a windows system makes an application a derivative work of that
Re: [PATCH] USB: mark USB drivers as being GPL only
On Saturday 09 February 2008 23:50:17 Marcel Holtmann wrote: > > > It makes no difference if you > > > distribute the GPL library with it or not. > > > > If you do not distribute the GPL library, the library is simply being > > used in the intended, ordinary way. You do not need to agree to, nor can > > you violate, the GPL simply by using a work in its ordinary intended way. > > > > If the application contains insufficient copyrightable expression from > > the library to be considered a derivative work (and purely functional > > things do not count), then it cannot be a derivative work. The library is > > not being copied or distributed. So how can its copyright be infringed? > > go ahead and create an application that uses a GPL only library. Then > ask a lawyer if it is okay to distribute your application in binary only > form without making the source code available (according to the GPL). > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL > > Regards > > Marcel In the US, at least, the belief that "Linking", in *ANY* form, with a GPL library creates a derivative work, is fallacious. Were I to create an application that uses, say, GTK for the interface the protected expression is my "unique and creative" use of the GTK API for creating the specific interface and any other code I have written using the API. I hold sole license to the copyright on that code and am able to license said code under the specific license of my choice. Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and hence the output is not able to be separately copyrighted - if it could be, then the copyright would be held by the *COMPILER*, and I am *NOT* bound by the license on that code. The same applies if GPL'd code is included in my application during the linking process. QED: The "Linking" argument used by most people is wholly fallacious in at least one major country - and if I'm not mistaken, the output from an automated process is similarly not considered as carrying a separate copyright in all nations that are signatories of or follow the Bern Convention. (And yes, this also applies to some GPL'd tools that RMS extended "GPL Exemptions" to - such as "Bison". There is, generally, no need for such an exemption, because the process by which the GPL'd code is included in the final binary is wholly mechanical.) DRH PS: The above information is a very condensed form of the result of several past conversations on this list about copyright law and the GPL as well as my own, private discussions with lawyers. I'm being lazy here and not searching various archives of LKML to give pointers to the past discussions. -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sunday 10 February 2008 00:43:49 Marcel Holtmann wrote: Hi Daniel, It makes no difference if you distribute the GPL library with it or not. If you do not distribute the GPL library, the library is simply being used in the intended, ordinary way. You do not need to agree to, nor can you violate, the GPL simply by using a work in its ordinary intended way. If the application contains insufficient copyrightable expression from the library to be considered a derivative work (and purely functional things do not count), then it cannot be a derivative work. The library is not being copied or distributed. So how can its copyright be infringed? go ahead and create an application that uses a GPL only library. Then ask a lawyer if it is okay to distribute your application in binary only form without making the source code available (according to the GPL). http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGP L http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGP L In the US, at least, the belief that Linking, in *ANY* form, with a GPL library creates a derivative work, is fallacious. that is how FSF states it and it seems that most legal departments of big companies (US and EU based) are not taking any risk on this. So it seems that someone actually has to prove in court that these assumptions for the GPL case are wrong. The FSF is making a claim that can be traced back to the beliefs of one person - RMS - and that propagate their views. As I stated in the original, this is not just my opinion, but that of two different lawyers I've spoken to and also the stated belief of numerous people on LKML. The fact is that the GPL only affects a derivative work in a viral manner. Merely using a GPL'd libraries API is not enough to make a program a derivative work. Were I to create an application that uses, say, GTK for the interface the protected expression is my unique and creative use of the GTK API for creating the specific interface and any other code I have written using the API. I hold sole license to the copyright on that code and am able to license said code under the specific license of my choice. Not even getting into this one since GTK+ is a LGPL based library. Get your examples straight. And the LGPL was created because of the FSF propagated belief that using a GPL'd library means your application is automatically a derivative work and hence must be released under the GPL. So the LGPL was created with the automatic 'linking' exemption. It is not necessary and never has been. This is why, even if the FSF claims what I've said above (that linking code with the GPL doesn't propagate the GPL into the non-GPL code) most companies won't risk it... Because the FSF has taken actions that are the exact opposite of their words. Why? Because the pre-processor is what is including any GPL'd code in my application and expanding any macros. That is a purely mechanical process and hence the output is not able to be separately copyrighted - if it could be, then the copyright would be held by the *COMPILER*, and I am *NOT* bound by the license on that code. The same applies if GPL'd code is included in my application during the linking process. QED: The Linking argument used by most people is wholly fallacious in at least one major country - and if I'm not mistaken, the output from an automated process is similarly not considered as carrying a separate copyright in all nations that are signatories of or follow the Bern Convention. The GPL is a license. Nobody is talking about the copyright of your code here. You always have the copyright on your code. The point is that you have to license your code under GPL (when using a GPL library) and you are distributing your code. Yes, It is my code and my copyright. However, by the absolutely *common* belief that linking to GPL libraries makes a program a derivative work it would mean that I no longer have the freedom to license my code under the license of my choosing, because the *mechanical* process of linking has caused the GPL's viral clause to spread to cover my code. And you're absolutely wrong. It doesn't matter that the library is GPL'd at all. My code *cannot*, under any circumstances, be affected by the GPL license on the library. Because the libraries API *cannot* be copyrighted and any GPL'd code which winds up in the final binary got there via a mechanical process and doesn't affect my right to release the code under a license of my choosing. Any other belief is fallacious. Claiming otherwise would mean that any program that uses any library on a windows system makes an application a derivative work of that library. DRH PS: I'm going to shut up again, because I've been party in my fill of these copyright/derivative work discussions (on both sides) and have had the
Re: [PATCH] USB: mark USB drivers as being GPL only
On Friday 08 February 2008 16:36:37 Alan Cox wrote: > > In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", > > but people ignoring this and doing things that circumvent this will, > > eventually, have problems with the people who hold the copyright on the > > code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" > > bit might also be in violation of the DMCA, but he isn't sure if a court > > would see it in the same light as someone cracking the CSS key on a DVD > > expressly for the purpose of creating pirated copies) > > There was a good analysis of that argument on the list some time ago. I > think the conclusion was fairly definitively no as the GPL explicitly > gives the right to modify GPL code. You are therefore aready "authorised" > to make such a change. > > It might have a significance in terms of intent but thats for lawyers to > argue over. > > Alan I think that's why he said he "Wasn't Sure" - as was pointed out in another post, the Lexmark ruling appears to apply for more than the "interface" portion of the ruling. And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said "I think this is so core to the kernel that anything using it is a derivative work" - is what he thought *MIGHT* be legally actionable under the DMCA. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Friday 08 February 2008 14:08:21 David Newall wrote: > I explained something poorly: > > Now, Alan has made a big issue over numerous legal opinions he has > > received, but he's been completely coy in the details. > > The point I wanted to make is that a few people have said that lawyers > say that kernel modules are derivative, but I only remember Alan saying > that he had actually spoken with the lawyers. Therefore I infer that > this somewhat widely held opinion originates from him. My point was to > those people who have been taking him at his word, and was to point out > that there are more reliable and transparent sources. Don't take his > word on it. Take the words of real experts in the law, because instead > of a mere four word conclusion, they explain everything. The one technically inclined lawyer that I asked about this said that the Lexmark decision meant that code using an API did not mean the work was a derivative of the API. However, in the case of the Linux Kernel, the code is meant to function inside a much larger framework and the API available to modules includes large amounts of "boilerplate code" buried behind handy chunks of code like "list_for_each". The problem, he said, was that, in the US, such code is included in the module in a mechanical and wholly automated process. Which means that the module doesn't automatically inherit the GPL license. But, he cautioned me, this does not mean that a court couldn't (and/or wouldn't) rule that a module written specifically for Linux is a derivative of the kernel. He also cautioned that, although the Bern Convention broadly controlled international copyright laws, specific countries do seem to have laws that cover the "kernel module" situation much better than the US laws and that those laws do apparently make a module a derivative of the kernel. His overall statement on it was that, in his opinion, whether a given module is a derivative or not would depend on the amount of "original" work contained in it compared to the number of places where linux specific code is used. He also stated that, while disagreeing with the idea that parts of an API could be "so deeply embedded that using them creates a derivative work", it would be a good idea to always pay attention to the beliefs of the developers of the code, because it is their opinion that will start the legal problems. In other words "EXPORT_SYMBOL_GPL" isn't his idea of "a good legal idea", but people ignoring this and doing things that circumvent this will, eventually, have problems with the people who hold the copyright on the code. (In addition, he stated that circumventing the "EXPORT_SYMBOL_GPL" bit might also be in violation of the DMCA, but he isn't sure if a court would see it in the same light as someone cracking the CSS key on a DVD expressly for the purpose of creating pirated copies) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: mark USB drivers as being GPL only
On Friday 08 February 2008 16:36:37 Alan Cox wrote: In other words EXPORT_SYMBOL_GPL isn't his idea of a good legal idea, but people ignoring this and doing things that circumvent this will, eventually, have problems with the people who hold the copyright on the code. (In addition, he stated that circumventing the EXPORT_SYMBOL_GPL bit might also be in violation of the DMCA, but he isn't sure if a court would see it in the same light as someone cracking the CSS key on a DVD expressly for the purpose of creating pirated copies) There was a good analysis of that argument on the list some time ago. I think the conclusion was fairly definitively no as the GPL explicitly gives the right to modify GPL code. You are therefore aready authorised to make such a change. It might have a significance in terms of intent but thats for lawyers to argue over. Alan I think that's why he said he Wasn't Sure - as was pointed out in another post, the Lexmark ruling appears to apply for more than the interface portion of the ruling. And Alan, while it might be legal to make the changes, making them for the sole purpose of using them in a proprietary module - when the people who actually hold the copyright have said I think this is so core to the kernel that anything using it is a derivative work - is what he thought *MIGHT* be legally actionable under the DMCA. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24 refuses to boot - ATA problem?
On Sunday 03 February 2008 12:36:33 Jeff Garzik wrote:
> Daniel Hazelton wrote:
> > On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
> >> Hi,
> >>
> >> I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
> >> PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer
> >> is failing to initialise:
> >
> >
> >
> >> Driver 'sd' needs updating - please use bus_type methods
> >> scsi0 : ata_piix
> >> scsi1 : ata_piix
> >> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
> >> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
> >> ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
> >> ata1.00: 39851760 sectors, multi 16: LBA
> >> ata1.00: configured for UDMA/66
> >> ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
> >> UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
> >> ata2.00: configured for UDMA/66
> >> ata2.01: configured for UDMA/33
> >> scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0
> >> ANSI: 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
> >> sd 0:0:0:0: [sda] Write Protect is off
> >> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> >> support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
> >> (20404 MB)
> >> sd 0:0:0:0: [sda] Write Protect is off
> >> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> >> support DPO or FUA sda:<4>ehci_hcd :03:0d.2: Unlink after no-IRQ?
> >> Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
> >> SAct 0x0 SErr 0x0 action 0x2 frozen
> >> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >> ata1.00: status: { DRDY }
> >> ata1: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> >> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> >> ata1.00: status: { DRDY }
> >> ata1: soft resetting link
> >> ata1.00: configured for UDMA/66
> >> ata1: EH complete
> >> SysRq : Emergency Sync
> >> Emergency Sync complete
> >> SysRq : Emergency Remount R/O
> >> Emergency Remount complete
> >> SysRq : Resetting
> >
> > This error is what I mentioned in a post yesterday that mentioned several
> > errors I've seen with a recent kernel built from linus' git.
> >
> > The only difference is that here the kernel starts at UDMA/133 and
> > devolves all the way down to PIO0 before spinning forever at that. A
> > fully "cold" boot (ie: removing all power from the system for a period of
> > several minutes and then powering it back on) seems to fix this problem.
> >
> > I've got a kernel here built from git b036555adc but I haven't tested it
> > yet. If the problem still occurs with it, I'll try to get a copy of the
> > output posted here.
>
> If its reproducible, please bisect... That will tell us precisely the
> problematic change.
>
> Jeff
It doesn't occur with 36555adc here - at least, it didn't the two times I've
booted a kernel built from that tree. With 36555adc I have other problems and
will be refreshing my copy of the code first. But I will start bisecting if
the problem persists.
I'm also going to make sure it wasn't caused by something strange, although,
IIRC, the only real differences in the configs from the kernel that booted
but had the somewhat random libata problem and the "strange xchat lockup"
problem is the CPA code and the "pre-emptible RCU" - so I'm going to turning
off one and then both of those options.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24 refuses to boot - ATA problem?
On Sunday 03 February 2008 12:36:33 Jeff Garzik wrote:
Daniel Hazelton wrote:
On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
Hi,
I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer
is failing to initialise:
snip
Driver 'sd' needs updating - please use bus_type methods
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
ata1.00: 39851760 sectors, multi 16: LBA
ata1.00: configured for UDMA/66
ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
ata2.00: configured for UDMA/66
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0
ANSI: 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
(20404 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA sda:4ehci_hcd :03:0d.2: Unlink after no-IRQ?
Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for UDMA/66
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for UDMA/66
ata1: EH complete
SysRq : Emergency Sync
Emergency Sync complete
SysRq : Emergency Remount R/O
Emergency Remount complete
SysRq : Resetting
This error is what I mentioned in a post yesterday that mentioned several
errors I've seen with a recent kernel built from linus' git.
The only difference is that here the kernel starts at UDMA/133 and
devolves all the way down to PIO0 before spinning forever at that. A
fully cold boot (ie: removing all power from the system for a period of
several minutes and then powering it back on) seems to fix this problem.
I've got a kernel here built from git b036555adc but I haven't tested it
yet. If the problem still occurs with it, I'll try to get a copy of the
output posted here.
If its reproducible, please bisect... That will tell us precisely the
problematic change.
Jeff
It doesn't occur with 36555adc here - at least, it didn't the two times I've
booted a kernel built from that tree. With 36555adc I have other problems and
will be refreshing my copy of the code first. But I will start bisecting if
the problem persists.
I'm also going to make sure it wasn't caused by something strange, although,
IIRC, the only real differences in the configs from the kernel that booted
but had the somewhat random libata problem and the strange xchat lockup
problem is the CPA code and the pre-emptible RCU - so I'm going to turning
off one and then both of those options.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Sunday 03 February 2008 00:03:10 Greg KH wrote: > On Sat, Feb 02, 2008 at 07:52:37PM -0500, Daniel Hazelton wrote: > > On Saturday 02 February 2008 19:22:49 Greg KH wrote: > > > On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: > > > > > > > > > > @@ -145,6 +145,10 @@ as small as possible, and that all potential > > > > interfaces are tested as well as they can be (unused interfaces are > > > > pretty much impossible to test for validity.) > > > > > > > > +However, changing an interface can be delicate work and it can take > > > > +significant amount of developer effort. Therefore, an interface is > > > > +not changed unless the change is regarded as very important by the > > > > +developers. > > > > > > > > What to do > > > > -- > > > > > > I still don't understand why you want to add these sentances. Why are > > > they needed? Are people thinking that the kernel developers just > > > randomly change things just because they are bored and have nothing > > > else to do at the moment? Do people think that our changes are > > > gratuitous? > > > > > > Even so, I don't think this needs to be added, we have already stated > > > many good reasons why changing apis are necessary and good. Do need to > > > add another one? > > > > Actually, Greg, a hell of a lot of people that don't track linux kernel > > development do think that way. And there are always going to be people > > that think that way. > > So why would to more sentances trying to say "see, we really do know > what we are doing, we aren't idiots" make things any better to these > people? (hint, it wouldn't...) I know this, because I've never needed to even read the document to understand why the API may have to change. But there are people that are very brain dead - I mean *EXTREMELY* brain dead who will start drooling and not understand the whole point of the document without a simple statement like the above. It is those people - and I've had a hell of a lot of contact with them (including people manning the phones in tech support departments!) - that wouldn't understand that the reason for the lack of a "fixed, stable API" is because of the various API changes that add capacity. (Instead they'd say "But MS does it with Windows" - ignoring the fact that the Windows API changed when NT3.51 was released, changed again when Win95 was released and has changed with *EVERY* release of Windows since - to the point that there are programs written for Win95 that can't/won't run on an XP machine.) > > As it stands the recommended paragraph does clarify that, while the > > interfaces aren't stable, can and will change as needed, there are some > > core interfaces that *WON'T* change without a very good reason. > > Again, do you think we kernel developers just randomly change core apis > because we are bored and want something to do late at night when we > can't sleep and are tired of playing Rock Band? No, I don't. Never have. But the fact is that there *ARE* people who do think that way. I've had a hell of a lot of contact with them. When I talk to people about using Linux (locally - I get "pinged" by someone every time I walk into a store to buy something, anymore) there is at least one person who complains that they can't run Linux because required hardware X isn't supported, and the manufacturer says its because there isn't a stable API to write the driver against. (though it's usually a lot coarser and less technical - I'm sure you understand) > > Having such a public statement that anyone can see and people can > > point to is another weapon to help people fight the FUD that exists > > around Linux. > > The whole article explains why apis are change for very good reasons > (evolution of hardware, security, we now know better, etc.) That's the > whole point of the document... Yes, it does, but you are making the mistake I used to make all the time and assuming that most people are going to actually have the ability to take the information in the document and comprehend that any *ONE* of the reasons that a stable API is bad is enough to not have one. Having such a paragraph to point to - or just having it there when those dead-brained people actually find and read the document - will definitely be a good thing. ... And now that I've re-iterated and explained the rather poor opinion I have of most people in the world and how it applies to this situation, I'm going to shut up and not say another word about this. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Saturday 02 February 2008 19:22:49 Greg KH wrote: > On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: > > @@ -145,6 +145,10 @@ as small as possible, and that all potential > > interfaces are tested as well as they can be (unused interfaces are > > pretty much impossible to test for validity.) > > > > +However, changing an interface can be delicate work and it can take > > +significant amount of developer effort. Therefore, an interface is > > +not changed unless the change is regarded as very important by the > > +developers. > > > > What to do > > -- > > I still don't understand why you want to add these sentances. Why are > they needed? Are people thinking that the kernel developers just > randomly change things just because they are bored and have nothing else > to do at the moment? Do people think that our changes are gratuitous? > > Even so, I don't think this needs to be added, we have already stated > many good reasons why changing apis are necessary and good. Do need to > add another one? > > thanks, > > greg k-h Actually, Greg, a hell of a lot of people that don't track linux kernel development do think that way. And there are always going to be people that think that way. As it stands the recommended paragraph does clarify that, while the interfaces aren't stable, can and will change as needed, there are some core interfaces that *WON'T* change without a very good reason. Having such a public statement that anyone can see and people can point to is another weapon to help people fight the FUD that exists around Linux. DRH (And yes, I do fight anti-linux FUD all the time. My parents have been using my laptops and can actually be quoted as saying that the next computer they buy will run Linux! My family mostly runs Windows - my brothers because their kids would complain about not being able to play their games and my sister because her husband is so computer illiterate I'm amazed he actually knows how to do a Google search) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24 refuses to boot - ATA problem?
On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
> Hi,
>
> I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
> PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer is
> failing to initialise:
>
> Driver 'sd' needs updating - please use bus_type methods
> scsi0 : ata_piix
> scsi1 : ata_piix
> ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
> ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
> ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
> ata1.00: 39851760 sectors, multi 16: LBA
> ata1.00: configured for UDMA/66
> ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
> UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
> ata2.00: configured for UDMA/66
> ata2.01: configured for UDMA/33
> scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0 ANSI:
> 5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
> (20404 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA sda:<4>ehci_hcd :03:0d.2: Unlink after no-IRQ?
> Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
> SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for UDMA/66
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for UDMA/66
> ata1: EH complete
> SysRq : Emergency Sync
> Emergency Sync complete
> SysRq : Emergency Remount R/O
> Emergency Remount complete
> SysRq : Resetting
This error is what I mentioned in a post yesterday that mentioned several
errors I've seen with a recent kernel built from linus' git.
The only difference is that here the kernel starts at UDMA/133 and devolves
all the way down to PIO0 before spinning forever at that. A fully "cold" boot
(ie: removing all power from the system for a period of several minutes and
then powering it back on) seems to fix this problem.
I've got a kernel here built from git b036555adc but I haven't tested it yet.
If the problem still occurs with it, I'll try to get a copy of the output
posted here.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 2.6.24 refuses to boot - ATA problem?
On Saturday 02 February 2008 18:40:55 Chris Rankin wrote:
Hi,
I have tried to boot a 2.6.24 kernel on my 1 GHz Coppermine / 512 MB RAM
PC. (This is without the nmi_watchdog=1 option.) However, the ATA layer is
failing to initialise:
snip
Driver 'sd' needs updating - please use bus_type methods
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xa800 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xa808 irq 15
ata1.00: ATA-4: ST320420A, 3.12, max UDMA/66
ata1.00: 39851760 sectors, multi 16: LBA
ata1.00: configured for UDMA/66
ata2.00: ATAPI: Pioneer DVD-ROM ATAPIModel DVD-116 0122, E1.22, max
UDMA/66 ata2.01: ATAPI: SONYCD-RW CRX145E, 1.0b, max UDMA/33
ata2.00: configured for UDMA/66
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA ST320420A3.12 PQ: 0 ANSI:
5 sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors (20404 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA sd 0:0:0:0: [sda] 39851760 512-byte hardware sectors
(20404 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA sda:4ehci_hcd :03:0d.2: Unlink after no-IRQ?
Controller is probably using the wrong IRQ. ata1.00: exception Emask 0x0
SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for UDMA/66
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: soft resetting link
ata1.00: configured for UDMA/66
ata1: EH complete
SysRq : Emergency Sync
Emergency Sync complete
SysRq : Emergency Remount R/O
Emergency Remount complete
SysRq : Resetting
This error is what I mentioned in a post yesterday that mentioned several
errors I've seen with a recent kernel built from linus' git.
The only difference is that here the kernel starts at UDMA/133 and devolves
all the way down to PIO0 before spinning forever at that. A fully cold boot
(ie: removing all power from the system for a period of several minutes and
then powering it back on) seems to fix this problem.
I've got a kernel here built from git b036555adc but I haven't tested it yet.
If the problem still occurs with it, I'll try to get a copy of the output
posted here.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Saturday 02 February 2008 19:22:49 Greg KH wrote: On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: snip @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +However, changing an interface can be delicate work and it can take +significant amount of developer effort. Therefore, an interface is +not changed unless the change is regarded as very important by the +developers. What to do -- I still don't understand why you want to add these sentances. Why are they needed? Are people thinking that the kernel developers just randomly change things just because they are bored and have nothing else to do at the moment? Do people think that our changes are gratuitous? Even so, I don't think this needs to be added, we have already stated many good reasons why changing apis are necessary and good. Do need to add another one? thanks, greg k-h Actually, Greg, a hell of a lot of people that don't track linux kernel development do think that way. And there are always going to be people that think that way. As it stands the recommended paragraph does clarify that, while the interfaces aren't stable, can and will change as needed, there are some core interfaces that *WON'T* change without a very good reason. Having such a public statement that anyone can see and people can point to is another weapon to help people fight the FUD that exists around Linux. DRH (And yes, I do fight anti-linux FUD all the time. My parents have been using my laptops and can actually be quoted as saying that the next computer they buy will run Linux! My family mostly runs Windows - my brothers because their kids would complain about not being able to play their games and my sister because her husband is so computer illiterate I'm amazed he actually knows how to do a Google search) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve Documentation/stable_api_nonsense.txt v2
On Sunday 03 February 2008 00:03:10 Greg KH wrote: On Sat, Feb 02, 2008 at 07:52:37PM -0500, Daniel Hazelton wrote: On Saturday 02 February 2008 19:22:49 Greg KH wrote: On Sat, Feb 02, 2008 at 04:44:57PM +0200, Heikki Orsila wrote: snip @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.) +However, changing an interface can be delicate work and it can take +significant amount of developer effort. Therefore, an interface is +not changed unless the change is regarded as very important by the +developers. What to do -- I still don't understand why you want to add these sentances. Why are they needed? Are people thinking that the kernel developers just randomly change things just because they are bored and have nothing else to do at the moment? Do people think that our changes are gratuitous? Even so, I don't think this needs to be added, we have already stated many good reasons why changing apis are necessary and good. Do need to add another one? Actually, Greg, a hell of a lot of people that don't track linux kernel development do think that way. And there are always going to be people that think that way. So why would to more sentances trying to say see, we really do know what we are doing, we aren't idiots make things any better to these people? (hint, it wouldn't...) I know this, because I've never needed to even read the document to understand why the API may have to change. But there are people that are very brain dead - I mean *EXTREMELY* brain dead who will start drooling and not understand the whole point of the document without a simple statement like the above. It is those people - and I've had a hell of a lot of contact with them (including people manning the phones in tech support departments!) - that wouldn't understand that the reason for the lack of a fixed, stable API is because of the various API changes that add capacity. (Instead they'd say But MS does it with Windows - ignoring the fact that the Windows API changed when NT3.51 was released, changed again when Win95 was released and has changed with *EVERY* release of Windows since - to the point that there are programs written for Win95 that can't/won't run on an XP machine.) As it stands the recommended paragraph does clarify that, while the interfaces aren't stable, can and will change as needed, there are some core interfaces that *WON'T* change without a very good reason. Again, do you think we kernel developers just randomly change core apis because we are bored and want something to do late at night when we can't sleep and are tired of playing Rock Band? No, I don't. Never have. But the fact is that there *ARE* people who do think that way. I've had a hell of a lot of contact with them. When I talk to people about using Linux (locally - I get pinged by someone every time I walk into a store to buy something, anymore) there is at least one person who complains that they can't run Linux because required hardware X isn't supported, and the manufacturer says its because there isn't a stable API to write the driver against. (though it's usually a lot coarser and less technical - I'm sure you understand) Having such a public statement that anyone can see and people can point to is another weapon to help people fight the FUD that exists around Linux. The whole article explains why apis are change for very good reasons (evolution of hardware, security, we now know better, etc.) That's the whole point of the document... Yes, it does, but you are making the mistake I used to make all the time and assuming that most people are going to actually have the ability to take the information in the document and comprehend that any *ONE* of the reasons that a stable API is bad is enough to not have one. Having such a paragraph to point to - or just having it there when those dead-brained people actually find and read the document - will definitely be a good thing. ... And now that I've re-iterated and explained the rather poor opinion I have of most people in the world and how it applies to this situation, I'm going to shut up and not say another word about this. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Various Errors with recent GIT
On Friday 01 February 2008 23:42:47 Gabriel C wrote: > Daniel Hazelton wrote: > > Another problem is one I wasn't able to find any kind of trigger for, > > other than just running XChat. Every so often XChat would seem to freeze > > - but if run from the command line, switching to that terminal window and > > hitting "ctrl-c" would cause it to rapidly update and become responsive > > again. The freeze would happen at a random time interval that I couldn't > > figure out. > > I got that Xchat problem on i686 yesterday. > > I'm running 2.6.24-06481-gaa62999 right now with near 4h uptime and the > problem seems fixed. Hrm... I'll see about updating my local git tree and building a new kernel. With the x86 merger if it's fixed in 32bit it is probably also fixed in 64bit. The other problems are a bigger concern, though. I don't like seeing warnings in my logs - makes me worry about the long-term stability of my systems. And with the apparent problem in libata I'm not too sure I will be able to successfully boot into a new kernel - after all, the system just spins on trying and retrying the drive without any progress. (And it seems random, though it does appear that the trick to a successful boot is to get the hardware completely powered down - in other words, a completely cold boot) DRH > > DRH > > Gabriel -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Various Errors with recent GIT
In a recent (haven't tested the latest git, but I have tested one pulled down
1/29 - I think it's 24e1c13) I see the following errors when the AES crypto
module is loaded:
[ 27.786935] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.786984] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.787141] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.787187] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.787232] aes_x86_64: Unknown symbol crypto_ft_tab
[ 27.625672] aes_x86_64: Unknown symbol crypto_it_tab
[ 27.625721] aes_x86_64: Unknown symbol crypto_aes_set_key
[ 27.625793] aes_x86_64: Unknown symbol crypto_fl_tab
[ 27.625838] aes_x86_64: Unknown symbol crypto_il_tab
[ 27.625883] aes_x86_64: Unknown symbol crypto_ft_tab
Another problem is one I wasn't able to find any kind of trigger for, other
than just running XChat. Every so often XChat would seem to freeze - but if
run from the command line, switching to that terminal window and
hitting "ctrl-c" would cause it to rapidly update and become responsive again.
The freeze would happen at a random time interval that I couldn't figure out.
The last two problems have different symptoms. With one the kernel would
sometimes spin unable to get a non-error return from the CD/DVD burner drive
in my laptop - it'd start at UDMA133 and rapidly devolve down to PIO0 and then
spin trying and retrying PIO0. The only part of the message I remember exactly
is { DRDY } on 90% of the messages once it switched to trying only the PIO
modes, although I have seen similar messages about this kind of error on the
list recently.
And the final error is one that I've been seeing since 2.6.24-rc6 and reported
as a secondary error in 2.6.24-rc7. The mac80211 system hits a warning when my
system initially brings my Wifi connection (iwlwifi is the driver) online. The
problem points to the following line:
WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
so it looks as though the initial packet from the device coming online and/or
registering with the network is corrupt. This does not happen when I boot
2.6.22 and load the pre-merge iwlwifi/mac80211 code and I do not have the time
or resources to bisect this problem at the moment or I would be trying to find
the cause. (This isn't a hardware problem like I initially thought, since the
code states that it's up to the driver to format the packet correctly - I
haven't been able to locate any changes to the iwlwifi code post import, (in
the recieve path that would have caused this, but the search was non
exhaustive) so I'm wondering if this might be a pre-existing bug...)
[ 49.960849] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 50.185438] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx()
[ 50.185446] Pid: 0, comm: swapper Not tainted 2.6.24-rc7-git #1
[ 50.185450]
[ 50.185451] Call Trace:
[ 50.185454][] :mac80211:__ieee80211_rx+0xc99/0xd60
[ 50.185509] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.185526] [] :iwl3945:iwl_rx_queue_restock+0xca/0x170
[ 50.185533] [] _spin_unlock_irqrestore+0x16/0x40
[ 50.18] []
:mac80211:ieee80211_tasklet_handler+0xb8/0x120
[ 50.185570] [] tasklet_action+0x51/0xc0
[ 50.185576] [] _spin_unlock+0x14/0x40
[ 50.185583] [] __do_softirq+0x64/0xe0
[ 50.185592] [] call_softirq+0x1c/0x30
[ 50.185599] [] do_softirq+0x3d/0x90
[ 50.185605] [] irq_exit+0x88/0xa0
[ 50.185611] [] do_IRQ+0xc5/0x1b0
[ 50.185619] [] ret_from_intr+0x0/0xa
[ 50.185628][]
:processor:acpi_idle_enter_bm+0x273/0x2e3
[ 50.185647] [] :processor:acpi_idle_enter_bm+0x269/0x2e3
[ 50.185652] [] menu_select+0xad/0xe0
[ 50.185657] [] cpuidle_idle_call+0x95/0xd0
[ 50.185661] [] cpuidle_idle_call+0x0/0xd0
[ 50.185665] [] cpu_idle+0x73/0xe0
[ 50.185670] [] start_secondary+0x315/0x410
[ 50.185683]
(That's the complete warning from my 2.6.24-rc7 kernel... The following is the
complete warning from the 24e1c13 build)
[ 182.298665] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 182.359208] ppdev: user-space parallel port driver
[ 182.623816] [ cut here ]
[ 182.623826] WARNING: at net/mac80211/rx.c:1704
__ieee80211_rx_handle_packet+0x8e7/0x980 [mac80211]()
[ 182.623831] Modules linked in: ppdev acpi_cpufreq cpufreq_ondemand
cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats freq_t
able dock container sbs sbshc dm_crypt dm_mod ipv6 sbp2 parport_pc lp parport
arc4 ecb crypto_blkcipher iwl3945 mac80211 cfg80211 ata_generic snd_hda_intel
snd_hwdep snd_pcm_oss s
nd_pcm snd_page_alloc snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event sdhci serio_raw psmouse pcspkr iTCO_wdt
iTCO_vendor_support ricoh_mmc mmc
_core pata_acpi snd_seq snd_timer snd_seq_device video snd soundcore ac shpchp
pci_hotplug button battery intel_agp evdev ext3 jbd mbcache sg sd_mod ohci1394
ieee1394 ata_piix ahc
i tg3 libata scsi_mod ehci_hcd uhci_hcd usbcore
Re: Various Errors with recent GIT
On Friday 01 February 2008 23:42:47 Gabriel C wrote: Daniel Hazelton wrote: Another problem is one I wasn't able to find any kind of trigger for, other than just running XChat. Every so often XChat would seem to freeze - but if run from the command line, switching to that terminal window and hitting ctrl-c would cause it to rapidly update and become responsive again. The freeze would happen at a random time interval that I couldn't figure out. I got that Xchat problem on i686 yesterday. I'm running 2.6.24-06481-gaa62999 right now with near 4h uptime and the problem seems fixed. Hrm... I'll see about updating my local git tree and building a new kernel. With the x86 merger if it's fixed in 32bit it is probably also fixed in 64bit. The other problems are a bigger concern, though. I don't like seeing warnings in my logs - makes me worry about the long-term stability of my systems. And with the apparent problem in libata I'm not too sure I will be able to successfully boot into a new kernel - after all, the system just spins on trying and retrying the drive without any progress. (And it seems random, though it does appear that the trick to a successful boot is to get the hardware completely powered down - in other words, a completely cold boot) DRH DRH Gabriel -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ndiswrapper and GPL-only symbols redux
On Tuesday 29 January 2008 19:46:06 Måns Rullgård wrote: > Adrian Bunk <[EMAIL PROTECTED]> writes: > > On Tue, Jan 29, 2008 at 11:25:22PM +, Måns Rullgård wrote: > >> Adrian Bunk <[EMAIL PROTECTED]> writes: > >> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote: > >> >> Hello! > >> >> > >> >> It have come to my attention that a patch has been committed to the > >> >> kernel with the explicit purpose of tainting ndiswrapper - the kernel > >> >> module allowing Windows NDIS drivers for Ethernet and Wireless cards > >> >> to be used by the kernel. > >> >>... > >> >> Just to reiterate some points from the old discussion: > >> >>... > >> >> - no copyright violation is involved, as Windows drivers are not > >> >> derived from Linux sources > >> >>... > >> > > >> > It is interesting that someone posting with an @gnu.org address claims > >> > that dynamic linking of not GPLv2 compatible code into GPLv2 code was > >> > not a copyright violation. > >> > >> As long as you don't distribute /proc/kcore, I can't see how the GPL > >> would have any say in the matter. The Windows drivers are (unrelated > >> violations aside) clearly not derived from GPL code. Only because of the distribution of the windows driver. As I understand US and International copyright law, dynamic linking cannot create a new, derivative work and hence cannot carry its own license. (It's a "machine translation") What that means is that there is no violation of the GPL if GPL'd code is linked to proprietary code and then distributed. However, the GPLv3 does have language in it that would require the proprietary code to also be distributed. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ndiswrapper and GPL-only symbols redux
On Tuesday 29 January 2008 19:46:06 Måns Rullgård wrote: Adrian Bunk [EMAIL PROTECTED] writes: On Tue, Jan 29, 2008 at 11:25:22PM +, Måns Rullgård wrote: Adrian Bunk [EMAIL PROTECTED] writes: On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote: Hello! It have come to my attention that a patch has been committed to the kernel with the explicit purpose of tainting ndiswrapper - the kernel module allowing Windows NDIS drivers for Ethernet and Wireless cards to be used by the kernel. ... Just to reiterate some points from the old discussion: ... - no copyright violation is involved, as Windows drivers are not derived from Linux sources ... It is interesting that someone posting with an @gnu.org address claims that dynamic linking of not GPLv2 compatible code into GPLv2 code was not a copyright violation. As long as you don't distribute /proc/kcore, I can't see how the GPL would have any say in the matter. The Windows drivers are (unrelated violations aside) clearly not derived from GPL code. Only because of the distribution of the windows driver. As I understand US and International copyright law, dynamic linking cannot create a new, derivative work and hence cannot carry its own license. (It's a machine translation) What that means is that there is no violation of the GPL if GPL'd code is linked to proprietary code and then distributed. However, the GPLv3 does have language in it that would require the proprietary code to also be distributed. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8: iwl3945 gets stuck
On Tuesday 22 January 2008 17:15:42 John W. Linville wrote: > On Tue, Jan 22, 2008 at 09:54:11PM +0100, Harald Dunkel wrote: > > If I put some heavy load on the iwl3945, then the network connection > > gets stuck after a some time. To fix it I have to reload the module. > > Can you quantify this a bit more? What constitutes a "heavey load"? > What (if any) encryption are you using? Are you using any options > for iwl3945 in /etc/modprobe.conf? > > Could you include the output of dmesg and/or the contents of > /var/log/messages (trimmed for the most recent boot)? > > > AFAICS this problem was a topic on lkml almost 3 months ago. Any news > > about this? I would be glad to help to track this down, but I have > > no idea how to change the scaling algorithm to iwl-3945-rs . > > This should happen automatically now. > > John I've been getting a warning in the dmesg of my laptop with every boot since I started using 2.6.24-rc7 that might be related. This doesn't appear to cause any problems, but from looking at the source of the warning it appears that the ipw3945 hardware might be causing the problem. [ 31.460143] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 31.549722] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx() [ 31.549817] Pid: 4436, comm: amixer Not tainted 2.6.24-rc7-git2 #1 [ 31.549903] [ 31.549904] Call Trace: [ 31.550063][] :mac80211:__ieee80211_rx+0xc99/0xd60 [ 31.550236] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.550332] [] :iwl3945:iwl_rx_queue_restock+0xca/0x170 [ 31.550422] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.550520] [] :mac80211:ieee80211_tasklet_handler+0xb8/0x120 [ 31.550646] [] tasklet_action+0x51/0xc0 [ 31.550732] [] _spin_unlock+0x14/0x40 [ 31.550820] [] __do_softirq+0x64/0xe0 [ 31.550909] [] call_softirq+0x1c/0x30 [ 31.550995] [] do_softirq+0x3d/0x90 [ 31.551083] [] irq_exit+0x88/0xa0 [ 31.551169] [] do_IRQ+0xc5/0x1b0 [ 31.551257] [] ret_from_intr+0x0/0xa [ 31.551369][] get_page_from_freelist+0x30e/0x670 [ 31.551519] [] __alloc_pages+0x6e/0x3b0 [ 31.551608] [] generic_file_aio_read+0xd7/0x180 [ 31.551699] [] alloc_page_vma+0x9c/0xf0 [ 31.551788] [] handle_mm_fault+0x50e/0x780 [ 31.551874] [] _spin_unlock+0x14/0x40 [ 31.551962] [] _spin_unlock_irqrestore+0x16/0x40 [ 31.552052] [] do_page_fault+0x228/0x970 [ 31.552146] [] _spin_unlock+0x14/0x40 [ 31.552251] [] vfs_read+0x13e/0x180 [ 31.552340] [] error_exit+0x0/0x51 [ 31.552436] The location of the warning is: hdrlen = ieee80211_get_hdrlen(rx.fc); line in question -->WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT) local->dot11ReceivedFragmentCount++; sta = rx.sta = sta_info_get(local, hdr->addr2); Now, the problem is that this might be nothing, and it might be the cause of the problem. (I don't think it is the cause, myself, because I've subjected my laptop to a lot of activity - to the point that the card was starting to drop packets - and have seen no problems) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc8: iwl3945 gets stuck
On Tuesday 22 January 2008 17:15:42 John W. Linville wrote: On Tue, Jan 22, 2008 at 09:54:11PM +0100, Harald Dunkel wrote: If I put some heavy load on the iwl3945, then the network connection gets stuck after a some time. To fix it I have to reload the module. Can you quantify this a bit more? What constitutes a heavey load? What (if any) encryption are you using? Are you using any options for iwl3945 in /etc/modprobe.conf? Could you include the output of dmesg and/or the contents of /var/log/messages (trimmed for the most recent boot)? AFAICS this problem was a topic on lkml almost 3 months ago. Any news about this? I would be glad to help to track this down, but I have no idea how to change the scaling algorithm to iwl-3945-rs . This should happen automatically now. John I've been getting a warning in the dmesg of my laptop with every boot since I started using 2.6.24-rc7 that might be related. This doesn't appear to cause any problems, but from looking at the source of the warning it appears that the ipw3945 hardware might be causing the problem. [ 31.460143] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 31.549722] WARNING: at net/mac80211/rx.c:1486 __ieee80211_rx() [ 31.549817] Pid: 4436, comm: amixer Not tainted 2.6.24-rc7-git2 #1 [ 31.549903] [ 31.549904] Call Trace: [ 31.550063] IRQ [8823c309] :mac80211:__ieee80211_rx+0xc99/0xd60 [ 31.550236] [80473a36] _spin_unlock_irqrestore+0x16/0x40 [ 31.550332] [8828930a] :iwl3945:iwl_rx_queue_restock+0xca/0x170 [ 31.550422] [80473a36] _spin_unlock_irqrestore+0x16/0x40 [ 31.550520] [8822d228] :mac80211:ieee80211_tasklet_handler+0xb8/0x120 [ 31.550646] [80246741] tasklet_action+0x51/0xc0 [ 31.550732] [80473974] _spin_unlock+0x14/0x40 [ 31.550820] [80246644] __do_softirq+0x64/0xe0 [ 31.550909] [8020d57c] call_softirq+0x1c/0x30 [ 31.550995] [8020ef0d] do_softirq+0x3d/0x90 [ 31.551083] [80246558] irq_exit+0x88/0xa0 [ 31.551169] [8020f025] do_IRQ+0xc5/0x1b0 [ 31.551257] [8020c8d1] ret_from_intr+0x0/0xa [ 31.551369] EOI [802874be] get_page_from_freelist+0x30e/0x670 [ 31.551519] [802878ce] __alloc_pages+0x6e/0x3b0 [ 31.551608] [80283417] generic_file_aio_read+0xd7/0x180 [ 31.551699] [802a256c] alloc_page_vma+0x9c/0xf0 [ 31.551788] [8029281e] handle_mm_fault+0x50e/0x780 [ 31.551874] [80473974] _spin_unlock+0x14/0x40 [ 31.551962] [80473a36] _spin_unlock_irqrestore+0x16/0x40 [ 31.552052] [80475a68] do_page_fault+0x228/0x970 [ 31.552146] [80473974] _spin_unlock+0x14/0x40 [ 31.552251] [802b2b5e] vfs_read+0x13e/0x180 [ 31.552340] [80473cc9] error_exit+0x0/0x51 [ 31.552436] The location of the warning is: hdrlen = ieee80211_get_hdrlen(rx.fc); line in question --WARN_ON_ONCE(((unsigned long)(skb-data + hdrlen)) 3); if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT) local-dot11ReceivedFragmentCount++; sta = rx.sta = sta_info_get(local, hdr-addr2); Now, the problem is that this might be nothing, and it might be the cause of the problem. (I don't think it is the cause, myself, because I've subjected my laptop to a lot of activity - to the point that the card was starting to drop packets - and have seen no problems) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote: > At Mon, 14 Jan 2008 16:03:22 -0500, > > Daniel Hazelton wrote: > > On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: > > > > > > > > Could this have anything to do with the following messages I've seen > > > > when trying -rc7 ? > > > > > > > > [7.760269] pnpacpi: exceeded the max number of mem resources: 12 > > > > > > Judging from Harald's report, it looks like a different problem. > > > The buggy patch (regarding HDA-intel) was, at least, already reverted > > > on Linus git tree. Could you give it a try? > > > > > > > > > Takashi > > > > Sorry, still no sound. Config, lspci and dmesg attached to help. System > > is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. > > Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? > > Anyway, try to change HZ=300. I got a report that HZ=1000 causes the > similar problem but HZ=300 not. > > > Takashi That did it. Looks like the hardware really is that sensitive to the timing. Strange, but I've seen worse. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Tuesday 15 January 2008 05:08:45 Takashi Iwai wrote: At Mon, 14 Jan 2008 16:03:22 -0500, Daniel Hazelton wrote: On Monday 14 January 2008 06:04:20 Takashi Iwai wrote: snip Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 Judging from Harald's report, it looks like a different problem. The buggy patch (regarding HDA-intel) was, at least, already reverted on Linus git tree. Could you give it a try? Takashi Sorry, still no sound. Config, lspci and dmesg attached to help. System is, as stated, Dell Inspiron 1420n running a 64bit kernel and userland. Hm, has the sound on ever 2.6.24-rc kernel worked with your machine? Anyway, try to change HZ=300. I got a report that HZ=1000 causes the similar problem but HZ=300 not. Takashi That did it. Looks like the hardware really is that sensitive to the timing. Strange, but I've seen worse. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: > Takashi Iwai wrote: > > At Thu, 10 Jan 2008 23:02:53 +0100, > > > > Harald Dunkel wrote: > >> Takashi Iwai wrote: > >>> Hm... Just to be sure, try the patch below. It's a clean up patch > >>> that I'd like to apply later. > >> > >> Sorry, no sound. > > > > OK, but I'd like to know whether this makes no regression to rc6. > > Could you check? > > > > Also, what exactly did you test? "No sound" means that no sound from > > the headphone / line-out or from the speaker? > > > > One interesting test would be to increase the value of udelay() in the > > reverted patch. What happens if it's set to 500? > > There is no udelay() in the reverted patch. If I replace "udelay(10)" > by "udelay(500)" in the original rc7, then there is still no sound. > > This is like fishing in the dark. We've got a working version. Why not > keep it? > > > Regards > > Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a "pop" from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp
Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep
On Saturday 12 January 2008 04:41:21 Harald Dunkel wrote: Takashi Iwai wrote: At Thu, 10 Jan 2008 23:02:53 +0100, Harald Dunkel wrote: Takashi Iwai wrote: Hm... Just to be sure, try the patch below. It's a clean up patch that I'd like to apply later. Sorry, no sound. OK, but I'd like to know whether this makes no regression to rc6. Could you check? Also, what exactly did you test? No sound means that no sound from the headphone / line-out or from the speaker? One interesting test would be to increase the value of udelay() in the reverted patch. What happens if it's set to 500? There is no udelay() in the reverted patch. If I replace udelay(10) by udelay(500) in the original rc7, then there is still no sound. This is like fishing in the dark. We've got a working version. Why not keep it? Regards Harri Could this have anything to do with the following messages I've seen when trying -rc7 ? [7.760269] pnpacpi: exceeded the max number of mem resources: 12 [7.760336] pnpacpi: exceeded the max number of mem resources: 12 [7.760401] pnpacpi: exceeded the max number of mem resources: 12 [7.760470] pnpacpi: exceeded the max number of mem resources: 12 [7.760536] pnpacpi: exceeded the max number of mem resources: 12 [7.760601] pnpacpi: exceeded the max number of mem resources: 12 [7.760666] pnpacpi: exceeded the max number of mem resources: 12 [7.760984] pnp: PnP ACPI: found 12 devices [7.761048] ACPI: ACPI bus type pnp unregistered [7.761345] PCI: Using ACPI for IRQ routing [7.761409] PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report And... [7.784472] system 00:05: ioport range 0xc80-0xcff could not be reserved [7.784546] system 00:08: iomem range 0xfed0-0xfed003ff has been reserved [7.784617] system 00:09: ioport range 0x900-0x97f has been reserved [7.784684] system 00:09: ioport range 0x4d0-0x4d1 has been reserved [7.784750] system 00:09: ioport range 0x1000-0x1005 has been reserved [7.784817] system 00:09: ioport range 0x1008-0x100f has been reserved [7.784887] system 00:0a: ioport range 0xf400-0xf4fe has been reserved [7.784954] system 00:0a: ioport range 0x1006-0x1007 has been reserved [7.785021] system 00:0a: ioport range 0x100a-0x1059 could not be reserved [7.785088] system 00:0a: ioport range 0x1060-0x107f has been reserved [7.785154] system 00:0a: ioport range 0x1080-0x10bf has been reserved [7.785221] system 00:0a: ioport range 0x10c0-0x10df has been reserved [7.785288] system 00:0a: ioport range 0x1010-0x102f has been reserved [7.785354] system 00:0a: ioport range 0x809-0x809 has been reserved [7.785425] system 00:0b: iomem range 0x0-0x9efff could not be reserved [7.785492] system 00:0b: iomem range 0x9f000-0x9 could not be reserved [7.785560] system 00:0b: iomem range 0xc-0xc has been reserved [7.785627] system 00:0b: iomem range 0xe-0xf has been reserved [7.785696] system 00:0b: iomem range 0x10-0x3f6923ff could not be reserved [7.785775] system 00:0b: iomem range 0x3f692400-0x3f6f could not be reserved [7.785854] system 00:0b: iomem range 0x3f70-0x3f7f could not be reserved [7.785932] system 00:0b: iomem range 0x3f70-0x3fef could not be reserved [7.786011] system 00:0b: iomem range 0xfff0-0x could not be reserved [7.786090] system 00:0b: iomem range 0xffa0-0xffaf has been reserved [7.786157] system 00:0b: iomem range 0xfec0-0xfec0 could not be reserved [7.786236] system 00:0b: iomem range 0xfee0-0xfee0 could not be reserved That's almost the entirety of the differences between a dmesg from a 2.6.24-rc7 boot and a 2.6.22 boot. System itself is a Dell Inspiron 1420n laptop running a 64bit kernel and userland - there is a pop from the speakers when booting, but no sound at all. I'll pull a new tree from GIT, but I'm thinking that the above changes are probably related to the move from ACPI motherboard drivers to the PNP platform driver. What I don't understand is how, if there are only more mem resources than the new PNP platform driver can handle, why there are also ioport ranges that could not be reserved. Additionally, with the same kernel, the iwlwifi driver appears to cause the new 802.11 code to crash. This doesn't stop the driver or cause any problems with the connection. I've been using the iwlwifi driver with 2.6.22 for a while and haven't seen anything like this. The message seen is: [ 30.504842] eth1: Initial auth_alg=0 [ 30.504848] eth1: authenticate with AP 00:11:50:fa:d4:ba [ 30.506630] eth1: RX authentication from 00:11:50:fa:d4:ba (alg=0 transaction =2 status=0) [ 30.506633] eth1: authenticated [ 30.506636] eth1: associate with AP 00:11:50:fa:d4:ba [ 30.509261] eth1: RX AssocResp from 00:11:50:fa:d4:ba (capab=0x411 status=0 a id=2) [
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 17:27:07 Dan Williams wrote:
> On Tue, 2007-10-23 at 15:41 -0400, Daniel Hazelton wrote:
> > On Tuesday 23 October 2007 14:54:54 Dan Williams wrote:
> > > On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote:
> > > > On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> > > > > On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > > > > > Hi!
> > > > > >
> > > > > > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > > > > > >
> > > > > > > > That doesn't say much, some manufacturers add that line to
> > > > > > > > their driver just to prevent the module loader complaining
> > > > > > > > about a non-GPL driver...
> > > > > > > >
> > > > > > > > There should be a copyright notice or a license file
> > > > > > > > accompanied with the driver that clearly states the license
> > > > > > > > of the driver.
> > > > > > >
> > > > > > > Lacking an explicitly stated license it can be argued that,
> > > > > > > since the MODULE_LICENSE() macro is meant to define the actual
> > > > > > > license on the code, this code is GPL. No, it isn't an explicit
> > > > > > > definition, but lacking any other signs of the license, the
> > > > > > > implicit declaration of it being GPL is (or should be) enough
> > > > > > > to deflect charges of copyright infringement.
> > > > > >
> > > > > > Yep, I believe this driver is GPLed. They published the source
> > > > > > and there's nothing to suggest otherwise, and there's explicit:
> > > > > >
> > > > > > #define DRIVER_AUTHOR "Jeff
> > > > > > Lee<[EMAIL PROTECTED]>" #define DRIVER_DESC
> > > > > >"IS89C35 802.11bg WLAN USB Driver" MODULE_LICENSE("GPL");
> > > > >
> > > > > If there isn't an explicit COPYING or LICENSE file or something
> > > > > distributed with the driver, and if there aren't copyright/license
> > > > > headers at the top of the files in question, I have a hard time
> > > > > agreeing that MODULE_LICENSE("GPL") _definitely_ means that the
> > > > > author has GPL-ed the driver intentionally. Of course that's the
> > > > > way it's supposed to work, but to me this doesn't pass sufficient
> > > > > muster to be definitely called GPL without additional
> > > > > clarification.
> > > > >
> > > > > Dan
> > > >
> > > > Lacking any other indication MODULE_LICENSE is supposed to mark the
> > > > license that the code is being distributed under. If companies are
> > > > intentionally
> > >
> > > Step 1: Ask the author.
> >
> > Agreed. This should have been done before this discussion even started.
> >
> > > Step 2: if the author doesn't reply, then we can have this discussion
> > >
> > > MODULE_LICENSE is just a random string that could have been added by
> > > anybody, not necessarily the author. Unless you can determine the
> > > intent of the author explicitly, a single MODULE_LICENSE is not
> > > sufficient to concretely determine the license of the code. It's only
> > > in one file. There is nothing to explicitly state the overall license
> > > of the whole work unless each file has a header referring to the
> > > license or unless there is a license document distributed with the code
> > > as a whole.
> > >
> > > In the absence of any other indication, MODULE_LICENSE doesn't not
> > > concretely determine the license of the code. You can assume it does,
> > > but that's your gun to put to your own head.
> >
> > The intent of MODULE_LICENSE is to mark the license on the code. This is
> > clearly stated in several places in Documentation/ (if my memory serves).
> >
> > > > mis-using this to get around the "internal interfaces" limitations
> > > > (where some interfaces are not available unless the module is GPL'd)
> > > > and the warning message printed in the logs when the module is not
> > > > GPL'd then they are (technically) in violation of the law.
> > > > (interfaces that are GPL only are con
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 14:54:54 Dan Williams wrote:
> On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote:
> > On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> > > On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > > > Hi!
> > > >
> > > > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > > > >
> > > > > > That doesn't say much, some manufacturers add that line to their
> > > > > > driver just to prevent the module loader complaining about a
> > > > > > non-GPL driver...
> > > > > >
> > > > > > There should be a copyright notice or a license file accompanied
> > > > > > with the driver that clearly states the license of the driver.
> > > > >
> > > > > Lacking an explicitly stated license it can be argued that, since
> > > > > the MODULE_LICENSE() macro is meant to define the actual license on
> > > > > the code, this code is GPL. No, it isn't an explicit definition,
> > > > > but lacking any other signs of the license, the implicit
> > > > > declaration of it being GPL is (or should be) enough to deflect
> > > > > charges of copyright infringement.
> > > >
> > > > Yep, I believe this driver is GPLed. They published the source and
> > > > there's nothing to suggest otherwise, and there's explicit:
> > > >
> > > > #define DRIVER_AUTHOR "Jeff
> > > > Lee<[EMAIL PROTECTED]>" #define DRIVER_DESC
> > > >"IS89C35 802.11bg WLAN USB Driver" MODULE_LICENSE("GPL");
> > >
> > > If there isn't an explicit COPYING or LICENSE file or something
> > > distributed with the driver, and if there aren't copyright/license
> > > headers at the top of the files in question, I have a hard time
> > > agreeing that MODULE_LICENSE("GPL") _definitely_ means that the author
> > > has GPL-ed the driver intentionally. Of course that's the way it's
> > > supposed to work, but to me this doesn't pass sufficient muster to be
> > > definitely called GPL without additional clarification.
> > >
> > > Dan
> >
> > Lacking any other indication MODULE_LICENSE is supposed to mark the
> > license that the code is being distributed under. If companies are
> > intentionally
>
> Step 1: Ask the author.
Agreed. This should have been done before this discussion even started.
> Step 2: if the author doesn't reply, then we can have this discussion
>
> MODULE_LICENSE is just a random string that could have been added by
> anybody, not necessarily the author. Unless you can determine the
> intent of the author explicitly, a single MODULE_LICENSE is not
> sufficient to concretely determine the license of the code. It's only
> in one file. There is nothing to explicitly state the overall license
> of the whole work unless each file has a header referring to the license
> or unless there is a license document distributed with the code as a
> whole.
>
> In the absence of any other indication, MODULE_LICENSE doesn't not
> concretely determine the license of the code. You can assume it does,
> but that's your gun to put to your own head.
The intent of MODULE_LICENSE is to mark the license on the code. This is
clearly stated in several places in Documentation/ (if my memory serves).
> > mis-using this to get around the "internal interfaces" limitations (where
> > some interfaces are not available unless the module is GPL'd) and the
> > warning message printed in the logs when the module is not GPL'd then
> > they are (technically) in violation of the law. (interfaces that are GPL
> > only are considered so internal to the kernel that using them makes your
> > code GPL because of the inclusion of GPL'd code. And no - I am not going
> > to get into that discussion - it's pointless)
>
> Just because the module may be loading illegally says _nothing_ about
> the license of the code.
No, but it is a mis-use of MODULE_LICENSE, which is supposed to state the
correct license on the code.
> > In the end, using MODULE_LICENSE for any purpose other than declaring the
> > chosen license for the code is deceptive. So it is easily arguable that
> > by
>
> "deceptive" is also not "this code code is definitely GPL". Doesn't
> matter whether it's deceptive or not. We do not know that the code is
> GPL.
Deception in order to create a situation whereby you can prosecute people for
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 10:05:12 Dan Williams wrote:
> On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
> > > >
> > > > That doesn't say much, some manufacturers add that line to their
> > > > driver just to prevent the module loader complaining about a non-GPL
> > > > driver...
> > > >
> > > > There should be a copyright notice or a license file accompanied with
> > > > the driver that clearly states the license of the driver.
> > >
> > > Lacking an explicitly stated license it can be argued that, since the
> > > MODULE_LICENSE() macro is meant to define the actual license on the
> > > code, this code is GPL. No, it isn't an explicit definition, but
> > > lacking any other signs of the license, the implicit declaration of it
> > > being GPL is (or should be) enough to deflect charges of copyright
> > > infringement.
> >
> > Yep, I believe this driver is GPLed. They published the source and
> > there's nothing to suggest otherwise, and there's explicit:
> >
> > #define DRIVER_AUTHOR "Jeff Lee<[EMAIL PROTECTED]>"
> > #define DRIVER_DESC "IS89C35 802.11bg WLAN
> > USB Driver" MODULE_LICENSE("GPL");
>
> If there isn't an explicit COPYING or LICENSE file or something
> distributed with the driver, and if there aren't copyright/license
> headers at the top of the files in question, I have a hard time agreeing
> that MODULE_LICENSE("GPL") _definitely_ means that the author has GPL-ed
> the driver intentionally. Of course that's the way it's supposed to
> work, but to me this doesn't pass sufficient muster to be definitely
> called GPL without additional clarification.
>
> Dan
Lacking any other indication MODULE_LICENSE is supposed to mark the license
that the code is being distributed under. If companies are intentionally
mis-using this to get around the "internal interfaces" limitations (where
some interfaces are not available unless the module is GPL'd) and the warning
message printed in the logs when the module is not GPL'd then they are
(technically) in violation of the law. (interfaces that are GPL only are
considered so internal to the kernel that using them makes your code GPL
because of the inclusion of GPL'd code. And no - I am not going to get into
that discussion - it's pointless)
In the end, using MODULE_LICENSE for any purpose other than declaring the
chosen license for the code is deceptive. So it is easily arguable that by
not including any license with the code other than the MODULE_LICENSE
statement and then trying to prosecute because MODULE_LICENSE doesn't
accurately state the license on the code is entrapment and illegal.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 10:05:12 Dan Williams wrote: On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote: Hi! Yes, I'm quite sure. There's MODULE_LICENCE(GPL), IIRC. That doesn't say much, some manufacturers add that line to their driver just to prevent the module loader complaining about a non-GPL driver... There should be a copyright notice or a license file accompanied with the driver that clearly states the license of the driver. Lacking an explicitly stated license it can be argued that, since the MODULE_LICENSE() macro is meant to define the actual license on the code, this code is GPL. No, it isn't an explicit definition, but lacking any other signs of the license, the implicit declaration of it being GPL is (or should be) enough to deflect charges of copyright infringement. Yep, I believe this driver is GPLed. They published the source and there's nothing to suggest otherwise, and there's explicit: #define DRIVER_AUTHOR Jeff Lee[EMAIL PROTECTED] #define DRIVER_DESC IS89C35 802.11bg WLAN USB Driver MODULE_LICENSE(GPL); If there isn't an explicit COPYING or LICENSE file or something distributed with the driver, and if there aren't copyright/license headers at the top of the files in question, I have a hard time agreeing that MODULE_LICENSE(GPL) _definitely_ means that the author has GPL-ed the driver intentionally. Of course that's the way it's supposed to work, but to me this doesn't pass sufficient muster to be definitely called GPL without additional clarification. Dan Lacking any other indication MODULE_LICENSE is supposed to mark the license that the code is being distributed under. If companies are intentionally mis-using this to get around the internal interfaces limitations (where some interfaces are not available unless the module is GPL'd) and the warning message printed in the logs when the module is not GPL'd then they are (technically) in violation of the law. (interfaces that are GPL only are considered so internal to the kernel that using them makes your code GPL because of the inclusion of GPL'd code. And no - I am not going to get into that discussion - it's pointless) In the end, using MODULE_LICENSE for any purpose other than declaring the chosen license for the code is deceptive. So it is easily arguable that by not including any license with the code other than the MODULE_LICENSE statement and then trying to prosecute because MODULE_LICENSE doesn't accurately state the license on the code is entrapment and illegal. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 14:54:54 Dan Williams wrote: On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote: On Tuesday 23 October 2007 10:05:12 Dan Williams wrote: On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote: Hi! Yes, I'm quite sure. There's MODULE_LICENCE(GPL), IIRC. That doesn't say much, some manufacturers add that line to their driver just to prevent the module loader complaining about a non-GPL driver... There should be a copyright notice or a license file accompanied with the driver that clearly states the license of the driver. Lacking an explicitly stated license it can be argued that, since the MODULE_LICENSE() macro is meant to define the actual license on the code, this code is GPL. No, it isn't an explicit definition, but lacking any other signs of the license, the implicit declaration of it being GPL is (or should be) enough to deflect charges of copyright infringement. Yep, I believe this driver is GPLed. They published the source and there's nothing to suggest otherwise, and there's explicit: #define DRIVER_AUTHOR Jeff Lee[EMAIL PROTECTED] #define DRIVER_DESC IS89C35 802.11bg WLAN USB Driver MODULE_LICENSE(GPL); If there isn't an explicit COPYING or LICENSE file or something distributed with the driver, and if there aren't copyright/license headers at the top of the files in question, I have a hard time agreeing that MODULE_LICENSE(GPL) _definitely_ means that the author has GPL-ed the driver intentionally. Of course that's the way it's supposed to work, but to me this doesn't pass sufficient muster to be definitely called GPL without additional clarification. Dan Lacking any other indication MODULE_LICENSE is supposed to mark the license that the code is being distributed under. If companies are intentionally Step 1: Ask the author. Agreed. This should have been done before this discussion even started. Step 2: if the author doesn't reply, then we can have this discussion MODULE_LICENSE is just a random string that could have been added by anybody, not necessarily the author. Unless you can determine the intent of the author explicitly, a single MODULE_LICENSE is not sufficient to concretely determine the license of the code. It's only in one file. There is nothing to explicitly state the overall license of the whole work unless each file has a header referring to the license or unless there is a license document distributed with the code as a whole. In the absence of any other indication, MODULE_LICENSE doesn't not concretely determine the license of the code. You can assume it does, but that's your gun to put to your own head. The intent of MODULE_LICENSE is to mark the license on the code. This is clearly stated in several places in Documentation/ (if my memory serves). mis-using this to get around the internal interfaces limitations (where some interfaces are not available unless the module is GPL'd) and the warning message printed in the logs when the module is not GPL'd then they are (technically) in violation of the law. (interfaces that are GPL only are considered so internal to the kernel that using them makes your code GPL because of the inclusion of GPL'd code. And no - I am not going to get into that discussion - it's pointless) Just because the module may be loading illegally says _nothing_ about the license of the code. No, but it is a mis-use of MODULE_LICENSE, which is supposed to state the correct license on the code. In the end, using MODULE_LICENSE for any purpose other than declaring the chosen license for the code is deceptive. So it is easily arguable that by deceptive is also not this code code is definitely GPL. Doesn't matter whether it's deceptive or not. We do not know that the code is GPL. Deception in order to create a situation whereby you can prosecute people for violation of the law is illegal. Therefore not distributing the code with any indication as to the license other than MODULE_LICENSE and attempting to prosecute afterwards is illegal. QED: even if the code is not GPL'd (and such could be learned by contacting the author), the fact that it ships without any indication of the license other than MODULE_LICENSE implies that the license is what is stated and prosecution on the grounds that it isn't becomes entrapment. not including any license with the code other than the MODULE_LICENSE statement and then trying to prosecute because MODULE_LICENSE doesn't accurately state the license on the code is entrapment and illegal. Arguable doesn't mean that it's concrete enough to pass legal muster. I am not a lawyer, but this just doesn't pass the bar. I know several and have asked one that is a very good friend. He agreed with my interpretation of the presented
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Tuesday 23 October 2007 17:27:07 Dan Williams wrote: On Tue, 2007-10-23 at 15:41 -0400, Daniel Hazelton wrote: On Tuesday 23 October 2007 14:54:54 Dan Williams wrote: On Tue, 2007-10-23 at 13:07 -0400, Daniel Hazelton wrote: On Tuesday 23 October 2007 10:05:12 Dan Williams wrote: On Tue, 2007-10-23 at 00:00 +0200, Pavel Machek wrote: Hi! Yes, I'm quite sure. There's MODULE_LICENCE(GPL), IIRC. That doesn't say much, some manufacturers add that line to their driver just to prevent the module loader complaining about a non-GPL driver... There should be a copyright notice or a license file accompanied with the driver that clearly states the license of the driver. Lacking an explicitly stated license it can be argued that, since the MODULE_LICENSE() macro is meant to define the actual license on the code, this code is GPL. No, it isn't an explicit definition, but lacking any other signs of the license, the implicit declaration of it being GPL is (or should be) enough to deflect charges of copyright infringement. Yep, I believe this driver is GPLed. They published the source and there's nothing to suggest otherwise, and there's explicit: #define DRIVER_AUTHOR Jeff Lee[EMAIL PROTECTED] #define DRIVER_DESC IS89C35 802.11bg WLAN USB Driver MODULE_LICENSE(GPL); If there isn't an explicit COPYING or LICENSE file or something distributed with the driver, and if there aren't copyright/license headers at the top of the files in question, I have a hard time agreeing that MODULE_LICENSE(GPL) _definitely_ means that the author has GPL-ed the driver intentionally. Of course that's the way it's supposed to work, but to me this doesn't pass sufficient muster to be definitely called GPL without additional clarification. Dan Lacking any other indication MODULE_LICENSE is supposed to mark the license that the code is being distributed under. If companies are intentionally Step 1: Ask the author. Agreed. This should have been done before this discussion even started. Step 2: if the author doesn't reply, then we can have this discussion MODULE_LICENSE is just a random string that could have been added by anybody, not necessarily the author. Unless you can determine the intent of the author explicitly, a single MODULE_LICENSE is not sufficient to concretely determine the license of the code. It's only in one file. There is nothing to explicitly state the overall license of the whole work unless each file has a header referring to the license or unless there is a license document distributed with the code as a whole. In the absence of any other indication, MODULE_LICENSE doesn't not concretely determine the license of the code. You can assume it does, but that's your gun to put to your own head. The intent of MODULE_LICENSE is to mark the license on the code. This is clearly stated in several places in Documentation/ (if my memory serves). mis-using this to get around the internal interfaces limitations (where some interfaces are not available unless the module is GPL'd) and the warning message printed in the logs when the module is not GPL'd then they are (technically) in violation of the law. (interfaces that are GPL only are considered so internal to the kernel that using them makes your code GPL because of the inclusion of GPL'd code. And no - I am not going to get into that discussion - it's pointless) Just because the module may be loading illegally says _nothing_ about the license of the code. No, but it is a mis-use of MODULE_LICENSE, which is supposed to state the correct license on the code. In the end, using MODULE_LICENSE for any purpose other than declaring the chosen license for the code is deceptive. So it is easily arguable that by deceptive is also not this code code is definitely GPL. Doesn't matter whether it's deceptive or not. We do not know that the code is GPL. Deception in order to create a situation whereby you can prosecute people for violation of the law is illegal. Therefore not distributing the code with any indication as to the license other than MODULE_LICENSE and attempting to prosecute afterwards is illegal. QED: even if the code is not GPL'd (and such could be learned by contacting the author), the fact that it ships without any indication of the license other than MODULE_LICENSE implies that the license is what is stated and prosecution on the grounds that it isn't becomes entrapment. not including any license with the code other than the MODULE_LICENSE statement and then trying to prosecute because MODULE_LICENSE doesn't accurately state
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Monday 22 October 2007 17:52:57 Ivo van Doorn wrote:
> On Monday 22 October 2007, Pavel Machek wrote:
> > Hi!
> >
> > > > > This device is NOT a Ralink USB wifi adapter!
> > > > >
> > > > > Get the windows driver in this link and see for yourself.
> > > > > http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB
> > > > > (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver))
> > > >
> > > > Thanks a lot. With some patches, I got driver from conitech.it to
> > > > compile and partly work on 2.6.23. I can now transmit packets but not
> > > > yet receive them.
> > > >
> > > > (use Makefile.26 instead of Makefile)
> > >
> > > I couldn't find any license info immediately visible; are you sure it's
> > > GPL?
> >
> > Yes, I'm quite sure. There's MODULE_LICENCE("GPL"), IIRC.
>
> That doesn't say much, some manufacturers add that line to their driver
> just to prevent the module loader complaining about a non-GPL driver...
>
> There should be a copyright notice or a license file accompanied with
> the driver that clearly states the license of the driver.
Lacking an explicitly stated license it can be argued that, since the
MODULE_LICENSE() macro is meant to define the actual license on the code,
this code is GPL. No, it isn't an explicit definition, but lacking any other
signs of the license, the implicit declaration of it being GPL is (or should
be) enough to deflect charges of copyright infringement.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rt73usb: support for wireless in Kohjinsha subnotebook
On Monday 22 October 2007 17:52:57 Ivo van Doorn wrote: On Monday 22 October 2007, Pavel Machek wrote: Hi! This device is NOT a Ralink USB wifi adapter! Get the windows driver in this link and see for yourself. http://www.conitech.it/conitech/ita/risorse.asp?cod=CN402USB (ISSC W89C35 802.11bg WLAN USB Adapters (Native Wifi driver)) Thanks a lot. With some patches, I got driver from conitech.it to compile and partly work on 2.6.23. I can now transmit packets but not yet receive them. (use Makefile.26 instead of Makefile) I couldn't find any license info immediately visible; are you sure it's GPL? Yes, I'm quite sure. There's MODULE_LICENCE(GPL), IIRC. That doesn't say much, some manufacturers add that line to their driver just to prevent the module loader complaining about a non-GPL driver... There should be a copyright notice or a license file accompanied with the driver that clearly states the license of the driver. Lacking an explicitly stated license it can be argued that, since the MODULE_LICENSE() macro is meant to define the actual license on the code, this code is GPL. No, it isn't an explicit definition, but lacking any other signs of the license, the implicit declaration of it being GPL is (or should be) enough to deflect charges of copyright infringement. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
On Monday 17 September 2007 02:43:50 Can E. Acar wrote:
> Daniel Hazelton wrote:
> > On Sunday 16 September 2007 23:00:09 Can E. Acar wrote:
>
> [snip]
>
> >> Theo summarized the latest situation here, some days ago:
> >>
> >> http://marc.info/?l=openbsd-misc=118963284332223=2
> >>
> >> and here is a very brief summary:
> >>
> >> http://marc.info/?l=openbsd-misc=118965266709012=2
BTW, I didn't say anything the last time, but the above mail is a load of
horse-shit. Theo is pointing fingers and making claims that anyone capable of
independent thought can see aren't related to reality.
Quoted in full (my comments are in the curly-braces):
I recognize that writeup about the Atheros / Linux / SFLC story is a
bit complex, so I wrote a very simple explanation to someone, and they
liked it's clarity so much that they asked me to post it for everyone.
Here it is (with a few more changes)
{Okay, this starts off good. Theo is going to make sure people understand what
is going on and what has happened. Perhaps he has realized things are
different from when he claimed that people were being advised to break the
law.}
-
starting premise:
you can already use the code as it is
steps taken:
1. pester developer for a year to get it under another license.
- get told no, repeatedly
{Alright - not a problem here. Happens all the time}
2. climb over ethical fence
{Off the deep end already, but lets keep going...}
3. remove his license
- get caught, look a bit stupid
{Caught? Well, yeah. Caught by the Linux Kernel developers before it became a
real problem. This has been fixed, although the code still hasn't been added
to the core Kernel tree - and the current iteration still hasn't been offered
for review}
4. wrap his license with your own
- get caught, look really stupid
{Not done, although this was, apparently, suggested by the SFLC. Nice FUD
there, Theo.}
5. assert copyright under author's license, without original work
- get caught, look even more stupid
{Not done. Again, nice FUD there}
Right now the wireless linux developers -- aided by an entire team of
evidently unskilled lawyers -- are at step 5, and we don't know what
will happen next. We wait, to see what will happen.
{Theo, embrace reality. It'll solve all kinds of problems. It's a simple fact
that reality has split from Theo's view of things between numbers 3 and 4.
What has happened is that the licenses have been maintained and the two
people that have been working on it for the Linux kernel has added their own
copyrights - covering the code they have added. If someone outside the Linux
Kernel development team has followed the above path then there is no reason
to doubt that they have created problems for themselves.}
Reyk can take them to court over this, but he must do it before the
year 2047.
{While there are ways to handle the situation that don't involve lawsuits I
don't think this is the best solution. I don't know what avenues that Reyk
and the OpenBSD community have already tried, but from what I've been told
all that's been done is a "private" message to the MadWifi people that they
are violating a copyright. The rest has been flames and FUD on the Linux
Kernel ML - which solves nothing and just creates problems. Maybe if the
OpenBSD community slammed the MadWifi mailing lists over this instead of the
Linux Kernel ML the problem there would go away...}
> >> If you really want to know the latest situation, please read these
> >> links, and think about it.
> >
> > No need. Here are the facts:
>
> It is now obvious that you have no interest in facts,
> You blindly repeat what you made yourself to believe.
I believe the truth. All the facts I have are derived from the mail exchanges
I've witnessed. If you disagree with the facts as I understand them say so -
don't just say that I'm "making myself believe them". If I've made a mistake
in judging the facts from available evidence then let me know - and provide a
reference that shows where I made the mistake. (ie: a public e-mai, etc...)
Anyway...
The facts I stated could be shown from the LKML archives, but I believed you'd
have seen the same posts I have - almost all the relevant posts were in
threads that were CC'd to at least one of the OpenBSD ML's.
I dissected the logic presented and pointed out how *ALL* the arguments that
have been presented so far have been either handled - either by being shown
to be false or in the most logical (and legal) manner possible. But instead
of the most expected answer - that is, attacks on the core Linux Kernel
developers - ie: those that discuss development and exchange patches on LKML
stopping - Theo continues to stir up the trouble by claiming that *ALL* Linux
Kernel developers are making a concentrated attempt to "steal" code.
Tha
Re: Wasting our Freedom
On Monday 17 September 2007 02:43:50 Can E. Acar wrote:
Daniel Hazelton wrote:
On Sunday 16 September 2007 23:00:09 Can E. Acar wrote:
[snip]
Theo summarized the latest situation here, some days ago:
http://marc.info/?l=openbsd-miscm=118963284332223w=2
and here is a very brief summary:
http://marc.info/?l=openbsd-miscm=118965266709012w=2
BTW, I didn't say anything the last time, but the above mail is a load of
horse-shit. Theo is pointing fingers and making claims that anyone capable of
independent thought can see aren't related to reality.
Quoted in full (my comments are in the curly-braces):
I recognize that writeup about the Atheros / Linux / SFLC story is a
bit complex, so I wrote a very simple explanation to someone, and they
liked it's clarity so much that they asked me to post it for everyone.
Here it is (with a few more changes)
{Okay, this starts off good. Theo is going to make sure people understand what
is going on and what has happened. Perhaps he has realized things are
different from when he claimed that people were being advised to break the
law.}
-
starting premise:
you can already use the code as it is
steps taken:
1. pester developer for a year to get it under another license.
- get told no, repeatedly
{Alright - not a problem here. Happens all the time}
2. climb over ethical fence
{Off the deep end already, but lets keep going...}
3. remove his license
- get caught, look a bit stupid
{Caught? Well, yeah. Caught by the Linux Kernel developers before it became a
real problem. This has been fixed, although the code still hasn't been added
to the core Kernel tree - and the current iteration still hasn't been offered
for review}
4. wrap his license with your own
- get caught, look really stupid
{Not done, although this was, apparently, suggested by the SFLC. Nice FUD
there, Theo.}
5. assert copyright under author's license, without original work
- get caught, look even more stupid
{Not done. Again, nice FUD there}
Right now the wireless linux developers -- aided by an entire team of
evidently unskilled lawyers -- are at step 5, and we don't know what
will happen next. We wait, to see what will happen.
{Theo, embrace reality. It'll solve all kinds of problems. It's a simple fact
that reality has split from Theo's view of things between numbers 3 and 4.
What has happened is that the licenses have been maintained and the two
people that have been working on it for the Linux kernel has added their own
copyrights - covering the code they have added. If someone outside the Linux
Kernel development team has followed the above path then there is no reason
to doubt that they have created problems for themselves.}
Reyk can take them to court over this, but he must do it before the
year 2047.
{While there are ways to handle the situation that don't involve lawsuits I
don't think this is the best solution. I don't know what avenues that Reyk
and the OpenBSD community have already tried, but from what I've been told
all that's been done is a private message to the MadWifi people that they
are violating a copyright. The rest has been flames and FUD on the Linux
Kernel ML - which solves nothing and just creates problems. Maybe if the
OpenBSD community slammed the MadWifi mailing lists over this instead of the
Linux Kernel ML the problem there would go away...}
If you really want to know the latest situation, please read these
links, and think about it.
No need. Here are the facts:
It is now obvious that you have no interest in facts,
You blindly repeat what you made yourself to believe.
I believe the truth. All the facts I have are derived from the mail exchanges
I've witnessed. If you disagree with the facts as I understand them say so -
don't just say that I'm making myself believe them. If I've made a mistake
in judging the facts from available evidence then let me know - and provide a
reference that shows where I made the mistake. (ie: a public e-mai, etc...)
Anyway...
The facts I stated could be shown from the LKML archives, but I believed you'd
have seen the same posts I have - almost all the relevant posts were in
threads that were CC'd to at least one of the OpenBSD ML's.
I dissected the logic presented and pointed out how *ALL* the arguments that
have been presented so far have been either handled - either by being shown
to be false or in the most logical (and legal) manner possible. But instead
of the most expected answer - that is, attacks on the core Linux Kernel
developers - ie: those that discuss development and exchange patches on LKML
stopping - Theo continues to stir up the trouble by claiming that *ALL* Linux
Kernel developers are making a concentrated attempt to steal code.
That is sheer and utter bullshit. I've finished a quick look through the
Atheros code in the git repo that Theo pointed out and don't see how
his Just an Adaptation argument works - there is more
Re: Wasting our Freedom
On Sunday 16 September 2007 23:00:09 Can E. Acar wrote: > Daniel Hazelton wrote: > > On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: > > [snip] > > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. > > > > IIRC, the advice was "Yes, it is legal to choose to follow only one of > > multiple offered licenses on a project" - nothing else. They looked at > > the patches and said "Wait, you've changed the license on files that > > aren't under a dual license." > > > > Hence, no problems here - no questionable advice only. > > The replies suggest that some (most?) people are not aware of the > recent developments, and that it is a dual licensing issue. Look at what I replied to and then thank me for replying to the text in question. Or is the fact that I was responding to - > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. - somehow beyond your comprehension? > This has very little to do with dual licensing right now, > there has been other developments, more "advice" from SLFC. And I have seen absolutely none of said "advice". > The code in question is Reyk's open source HAL work. > I want to emphasize. This work was NOT ever dual licensed. And that was only in question *PRIOR* to the review and rejection of the patches in question. Comprende ? > Furthermore, since it is compatible with the binary HAL from > Atheros, the interface is fixed and the same both in Linux and > *BSD. So, even the latst code divergence arguments do not > apply here. The improvements to this piece of code improve > the Open Source Atheros support, and is important for both > Linux and BSD. Doubtful. If I wrote a HAL implementation from scratch using Reyk's code as a reference only would that make my bottom-up rewrite a derivative? If you think it would, then you need to stop talking and start listening. Just because the code needs to provide a specific interface does not mean that any specific persons implementation is a derivative of another. This simple fact is key - because if that fact wasn't true then the original, purely binary HAL that was/is in FreeBSD would be illegal, as would Reyk's code. > Theo summarized the latest situation here, some days ago: > > http://marc.info/?l=openbsd-misc=118963284332223=2 > > and here is a very brief summary: > > http://marc.info/?l=openbsd-misc=118965266709012=2 > > If you really want to know the latest situation, please read these > links, and think about it. No need. Here are the facts: 1) People have come to the Linux Kernel ML and complained about a set of patches that were never accepted. 2) Theo has accused a Kernel developer of telling people to break the law. 3) People show up complaining again, apparently about the same patches. 4) One of them points out that the MadWifi developers have taken the broken patches 5) Several people on LKML say "So go be a troll there, leave us alone" 6) The original people, and more, start with claims that the Linux Kernel developers should "police" the "GNU/FSF/GPL Community" And now you come here saying that people don't understand the situation. Go look at the first two links in Theo's mails, which you linked to. Are they to kernel.org git repo's? Is either of them for the "linux-wireless-2.6" git repo? The answer to both is "No" - they are to MadWifi - a system which is developed separate from the Linux Kernel and not discussed here. The other two links are to a git repo that hasn't been included in the Linux Kernel, but probably will be, since it doesn't violate anyones copyright. Is Theo happy? No. Because the two people that ported to code to work in Linux have added themselves as holding copyrights to portions of the code. "Those files are still invalidly being distributed -- Nick and Jiri did not proveably do enough original work to earn copyright on a derivative work, since their work is just an adaptation." Now think about it - there are files that they have modified - in some cases this was apparently quite a bit of work. Yet they can't place their own copyrights on the code because Theo thinks it all is "Just an Adaptation" ? Think about this: Linux runs on numerous hardware platforms. For each platform there is a "port" - and "adaptation" of the code to make the kernel capable of running as fast and as stably on the new platform as the original supported one. Each one of those "ports" is an "adaptation" of existing code. By Theo's reckoning - judging from the statement I've quo
Re: Wasting our Freedom
On Sunday 16 September 2007 16:39:26 Hannah Schroeter wrote: > Hi! > > On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote: > >On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote: > >>... > >> First, these developers got questionable advice from senior Linux kernel > >> developers, and SLFC (which is closely related to FSF) in the process. > > > >The most questionable legal advice in this thread was by Theo de Raadt > >who claimed choosing one licence for _dual-licenced_ code was illegal... > > JFTR, I do *not* think that that assessment was questionable. Unless the > dual-licensing *explicitly* allows relicensing, relicensing is forbidden > by copyright law. The dual-licensing allows relicensing only if that's > *explicitly* stated, either in the statement offering the alternative, or > in one of the licenses. That advice wasn't regarding relicensing. Dual-licensed code allows distribution and use under either license. If I get BSD/GPL code, I can follow the GPL exclusively and I don't have to follow the BSD license at all. And the alternative is also true. (ie: follow the BSD license exclusively and ignore the GPL) It's not "relicensing" - it's following *WHICH* of the offered terms are more agreeable. I'll just snip the rest, since you seem confused. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: > On Sunday 16 September 2007 15:23:25 Daniel Hazelton wrote: > > On Sunday 16 September 2007 05:17:53 J.C. Roberts wrote: > >> On Sunday 16 September 2007, Jeff Garzik wrote: > >> > J.C. Roberts wrote: > >> > > http://marc.info/?l=linux-wireless=118857712529898=2 > >> > > >> > Link with outdated info. > >> > > >> > > http://madwifi.org/browser/branches/ath5k > >> > > >> > Link with outdated info. > >> > > >> > > I suggest actually taking the time to get the facts before making > >> > > completely baseless statements. When you make obviously erroneous > >> > > statements, it leaves everyone to believe you are either hopelessly > >> > > misinformed, or a habitual liar. -Which is it? > >> > > >> > Please take a moment to understand the Linux development process. > >> > > >> > A better place to look would be 'ath5k' branch of > >> > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g > >> >it > >> > > >> > but nonethless, the fact remains that ath5k is STILL NOT UPSTREAM and > >> > HAS NEVER BEEN UPSTREAM, as can be verified from > >> > > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > >> > (official linux repo; nothing is official until it hits here) > >> > > >> > Part of the reason why ath5k is not upstream is that developers are > >> > actively addressing these copyright concerns -- as can be clearly > >> > seen by the changes being made over time. > >> > > >> > So let's everybody calm down, ok? > >> > > >> > Regards, > >> > > >> > Jeff > >> > >> Jeff, > >> > >> Look at what you are saying from a different perspective. Let's say > >> someone took the linux kernel source from the official repository, > >> removed the GPL license and dedicated the work to public domain or put > >> it under any other license, and for kicks back-dated the files so they > >> are older than the originals. Then they took this illegal license > >> removal copy of your code and put it in a public repository somewhere. > >> > >> You'd be perfectly content with such a development because it had not > >> been officially brought "upstream" by the "offical" public domain or > >> whatever project? > > > > But that isn't the situation being discussed. You've sent this mail to > > the *LINUX* *KERNEL* ML, not the MadWifi ML. The patches in question were > > not accepted into the Linux Kernel, so this is *NOT* the place to send > > mail related to them. > > You are so cleanly isolating and cutting away of a group of developers. > I sincerely hope your fellow developers will not cut you off if you > make a similar mistake. I know mine wont. No, I'm saying "You are complaining about this in the wrong place and accusing the wrong people of the misdeed." > What you are saying is, a Copyright violation done by someone else is > Somebody Else's Problem (tm). There are a couple of issues with this point > of view: > > First, these developers got questionable advice from senior Linux kernel > developers, and SLFC (which is closely related to FSF) in the process. IIRC, the advice was "Yes, it is legal to choose to follow only one of multiple offered licenses on a project" - nothing else. They looked at the patches and said "Wait, you've changed the license on files that aren't under a dual license." Hence, no problems here - no questionable advice only. > > > *PLEASE* go do a Google search or check the MadWifi site for their > > discussion list/forum/whatever and complain there. > > This has been done. Really. They have been contacted privately > before the issue became public. Got no results. The issue is then made > public, > with the results you see now. This is no longer a MadWifi problem. Then file the lawsuit - if they have violated the license and ignored requests to fix the problem then there is sound legal grounds for it. > > > If the OpenBSD developers want to attack the Linux Kernel community over > > patches that were *NEVER* *ACCEPTED* by said community, it should be just > > as fair for the Linux Kernel community to complain about those > > (unspecified) times where OpenBSD replaced the GPL on code with the BSD > > license. > > It is fair. All license issues deserve utmos
Re: Wasting our Freedom
On Sunday 16 September 2007 05:17:53 J.C. Roberts wrote: > On Sunday 16 September 2007, Jeff Garzik wrote: > > J.C. Roberts wrote: > > > http://marc.info/?l=linux-wireless=118857712529898=2 > > > > Link with outdated info. > > > > > http://madwifi.org/browser/branches/ath5k > > > > Link with outdated info. > > > > > I suggest actually taking the time to get the facts before making > > > completely baseless statements. When you make obviously erroneous > > > statements, it leaves everyone to believe you are either hopelessly > > > misinformed, or a habitual liar. -Which is it? > > > > Please take a moment to understand the Linux development process. > > > > A better place to look would be 'ath5k' branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g > >it > > > > but nonethless, the fact remains that ath5k is STILL NOT UPSTREAM and > > HAS NEVER BEEN UPSTREAM, as can be verified from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > (official linux repo; nothing is official until it hits here) > > > > Part of the reason why ath5k is not upstream is that developers are > > actively addressing these copyright concerns -- as can be clearly > > seen by the changes being made over time. > > > > So let's everybody calm down, ok? > > > > Regards, > > > > Jeff > > Jeff, > > Look at what you are saying from a different perspective. Let's say > someone took the linux kernel source from the official repository, > removed the GPL license and dedicated the work to public domain or put > it under any other license, and for kicks back-dated the files so they > are older than the originals. Then they took this illegal license > removal copy of your code and put it in a public repository somewhere. > > You'd be perfectly content with such a development because it had not > been officially brought "upstream" by the "offical" public domain or > whatever project? But that isn't the situation being discussed. You've sent this mail to the *LINUX* *KERNEL* ML, not the MadWifi ML. The patches in question were not accepted into the Linux Kernel, so this is *NOT* the place to send mail related to them. *PLEASE* go do a Google search or check the MadWifi site for their discussion list/forum/whatever and complain there. > No, you would most likely be absolutely livid and extremely vocal > getting the problem fixed immediately, so your reasoning falls apart. Yes, true, but you are attacking people who haven't done anything wrong. And by your own words, Mr. Roberts, OpenBSD has violated peoples copyrights: "Most of us are also aware of the instance where OpenBSD took some GPL code and replaced the license with BSD. What OpenBSD did in that cases was just as illegal," If the OpenBSD developers want to attack the Linux Kernel community over patches that were *NEVER* *ACCEPTED* by said community, it should be just as fair for the Linux Kernel community to complain about those (unspecified) times where OpenBSD replaced the GPL on code with the BSD license. And, as said before, the place to take these complaints is the MadWifi discussion area, since they are, apparently, the only people that accepted the patches in question. > If the people who could fix the problem continued to ignore you, and the > people in leadership roles tell you then intend to steal your code, > then you would continue to get more angry and vocal about it. *WE*, the people on the Linux Kernel ML, *CANNOT* "fix the problem" with the *MADWIFI* code having accepted patches which violate Reyk's copyright. > Now take it one step further. For the sake of example, let's assume all > of this atheros driver nonsense went to a German court and the > GNU/FSF/SFLC/Linux or whoever you want to call yourselves lost a > criminal copyright infringement suit. You have now been legally proven > to be guilty code theft. > > After such a ruling let's assume some jerk was to do the all the > horrific stuff mentioned in the first paragraph above to the linux > source tree, along with a little regex magic to call it something other > than "linux" and seeded the Internet with countless copies. At this > point, the GNU, FSF, GPL and all of the hard working Linux devs are now > stuffed. A company could download the bogus source, violate the now > missing GPL license, claim you stole the code from someplace else on > the `net and illegally put your GPL license on it... Worst of all, they > now have your past conviction of criminal code theft to back up their > assertion about the way you normally operate. > > You should be concerned. The above is an immoral and illegal but still > practical attack on the GPL and all of hard work by many great people. > By having some people within the GNU/FSF/GPL camp indulging in code > theft to push their preferred license and the reasonable folks in the > GNU/FSF/GPL camp refusing to voice a strong opinion against code theft, > you are weakening your own license.
Re: Wasting our Freedom
On Sunday 16 September 2007 05:17:53 J.C. Roberts wrote: On Sunday 16 September 2007, Jeff Garzik wrote: J.C. Roberts wrote: http://marc.info/?l=linux-wirelessm=118857712529898w=2 Link with outdated info. http://madwifi.org/browser/branches/ath5k Link with outdated info. I suggest actually taking the time to get the facts before making completely baseless statements. When you make obviously erroneous statements, it leaves everyone to believe you are either hopelessly misinformed, or a habitual liar. -Which is it? Please take a moment to understand the Linux development process. A better place to look would be 'ath5k' branch of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g it but nonethless, the fact remains that ath5k is STILL NOT UPSTREAM and HAS NEVER BEEN UPSTREAM, as can be verified from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (official linux repo; nothing is official until it hits here) Part of the reason why ath5k is not upstream is that developers are actively addressing these copyright concerns -- as can be clearly seen by the changes being made over time. So let's everybody calm down, ok? Regards, Jeff Jeff, Look at what you are saying from a different perspective. Let's say someone took the linux kernel source from the official repository, removed the GPL license and dedicated the work to public domain or put it under any other license, and for kicks back-dated the files so they are older than the originals. Then they took this illegal license removal copy of your code and put it in a public repository somewhere. You'd be perfectly content with such a development because it had not been officially brought upstream by the offical public domain or whatever project? But that isn't the situation being discussed. You've sent this mail to the *LINUX* *KERNEL* ML, not the MadWifi ML. The patches in question were not accepted into the Linux Kernel, so this is *NOT* the place to send mail related to them. *PLEASE* go do a Google search or check the MadWifi site for their discussion list/forum/whatever and complain there. No, you would most likely be absolutely livid and extremely vocal getting the problem fixed immediately, so your reasoning falls apart. Yes, true, but you are attacking people who haven't done anything wrong. And by your own words, Mr. Roberts, OpenBSD has violated peoples copyrights: Most of us are also aware of the instance where OpenBSD took some GPL code and replaced the license with BSD. What OpenBSD did in that cases was just as illegal, If the OpenBSD developers want to attack the Linux Kernel community over patches that were *NEVER* *ACCEPTED* by said community, it should be just as fair for the Linux Kernel community to complain about those (unspecified) times where OpenBSD replaced the GPL on code with the BSD license. And, as said before, the place to take these complaints is the MadWifi discussion area, since they are, apparently, the only people that accepted the patches in question. If the people who could fix the problem continued to ignore you, and the people in leadership roles tell you then intend to steal your code, then you would continue to get more angry and vocal about it. *WE*, the people on the Linux Kernel ML, *CANNOT* fix the problem with the *MADWIFI* code having accepted patches which violate Reyk's copyright. Now take it one step further. For the sake of example, let's assume all of this atheros driver nonsense went to a German court and the GNU/FSF/SFLC/Linux or whoever you want to call yourselves lost a criminal copyright infringement suit. You have now been legally proven to be guilty code theft. After such a ruling let's assume some jerk was to do the all the horrific stuff mentioned in the first paragraph above to the linux source tree, along with a little regex magic to call it something other than linux and seeded the Internet with countless copies. At this point, the GNU, FSF, GPL and all of the hard working Linux devs are now stuffed. A company could download the bogus source, violate the now missing GPL license, claim you stole the code from someplace else on the `net and illegally put your GPL license on it... Worst of all, they now have your past conviction of criminal code theft to back up their assertion about the way you normally operate. You should be concerned. The above is an immoral and illegal but still practical attack on the GPL and all of hard work by many great people. By having some people within the GNU/FSF/GPL camp indulging in code theft to push their preferred license and the reasonable folks in the GNU/FSF/GPL camp refusing to voice a strong opinion against code theft, you are weakening your own license. Linux Kernel != FSF/GNU If it was then RMS would not be attacking Linus and Linux with faulty claims just because Linus has
Re: Wasting our Freedom
On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: On Sunday 16 September 2007 15:23:25 Daniel Hazelton wrote: On Sunday 16 September 2007 05:17:53 J.C. Roberts wrote: On Sunday 16 September 2007, Jeff Garzik wrote: J.C. Roberts wrote: http://marc.info/?l=linux-wirelessm=118857712529898w=2 Link with outdated info. http://madwifi.org/browser/branches/ath5k Link with outdated info. I suggest actually taking the time to get the facts before making completely baseless statements. When you make obviously erroneous statements, it leaves everyone to believe you are either hopelessly misinformed, or a habitual liar. -Which is it? Please take a moment to understand the Linux development process. A better place to look would be 'ath5k' branch of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.g it but nonethless, the fact remains that ath5k is STILL NOT UPSTREAM and HAS NEVER BEEN UPSTREAM, as can be verified from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (official linux repo; nothing is official until it hits here) Part of the reason why ath5k is not upstream is that developers are actively addressing these copyright concerns -- as can be clearly seen by the changes being made over time. So let's everybody calm down, ok? Regards, Jeff Jeff, Look at what you are saying from a different perspective. Let's say someone took the linux kernel source from the official repository, removed the GPL license and dedicated the work to public domain or put it under any other license, and for kicks back-dated the files so they are older than the originals. Then they took this illegal license removal copy of your code and put it in a public repository somewhere. You'd be perfectly content with such a development because it had not been officially brought upstream by the offical public domain or whatever project? But that isn't the situation being discussed. You've sent this mail to the *LINUX* *KERNEL* ML, not the MadWifi ML. The patches in question were not accepted into the Linux Kernel, so this is *NOT* the place to send mail related to them. You are so cleanly isolating and cutting away of a group of developers. I sincerely hope your fellow developers will not cut you off if you make a similar mistake. I know mine wont. No, I'm saying You are complaining about this in the wrong place and accusing the wrong people of the misdeed. What you are saying is, a Copyright violation done by someone else is Somebody Else's Problem (tm). There are a couple of issues with this point of view: First, these developers got questionable advice from senior Linux kernel developers, and SLFC (which is closely related to FSF) in the process. IIRC, the advice was Yes, it is legal to choose to follow only one of multiple offered licenses on a project - nothing else. They looked at the patches and said Wait, you've changed the license on files that aren't under a dual license. Hence, no problems here - no questionable advice only. snip *PLEASE* go do a Google search or check the MadWifi site for their discussion list/forum/whatever and complain there. This has been done. Really. They have been contacted privately before the issue became public. Got no results. The issue is then made public, with the results you see now. This is no longer a MadWifi problem. Then file the lawsuit - if they have violated the license and ignored requests to fix the problem then there is sound legal grounds for it. snip If the OpenBSD developers want to attack the Linux Kernel community over patches that were *NEVER* *ACCEPTED* by said community, it should be just as fair for the Linux Kernel community to complain about those (unspecified) times where OpenBSD replaced the GPL on code with the BSD license. It is fair. All license issues deserve utmost attention and respect by all communities. If we let such issues to go unresolved, we face a much greater danger to our work. Yes, but in this case you are complaining to people that have no control over the code in question. It's known that the patches are bad, and if people continue to use them, then it is their problem and the problem of the copyright holder. snip Is it too naive to hope that some leader/senior developer from the Linux/FSF/GNU whatever will take the clue stick and let the developers know what is happening is wrong. Being leaders in a community do have some responsibilities you know. And it has happened - the Linux Kernel community has commented on the situation a *LOT* - to the extent that the patches in question were rejected - long *BEFORE* Theo commented on it. And, as said before, the place to take these complaints is the MadWifi discussion area, since they are, apparently, the only people that accepted the patches in question
Re: Wasting our Freedom
On Sunday 16 September 2007 16:39:26 Hannah Schroeter wrote: Hi! On Sun, Sep 16, 2007 at 09:59:09PM +0200, Adrian Bunk wrote: On Sun, Sep 16, 2007 at 11:48:47AM -0700, Can E. Acar wrote: ... First, these developers got questionable advice from senior Linux kernel developers, and SLFC (which is closely related to FSF) in the process. The most questionable legal advice in this thread was by Theo de Raadt who claimed choosing one licence for _dual-licenced_ code was illegal... JFTR, I do *not* think that that assessment was questionable. Unless the dual-licensing *explicitly* allows relicensing, relicensing is forbidden by copyright law. The dual-licensing allows relicensing only if that's *explicitly* stated, either in the statement offering the alternative, or in one of the licenses. That advice wasn't regarding relicensing. Dual-licensed code allows distribution and use under either license. If I get BSD/GPL code, I can follow the GPL exclusively and I don't have to follow the BSD license at all. And the alternative is also true. (ie: follow the BSD license exclusively and ignore the GPL) It's not relicensing - it's following *WHICH* of the offered terms are more agreeable. I'll just snip the rest, since you seem confused. snip DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wasting our Freedom
On Sunday 16 September 2007 23:00:09 Can E. Acar wrote: Daniel Hazelton wrote: On Sunday 16 September 2007 14:48:47 Can E. Acar wrote: [snip] First, these developers got questionable advice from senior Linux kernel developers, and SLFC (which is closely related to FSF) in the process. IIRC, the advice was Yes, it is legal to choose to follow only one of multiple offered licenses on a project - nothing else. They looked at the patches and said Wait, you've changed the license on files that aren't under a dual license. Hence, no problems here - no questionable advice only. The replies suggest that some (most?) people are not aware of the recent developments, and that it is a dual licensing issue. Look at what I replied to and then thank me for replying to the text in question. Or is the fact that I was responding to - First, these developers got questionable advice from senior Linux kernel developers, and SLFC (which is closely related to FSF) in the process. - somehow beyond your comprehension? This has very little to do with dual licensing right now, there has been other developments, more advice from SLFC. And I have seen absolutely none of said advice. The code in question is Reyk's open source HAL work. I want to emphasize. This work was NOT ever dual licensed. And that was only in question *PRIOR* to the review and rejection of the patches in question. Comprende ? Furthermore, since it is compatible with the binary HAL from Atheros, the interface is fixed and the same both in Linux and *BSD. So, even the latst code divergence arguments do not apply here. The improvements to this piece of code improve the Open Source Atheros support, and is important for both Linux and BSD. Doubtful. If I wrote a HAL implementation from scratch using Reyk's code as a reference only would that make my bottom-up rewrite a derivative? If you think it would, then you need to stop talking and start listening. Just because the code needs to provide a specific interface does not mean that any specific persons implementation is a derivative of another. This simple fact is key - because if that fact wasn't true then the original, purely binary HAL that was/is in FreeBSD would be illegal, as would Reyk's code. Theo summarized the latest situation here, some days ago: http://marc.info/?l=openbsd-miscm=118963284332223w=2 and here is a very brief summary: http://marc.info/?l=openbsd-miscm=118965266709012w=2 If you really want to know the latest situation, please read these links, and think about it. No need. Here are the facts: 1) People have come to the Linux Kernel ML and complained about a set of patches that were never accepted. 2) Theo has accused a Kernel developer of telling people to break the law. 3) People show up complaining again, apparently about the same patches. 4) One of them points out that the MadWifi developers have taken the broken patches 5) Several people on LKML say So go be a troll there, leave us alone 6) The original people, and more, start with claims that the Linux Kernel developers should police the GNU/FSF/GPL Community And now you come here saying that people don't understand the situation. Go look at the first two links in Theo's mails, which you linked to. Are they to kernel.org git repo's? Is either of them for the linux-wireless-2.6 git repo? The answer to both is No - they are to MadWifi - a system which is developed separate from the Linux Kernel and not discussed here. The other two links are to a git repo that hasn't been included in the Linux Kernel, but probably will be, since it doesn't violate anyones copyright. Is Theo happy? No. Because the two people that ported to code to work in Linux have added themselves as holding copyrights to portions of the code. Those files are still invalidly being distributed -- Nick and Jiri did not proveably do enough original work to earn copyright on a derivative work, since their work is just an adaptation. Now think about it - there are files that they have modified - in some cases this was apparently quite a bit of work. Yet they can't place their own copyrights on the code because Theo thinks it all is Just an Adaptation ? Think about this: Linux runs on numerous hardware platforms. For each platform there is a port - and adaptation of the code to make the kernel capable of running as fast and as stably on the new platform as the original supported one. Each one of those ports is an adaptation of existing code. By Theo's reckoning - judging from the statement I've quoted - none of them are worthy of a copyright, because they are Just an adaptation. For instance, compare src/sys/dev/ic/ar5xxx.h to ath5k.h (they appear to be the same file) - there was a *LOT* of work done in this file. I truthfully can't tell how much of the original remains and how much has been rewritten or split out. But from the amount of work I can see in just *ONE* of the files
Re: Fwd: That whole "Linux stealing our code" thing
On Tuesday 04 September 2007 15:44:31 Michael Poole wrote: > Chris Friesen writes: > > Daniel Hazelton wrote: > >> On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: > >>>Daniel Hazelton <[EMAIL PROTECTED]> writes: > >>>>US Copyright law. A copyright holder, regardless of what license he/she > >>>>may have released the work under, can still revoke the license for a > >>>>specific person or group of people. (There are some exceptions, but > >>>> they do not apply to the situation that is being discussed) > > > > The OpenBSD policy page doesn't agree with you: > > > > "...That means that having granted a permission, the copyright holder > > can not retroactively say that an individual or class of individuals > > are no longer granted those permissions. Likewise should the copyright > > holder decide to "go commercial" he can not revoke permissions already > > granted for the use of the work as distributed, though he may impose > > more restrictive permissions in his future distributions of that work." > > > > http://www.openbsd.org/policy.html > > By my reading, this is supported by 17 USC 203(a)(3): > > (3) Termination of the grant may be effected at any time during a > period of five years beginning at the end of thirty-five years > from the date of execution of the grant; or, if the grant covers > the right of publication of the work, the period begins at the > end of thirty-five years from the date of publication of the > work under the grant or at the end of forty years from the date > of execution of the grant, whichever term ends earlier. > > (from > http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000- >.html ) Ah, I am both right and wrong, it seems. Apparently you have to wait anywhere form 35 to 40 years, and then you only have a five year window. Seems damned strange to me, but oh well. (I'd totally forgotten that part of the law - or my mind decided to play tricks on me.) DRH PS: See, I will admit it when I'm shown evidence that I'm wrong :) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Tuesday 04 September 2007 11:10:52 [EMAIL PROTECTED] wrote: > On Mon, 03 Sep 2007 17:23:37 PDT, David Schwartz said: > > > Wrong - I said "You can't complain about Person A doing X when > > > you let Person > > > B do X without complaint". > > > > Yes, I can. There is no inconsistency between acting in one case and > > failing to act in another. We need not act in every possible case where > > we could act to preserve our right to act in a particular case. > > You *do* however need to be aware that in some cases, public inactivity > and/or statements that something will not be acted on may estoppel any > future attempts to enforce something. Exactly. However, inactivity can be construed as lack of knowledge that something is occurring. (ie: the RIAA didn't start acting on file-sharing until they became aware of Napster) But for said estoppel to not be a factor you will have to prosecute and/or file suit on all instances of the activity. (And filing a suit and then dropping it against some of the people that you filed suit against - ie: you file suit against persons A and B and then drop the suit against person A in its entirety - because you only wanted to prosecute person B for the action, you are leaving yourself open to lawsuits on a number of counts.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > US Copyright law. A copyright holder, regardless of what license he/she > > may have released the work under, can still revoke the license for a > > specific person or group of people. (There are some exceptions, but they > > do not apply to the situation that is being discussed) > > Oh come on, I thought some small country in maybe central Africa, > but certainly not USA. US Law is a twisted maze - you wouldn't believe the contradictions that exist between different sections of the US Federal Code. (And its worse as you move down to the State and the Local levels) > What you write would essentially mean GPL (and any other such licence) > is invalid in the USA. Nope. The GPL is an explicit grant of rights and is fully legal and active as it stands. > The licence is basically a promise not to sue. It wouldn't make any > sense to promise if you could revoke at will. If I was to revoke the license on something I held copyright to, I'd be forced to make an attempt to contact everyone that may have received a copy of the work under that license before I could ever begin filing lawsuits. This process will take at least a month - more if the various localities where someone might be living has laws about what constitutes an attempt to contact. (For instance, here in Pennsylvania an attempt to contact is taking out large format classified ad's in every newspaper in the area where the person is known to reside - or statewide if the region is not known. The ad's have to run for a minimum of one week) This means that it'd take no less than five weeks - and might take as much as six months - before I could begin filing lawsuits. (And even then I'd have to have proof that the person in question was violating my copyright at the time the lawsuit was filed) > > Ah, see - in the US the license(s) in question (and licenses in general) > > are grants of rights, not a "statements of will". > > Right here grants of rights are some sort of statements of will. Difference in terminology ? A "Grant of Rights" is where you say 'Normally only I could do this, but I am giving you the legal right to do it as well'. A "statement of will" is 'This is what I want to have happen, in perpetuity'. In the US, a "statement of will" can include or imply a "Grant of Rights" and vice-versa, but they are separate entities. > > (Truthfully, in the US a license > > should be read with an implicit "All rights reserved") > > Actually (and I think it's the same in the USA), a copyrighted work > has an implicit "all rights reserved". A licence is just exception. And? The fact remains that "All Rights Reserved" means "I am reserving all rights I do not specifically grant or waive". ie: If a license doesn't state 'The licenser hereby waives the right to revoke this license at any time' then that right hasn't been lost. (A license acquired through a purchase - as might apply to a novel - is a lot different. And contracts are a different beast entirely) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
On Tuesday 04 September 2007 04:50:34 James Bruce wrote: > Daniel Hazelton wrote: > > On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: > >> Daniel Hazelton <[EMAIL PROTECTED]> writes: > >>> The fact > >>> remains that the person making a work available under *ANY* form of > >>> copyright > >>> license has the right to revoke said grant of license to anyone. > >> > >> Not after the licence has been given and accepted (and there might be > >> restrictions), unless of course the licence contained such reservation. > > > > I hate to belabor the point, but you seem to be making the mistake of > > "The license applies to the copyright holder" that I've seen a lot of > > people make (and kept quiet about). > > I believe you are making the mistake that the license on code has > anything to do with what the author chooses to do in the future. > Releasing something as BSD does not force the author to do anything in > the future with his code, and he/she could add and relicence as he/she > feels fit. HOWEVER, that particular code has already been released as > BSD, and the author no longer has control over that release. I may be mistaken, but it has always been my understanding that, unless you specifically waive your rights, they are automatically retained. (Under the law in the US, at least). Hence, a copyright holder can do such, where the license has not been acquired by money changing hands. (And actually, my above statement isn't rendered false by your rebuttal - it still appears that the person I replied to believes that a copyright license applies to the person holding the copyright in the same manner it applies to the person receiving the item under said license. Though I will admit it if I am wrong - publicly) > > The person holding the copyright has all the legal standing to revoke a > > license grant at any time. Licenses such as the GPL are not signed > > contracts, and that means there are limits to what effect they can have > > on the copyright holder. > > I believe you are confusing the fact that an author can decide to > release code under another license, with the existence of code under > that earlier license. The license grant comes from THE CODE (which > bears a license), not THE AUTHOR. I can use GPL code I get in the mail > because the license on the work says I can do so, not because I > contacted the author and got a specific grant. If such a grant were > only verbal, your theory might hold, but that doesn't apply to any OSS > software under discussion here. The license is a direct grant from the author. If the author so wished, he/she could pull the license - either entirely or in part. About the only caveat is that the author would have to publish and attempt to contact everyone who may have acquired the item under that license to inform them of such a change - this does make it difficult, hell, makes it nearly impossible, but it can be done. (IANAL, but this does appear to be what the law says) > If your legal theory were true, I could sell you a book and then later > demand that you destroy it. I could also release something as public > domain, and then later rescind that (I still hold the copyright on what > I produced), and charge money from anyone who used it. I think its safe > to say that this does not happen in practice. Please provide some > examples to the contrary or caselaw if you want to convince me otherwise. Actually, no. A purchase does automatically grant the rights inherent in ownership - but that is a *PURCHASE*. Mere transfer of an item with no exchange of money cannot convey those rights. As far as the 'public domain' argument goes... That smells of a straw-man and is as different from a grant of license as it is from a purchase. When you release something into the public domain you are waiving *ALL* of your rights as copyright holder. (Which, I am told, cannot be done in Germany and some other countries) > Furthermore, BSD/GPL software could not really exist under your legal > theory; A programmer who wrote 30 year old core BSD code could wake up > tomorrow and decide to require all BSD derivatives to remove his code or > pay him for it (and the next day he could change the price again). Open > source software would not exist if such a liability were true, and > companies like Sun could not be built up off of derivatives of it. > Linux 0.01 is still available under a pre-GPL license if you can find a > copy, and neither Linus (nor anyone else) can change that. He could, but AFAICT, thirty years ago BSD was still run entirely by UC Berkely and any copyrights that might be held are held entirely by UC Berkely and not the individuals that contributed to such. (Whats more, a 3
Re: Fwd: That whole Linux stealing our code thing
On Tuesday 04 September 2007 04:50:34 James Bruce wrote: Daniel Hazelton wrote: On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. Not after the licence has been given and accepted (and there might be restrictions), unless of course the licence contained such reservation. I hate to belabor the point, but you seem to be making the mistake of The license applies to the copyright holder that I've seen a lot of people make (and kept quiet about). I believe you are making the mistake that the license on code has anything to do with what the author chooses to do in the future. Releasing something as BSD does not force the author to do anything in the future with his code, and he/she could add and relicence as he/she feels fit. HOWEVER, that particular code has already been released as BSD, and the author no longer has control over that release. I may be mistaken, but it has always been my understanding that, unless you specifically waive your rights, they are automatically retained. (Under the law in the US, at least). Hence, a copyright holder can do such, where the license has not been acquired by money changing hands. (And actually, my above statement isn't rendered false by your rebuttal - it still appears that the person I replied to believes that a copyright license applies to the person holding the copyright in the same manner it applies to the person receiving the item under said license. Though I will admit it if I am wrong - publicly) The person holding the copyright has all the legal standing to revoke a license grant at any time. Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. I believe you are confusing the fact that an author can decide to release code under another license, with the existence of code under that earlier license. The license grant comes from THE CODE (which bears a license), not THE AUTHOR. I can use GPL code I get in the mail because the license on the work says I can do so, not because I contacted the author and got a specific grant. If such a grant were only verbal, your theory might hold, but that doesn't apply to any OSS software under discussion here. The license is a direct grant from the author. If the author so wished, he/she could pull the license - either entirely or in part. About the only caveat is that the author would have to publish and attempt to contact everyone who may have acquired the item under that license to inform them of such a change - this does make it difficult, hell, makes it nearly impossible, but it can be done. (IANAL, but this does appear to be what the law says) If your legal theory were true, I could sell you a book and then later demand that you destroy it. I could also release something as public domain, and then later rescind that (I still hold the copyright on what I produced), and charge money from anyone who used it. I think its safe to say that this does not happen in practice. Please provide some examples to the contrary or caselaw if you want to convince me otherwise. Actually, no. A purchase does automatically grant the rights inherent in ownership - but that is a *PURCHASE*. Mere transfer of an item with no exchange of money cannot convey those rights. As far as the 'public domain' argument goes... That smells of a straw-man and is as different from a grant of license as it is from a purchase. When you release something into the public domain you are waiving *ALL* of your rights as copyright holder. (Which, I am told, cannot be done in Germany and some other countries) Furthermore, BSD/GPL software could not really exist under your legal theory; A programmer who wrote 30 year old core BSD code could wake up tomorrow and decide to require all BSD derivatives to remove his code or pay him for it (and the next day he could change the price again). Open source software would not exist if such a liability were true, and companies like Sun could not be built up off of derivatives of it. Linux 0.01 is still available under a pre-GPL license if you can find a copy, and neither Linus (nor anyone else) can change that. He could, but AFAICT, thirty years ago BSD was still run entirely by UC Berkely and any copyrights that might be held are held entirely by UC Berkely and not the individuals that contributed to such. (Whats more, a 30 year old version of BSD doesn't meet the requirements of the ATT agreement, so its only legal in-so-far as it massively predates that agreement (and the lawsuit which spawned it) :) And yes, Linus actually could revoke the license on any copy of Linux from before he started merging code written by other people into the code
Re: Fwd: That whole Linux stealing our code thing
On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) Oh come on, I thought some small country in maybe central Africa, but certainly not USA. US Law is a twisted maze - you wouldn't believe the contradictions that exist between different sections of the US Federal Code. (And its worse as you move down to the State and the Local levels) What you write would essentially mean GPL (and any other such licence) is invalid in the USA. Nope. The GPL is an explicit grant of rights and is fully legal and active as it stands. The licence is basically a promise not to sue. It wouldn't make any sense to promise if you could revoke at will. If I was to revoke the license on something I held copyright to, I'd be forced to make an attempt to contact everyone that may have received a copy of the work under that license before I could ever begin filing lawsuits. This process will take at least a month - more if the various localities where someone might be living has laws about what constitutes an attempt to contact. (For instance, here in Pennsylvania an attempt to contact is taking out large format classified ad's in every newspaper in the area where the person is known to reside - or statewide if the region is not known. The ad's have to run for a minimum of one week) This means that it'd take no less than five weeks - and might take as much as six months - before I could begin filing lawsuits. (And even then I'd have to have proof that the person in question was violating my copyright at the time the lawsuit was filed) Ah, see - in the US the license(s) in question (and licenses in general) are grants of rights, not a statements of will. Right here grants of rights are some sort of statements of will. Difference in terminology ? A Grant of Rights is where you say 'Normally only I could do this, but I am giving you the legal right to do it as well'. A statement of will is 'This is what I want to have happen, in perpetuity'. In the US, a statement of will can include or imply a Grant of Rights and vice-versa, but they are separate entities. (Truthfully, in the US a license should be read with an implicit All rights reserved) Actually (and I think it's the same in the USA), a copyrighted work has an implicit all rights reserved. A licence is just exception. And? The fact remains that All Rights Reserved means I am reserving all rights I do not specifically grant or waive. ie: If a license doesn't state 'The licenser hereby waives the right to revoke this license at any time' then that right hasn't been lost. (A license acquired through a purchase - as might apply to a novel - is a lot different. And contracts are a different beast entirely) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Tuesday 04 September 2007 11:10:52 [EMAIL PROTECTED] wrote: On Mon, 03 Sep 2007 17:23:37 PDT, David Schwartz said: Wrong - I said You can't complain about Person A doing X when you let Person B do X without complaint. Yes, I can. There is no inconsistency between acting in one case and failing to act in another. We need not act in every possible case where we could act to preserve our right to act in a particular case. You *do* however need to be aware that in some cases, public inactivity and/or statements that something will not be acted on may estoppel any future attempts to enforce something. Exactly. However, inactivity can be construed as lack of knowledge that something is occurring. (ie: the RIAA didn't start acting on file-sharing until they became aware of Napster) But for said estoppel to not be a factor you will have to prosecute and/or file suit on all instances of the activity. (And filing a suit and then dropping it against some of the people that you filed suit against - ie: you file suit against persons A and B and then drop the suit against person A in its entirety - because you only wanted to prosecute person B for the action, you are leaving yourself open to lawsuits on a number of counts.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole Linux stealing our code thing
On Tuesday 04 September 2007 15:44:31 Michael Poole wrote: Chris Friesen writes: Daniel Hazelton wrote: On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) The OpenBSD policy page doesn't agree with you: ...That means that having granted a permission, the copyright holder can not retroactively say that an individual or class of individuals are no longer granted those permissions. Likewise should the copyright holder decide to go commercial he can not revoke permissions already granted for the use of the work as distributed, though he may impose more restrictive permissions in his future distributions of that work. http://www.openbsd.org/policy.html By my reading, this is supported by 17 USC 203(a)(3): (3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier. (from http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000- .html ) Ah, I am both right and wrong, it seems. Apparently you have to wait anywhere form 35 to 40 years, and then you only have a five year window. Seems damned strange to me, but oh well. (I'd totally forgotten that part of the law - or my mind decided to play tricks on me.) DRH PS: See, I will admit it when I'm shown evidence that I'm wrong :) -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 20:23:37 David Schwartz wrote: > > Wrong - I said "You can't complain about Person A doing X when > > you let Person > > B do X without complaint". > > Yes, I can. There is no inconsistency between acting in one case and > failing to act in another. We need not act in every possible case where we > could act to preserve our right to act in a particular case. Sorry, I should have said that you cannot prosecute one person for doing something without prosecuting everyone that is doing it. Otherwise you have lost the case before it has started - no judge would allow such a one sided application of the law. > > To whit: you can't complain that Jiri has made > > changes to a dual-licensed "work" and only released his changes > > under one of > > the licenses on the work when somebody else - in this case Msr. > > Floeter - has > > done the same thing. > > First of all, I haven't complained about Jiri's changes. Second, I most > certainly can. I can complain about one murder without complaining about > every murder. There is no inconsistency whatsoever with acting in one case > without having to act in every other conceivable case. Sorry, this ties back to the original statement and the implied threats of legal action by Theo and backed up by almost every OpenBSD developer that has participated in this discussion. It's a mis-statement of mine - see above. If you are going to prosecute one person for doing something, you have to prosecute everyone who does it. > We can complain about or work to fight whatever injustices we like. There > is no obligation to address every equal, or greater, injustice before > working on the injustice of one's choice. Yes, of course. > > No, no confusion. You could care less about the code being dual-licensed. > > Your > > > choice of subjects 'GPL weasels' speaks volumes. > > *My* choice of subjects?! You seem to have me confused with someone else > entirely. Potentially - I am terrible with names and had assumed that you were the person who had forked the "Stealing Our Code" thread with the "GPL weasels" subject. If my assumption is faulty, then I apologize and ask your forgiveness for my false accusation. > My sole points in this thread were to: > > 1) Correct some misunderstandings about how dual licenses actually work. This was, IIRC, already well understood by most of the people on the Linux Kernel side of things. (Alan Cox has given several quite lucid statements showing that he, at least, does understand this) > 2) Explain *why* a file cannot really remain dual-licensed if it's part of > the Linux kernel distribution. A file/files can have as many licenses on it as the developer wants, provided that at least one of them is the GPL(v2). That is because, for it to be legally distributed as part of the Linux Kernel it has to be done so under the auspices of the license on the Linux Kernel - the GPLv2. > While I generally prefer the BSD license to the GPL license and tend to be > a pretty vocal GPL critic, I have said many times that almost any > *consistent* license is better for a large project than different licenses, > even if they're compatible, on different files. I am critical of the GPL myself, as is Linus and a lot of people. (Linus himself has said, numerous times, that he is "no fan of the GPL, but it is the best that exists" (his words and opinion) - and I have heard similar sentiments from a lot of people.) I am not a fan of the BSD license because I'd like to be able to incorporate any changes someone might make back into the original code. There is no requirement in the BSD license for someone to make their changes to my code available to me - so I am not a fan of it. > > Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The > > fact remains that the person making a work available under *ANY* form of > > copyright > > > license has the right to revoke said grant of license to anyone. The GPL > > codifies certain situations in which the person would not, personally, > > have > > > to revoke the license, but does not limit the original copyright holders > > rights (in that regard) in any way. > > I'm not sure where you're getting this from, but it's not true. Linus > cannot decide tomorrow that nobody can distribute the Linux kernel anymore. In the US you have to explicitly waive rights for you to not have them (in regards to licenses). Although, considering what I have been informed of in regards to the law in Poland (and, seeing as how this has surprised a lot of people, likely a large number of other countries), to make sure those rights are "reserved" they should be explicitly spelled out in the text of the license. And the truth is that Linus could do that - if he required contributors to do a copyright assignment (which would make him the holder of the sole copyright on the Linux Kernel). Since Linus is *NOT* the sole copyright holder on Linux, he cannot do this. He
Re: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 15:33:01 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > I hate to belabor the point, but you seem to be making the mistake of > > "The license applies to the copyright holder" > > Of course not. I'll take this at face value - I might have mis-parsed your earlier statements wrong. > > The person holding the copyright has all the legal standing to revoke a > > license grant at any time. > > Based on? US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) > > Licenses such as the GPL are not signed contracts, > > and that means there are limits to what effect they can have on the > > copyright > > holder. > > Perhaps that is your local laws, but I'd be surprised anyway. I wouldn't. The US Legal system is rather twisted. > Do you sign contracts when shopping, or are you (and the shop) > allowed to "revoke" the transaction after it's made (I'm not > talking about shop's return policy)? A purchase is separate from a grant of copyright under license. If I purchase a book I have the right to read the book and I have the right to sell the book to someone else, but I have no other rights to it. But if I purchase something, there are rights that go along with said purchase. Under a license such as the GPL (I can't say the same for the BSD/ISC license - I haven't spent enough time studying it to know for sure) no money need change hands for access to the program *and* source. All the rights that anyone *BESIDES* the copyright holder have to the program and/or source comes from license. But since money has not changed hands, there is no further set of rights or guarantees - the copyright holder has not, in general, sold a copy of the work or granted any guarantee that the license will not be revoked. > Is what you wrote only valid WRT licences? Yes. For contracts there is slightly different set of laws in play. > Which country has such laws BTW? The USA. > > In Poland, I can't just go and "revoke" a "statement of will" > if I haven't explicite reserved a right to do so. > Obviously I can act contrary to the statement, and be held liable. Ah, see - in the US the license(s) in question (and licenses in general) are grants of rights, not a "statements of will". If there are to be any limits on the rights of the copyright holder, under US law, they have to be explicitly stated in the license itself. (Truthfully, in the US a license should be read with an implicit "All rights reserved") DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > The fact > > remains that the person making a work available under *ANY* form of > > copyright > > license has the right to revoke said grant of license to anyone. > > Not after the licence has been given and accepted (and there might be > restrictions), unless of course the licence contained such reservation. I hate to belabor the point, but you seem to be making the mistake of "The license applies to the copyright holder" that I've seen a lot of people make (and kept quiet about). The person holding the copyright has all the legal standing to revoke a license grant at any time. Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. If the license was of the "signed contract" type, or contained text stating that the copyright holder was giving up all rights of revocation (etc...) I could agree with you. As it stands, no "Open Source" license that I have seen used on a major project contains any part that does that. In fact, the GPL is the only license I can name (offhand) that even touches on the rights of the copyright holder - and then it is in the form of "If you do X, Y or Z all rights granted under this license are automatically revoked". That is an "automatic clause" - not a limitation stating that the copyright holder can only revoke under those conditions. The person holding the copyright has quite a few rights - more than people believe - and not even the most generous of Open Source licenses (except those that contain text like "granted in perpetuity" or similar) even come close to being exempt from the holder of the copyright not being able to summarily revoke a given persons license. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 13:18:35 Krzysztof Halasa wrote: > Daniel Hazelton <[EMAIL PROTECTED]> writes: > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > Actually it is not. > > Dual BSD/GPL licence essentially means BSD, because rights given by > BSD are a superset of these by GPL. Actually, I was pointing out a logical fallacy. I'll spell it out long here so everyone can see the point I was trying to make. Person A writes a device driver and releases it under a dual license. Person B modifies said device driver and licenses his changes under only one of the licenses on the device driver. Nobody complains. Person C modifies the same device driver and licenses his changes under the other license on the device driver. People start complaining. In this case either the actions of both persons B and C are legal - in which case neither person B or person C is likely to lose a lawsuit (or even face one) - or they are illegal, in which case the second a lawsuit is brought against person C, the same lawsuit must be brought against person B. The exact nature of the licenses and whether one is a superset or subset of the other doesn't matter. Either the action of making modifications licensed solely under one or the other of the two licenses on the original code-base is illegal or it isn't. > The other thing is copyright notices. I think one can't legally > alter someone else's licence conditions (in his/her name), unless > something like that is explicitly permitted. Fully agreed. I've even said such myself. > However, we're talking about derivative works. A derivative > work may be, for example, GPL-licenced: > > "Copyright (C) 1234 Joe the GPL lover > licenced under the GPL as published" > > but could lawfully use code originally licenced under BSD: > > "Portions copyright (C) 1234 Bill the BSD lover > originally licenced under no-ad BSD" > > Thus his (Joe's) work is GPL only, but Bill's licence notice is > intact as required by it (BSD). I've suggested that such be done in the future - if just because it *IS* how it should be done. > > IANAL, maybe you (all of us) should consult one if required. Would cost me money to consult a lawyer over this, but I do have a few friends that have completed law school and are waiting on the results of the BAR. They have told me that they are not legally allowed to dispense legal advice - but I got around that by asking them to recount what the law actually says. Apparently the above suggestion would meet the letter of the law. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole "Linux stealing our code" thing
On Monday 03 September 2007 05:48:00 David Schwartz wrote: > > Mr. Floeter *CAN* request that his code be removed from said fork > > - his code > > is solely licensed (AFAICT and IIRC) under the BSD/ISC license > > and was only > > covered by the dual-license because it was integrated into a work that > > carried said dual-license. (I'm not sure how well such a revocation would > > work in reality, but it is Mr. Floeters right.)... > > No. Neither the BSD license nor the GPL license permit you to revoke > rights. Mr. Floeter's code is still available under the BSD/ISC license. > The BSD license does not require you to make derived works available under > a BSD license. *His* code is still available under a BSD/ISC license, of > course, but the changed code is not. Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. The GPL codifies certain situations in which the person would not, personally, have to revoke the license, but does not limit the original copyright holders rights (in that regard) in any way. The BSD/ISC license has none of the automatic conditions of the GPL, but it also cannot remove the copyright holder(s) from exercising their rights. (And no, I haven't spoken to a lawyer about this - I did, however, ask a recently graduated law-school student where I could look for case-law and the text of the actual laws. What I got was some background on US copyright law itself and an agreement that a copyright license does not - and can not - affect the person holding the copyright) > Read the BSD license. It does not require changes to be made available > under a compatible license. This is the main difference between the BSD and > GPL licenses. Have done so. And that is the only part of the license that I actually don't like. > Note that it would be an error to remove the BSD license text, as the BSD > license requires you to keep it and you still need the BSD license to grant > you distribution rights to the original work. However, the license does not > apply to protectable aspects of the code not placed under the BSD license > by their original author, and it is important to add a note to that effect. Agreed, and I've never claimed otherwise. (Nor has anyone else. I believe the closest that anyone has come was Alan Cox saying (and I'm going to paraphrase it because I don't think he ever stated it well) "If you've made changes to a file that carries a dual BSD/GPL license and your changes are GPL only, the file can no longer be distributed under the BSD license at all. So it is safe to remove the headers from that individual file." There is no way that a license on a constituent file can alter or affect the license on the whole project (if it is different). It can "muddy the waters", but that is about as far as I can see it going. (I realize I may have said different, originally, but you'll have to forgive me. I was not in the best of moods (or the best state of mind) to be making a completely rational argument when I did such.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
(As noted before - I am surround all-caps text with *'s to indicate vocal stress, not volume) On Monday 03 September 2007 05:47:59 David Schwartz wrote: > Daniel Hazelton wrote: > > > Your entire argument is based on the false assumption that > > > these licenses > > > are compatible. They are not. You cannot put code that was offered > > > under the GPLv2 into code that is licensed under the dual license and > > > distribute > > > the result. > > > > Then go yell at Mr. Floeter. The code is dual-licensed and he put > > BSD-License > > only code in it. Because that's the *EXACT* *SAME* thing you're talking > > about. > > This is a completely irrelevent reply. For one thing, I'm not yelling at > anyone, so I don't see why you think I'm being inconsistent or something > because I'm not yelling at Mr. Floeter. > > Actually, it's perfectly fine to put BSD-only code in a dual-licensed file. > You just need to remove the dual license and make the file GPL-only. Huh? You're not making any sense. I think what you meant was "It's perfectly fine to put BSD-only code in a dual-licensed file. You just need to make the file *BSD* only." And you are correct - but you (and I may be wrongly interpreting your words) and a lot of other people have complained that Jiri made modifications to the Atheros code and only licensed his code under the GPL. What none of you have done is complained that Mr. Floeter did the same thing - made changes to the Atheros code and made his changes only available under *ONE* of the licenses. Apparently the reason why people that are complaining about Jiri doing such haven't complained about Floeter doing the same thing is that he used a license that you and the other people like. > > IANAL, but your argument is specious - if the code is > > dual-licensed and you > > are going to let one person add code to it that is only licensed > > under one of > > those licenses, you *CANNOT* complain when somebody else does it > > and chooses > > the other license. (Well, you can, but the complaint has no legal > > standing) > > What argument am I making that's specious? Perhaps you have me confused > with someone else? > > In any event, I utterly reject the argument that you make. Any argument > "you cannot complain about X unless you also complain about Y" is just > totally bogus. You can say "you cannot complain about X and *defend* Y > because X and Y are similar". But the fact that I don't complain about > something creates no inconsistency. I am under no obligation to complain > about everything that contradicts my principles, even things I don't know > about or don't have enough information to give an informed opinion. Wrong - I said "You can't complain about Person A doing X when you let Person B do X without complaint". To whit: you can't complain that Jiri has made changes to a dual-licensed "work" and only released his changes under one of the licenses on the work when somebody else - in this case Msr. Floeter - has done the same thing. > > > That's not the problem. The problem is that if the file stays > > > dual-licensed, everyone working on that file in the Linux > > > kernel will have > > > to be careful not to put any GPLv2-only code into it. That's just > > > untenable. Any consistent license is better than different files being > > > under different licenses such that you can't cut and paste code between > > > files. > > > > Then why aren't you complaining about Mr. Floeters code ? > > Because I am too busy answering nonsensical arguments like yours. Nonsense? Maybe in your little fantasy world. In the real world what I have proved by stating the facts is that you are complaining about something - and apparently claiming that its illegal - when somebody else has done the *EXACT* *SAME* *THING* and you have no problem with it. (And since you apparently keep forgetting, that "exact same thing" is 'making changes to a dual-licensed project and only releasing the changes under one of the licenses on the project) > I am > under no obligation to complain about everything I might disagree with if I > were informed about it. Huh? You are complaining about one person doing something and are not or do not see a need to complain about somebody else who has does the same thing. You either have a problem with the action or you don't - in this case it appears that you are complaining because the person in question made a choice you don't like. > Why aren't you complaining about starving kids in > Africa? Nice straw-man, but I'll answer anyway... I do, all the time. But I also do that in a forum where it does some good, and
Re: GPL weasels and the atheros stink
(As noted before - I am surround all-caps text with *'s to indicate vocal stress, not volume) On Monday 03 September 2007 05:47:59 David Schwartz wrote: Daniel Hazelton wrote: Your entire argument is based on the false assumption that these licenses are compatible. They are not. You cannot put code that was offered under the GPLv2 into code that is licensed under the dual license and distribute the result. Then go yell at Mr. Floeter. The code is dual-licensed and he put BSD-License only code in it. Because that's the *EXACT* *SAME* thing you're talking about. This is a completely irrelevent reply. For one thing, I'm not yelling at anyone, so I don't see why you think I'm being inconsistent or something because I'm not yelling at Mr. Floeter. Actually, it's perfectly fine to put BSD-only code in a dual-licensed file. You just need to remove the dual license and make the file GPL-only. Huh? You're not making any sense. I think what you meant was It's perfectly fine to put BSD-only code in a dual-licensed file. You just need to make the file *BSD* only. And you are correct - but you (and I may be wrongly interpreting your words) and a lot of other people have complained that Jiri made modifications to the Atheros code and only licensed his code under the GPL. What none of you have done is complained that Mr. Floeter did the same thing - made changes to the Atheros code and made his changes only available under *ONE* of the licenses. Apparently the reason why people that are complaining about Jiri doing such haven't complained about Floeter doing the same thing is that he used a license that you and the other people like. IANAL, but your argument is specious - if the code is dual-licensed and you are going to let one person add code to it that is only licensed under one of those licenses, you *CANNOT* complain when somebody else does it and chooses the other license. (Well, you can, but the complaint has no legal standing) What argument am I making that's specious? Perhaps you have me confused with someone else? In any event, I utterly reject the argument that you make. Any argument you cannot complain about X unless you also complain about Y is just totally bogus. You can say you cannot complain about X and *defend* Y because X and Y are similar. But the fact that I don't complain about something creates no inconsistency. I am under no obligation to complain about everything that contradicts my principles, even things I don't know about or don't have enough information to give an informed opinion. Wrong - I said You can't complain about Person A doing X when you let Person B do X without complaint. To whit: you can't complain that Jiri has made changes to a dual-licensed work and only released his changes under one of the licenses on the work when somebody else - in this case Msr. Floeter - has done the same thing. That's not the problem. The problem is that if the file stays dual-licensed, everyone working on that file in the Linux kernel will have to be careful not to put any GPLv2-only code into it. That's just untenable. Any consistent license is better than different files being under different licenses such that you can't cut and paste code between files. Then why aren't you complaining about Mr. Floeters code ? Because I am too busy answering nonsensical arguments like yours. Nonsense? Maybe in your little fantasy world. In the real world what I have proved by stating the facts is that you are complaining about something - and apparently claiming that its illegal - when somebody else has done the *EXACT* *SAME* *THING* and you have no problem with it. (And since you apparently keep forgetting, that exact same thing is 'making changes to a dual-licensed project and only releasing the changes under one of the licenses on the project) I am under no obligation to complain about everything I might disagree with if I were informed about it. Huh? You are complaining about one person doing something and are not or do not see a need to complain about somebody else who has does the same thing. You either have a problem with the action or you don't - in this case it appears that you are complaining because the person in question made a choice you don't like. Why aren't you complaining about starving kids in Africa? Nice straw-man, but I'll answer anyway... I do, all the time. But I also do that in a forum where it does some good, and I even use my own money to try and do something about it. His code doesn't maintain the dual-license. I think the reason is that you could care less about the Dual License and you just want the code - period. You are probably confusing me with someone else. I honestly can't see how your reply in any way fits with what I'm saying. No, no confusion. You could care less about the code being dual-licensed. Your choice of subjects 'GPL
Re: Fwd: That whole Linux stealing our code thing
On Monday 03 September 2007 05:48:00 David Schwartz wrote: Mr. Floeter *CAN* request that his code be removed from said fork - his code is solely licensed (AFAICT and IIRC) under the BSD/ISC license and was only covered by the dual-license because it was integrated into a work that carried said dual-license. (I'm not sure how well such a revocation would work in reality, but it is Mr. Floeters right.)... No. Neither the BSD license nor the GPL license permit you to revoke rights. Mr. Floeter's code is still available under the BSD/ISC license. The BSD license does not require you to make derived works available under a BSD license. *His* code is still available under a BSD/ISC license, of course, but the changed code is not. Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. The GPL codifies certain situations in which the person would not, personally, have to revoke the license, but does not limit the original copyright holders rights (in that regard) in any way. The BSD/ISC license has none of the automatic conditions of the GPL, but it also cannot remove the copyright holder(s) from exercising their rights. (And no, I haven't spoken to a lawyer about this - I did, however, ask a recently graduated law-school student where I could look for case-law and the text of the actual laws. What I got was some background on US copyright law itself and an agreement that a copyright license does not - and can not - affect the person holding the copyright) Read the BSD license. It does not require changes to be made available under a compatible license. This is the main difference between the BSD and GPL licenses. Have done so. And that is the only part of the license that I actually don't like. Note that it would be an error to remove the BSD license text, as the BSD license requires you to keep it and you still need the BSD license to grant you distribution rights to the original work. However, the license does not apply to protectable aspects of the code not placed under the BSD license by their original author, and it is important to add a note to that effect. Agreed, and I've never claimed otherwise. (Nor has anyone else. I believe the closest that anyone has come was Alan Cox saying (and I'm going to paraphrase it because I don't think he ever stated it well) If you've made changes to a file that carries a dual BSD/GPL license and your changes are GPL only, the file can no longer be distributed under the BSD license at all. So it is safe to remove the headers from that individual file. There is no way that a license on a constituent file can alter or affect the license on the whole project (if it is different). It can muddy the waters, but that is about as far as I can see it going. (I realize I may have said different, originally, but you'll have to forgive me. I was not in the best of moods (or the best state of mind) to be making a completely rational argument when I did such.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 13:18:35 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: Then go yell at Mr. Floeter. The code is dual-licensed and he put BSD-License only code in it. Because that's the *EXACT* *SAME* thing you're talking about. Actually it is not. Dual BSD/GPL licence essentially means BSD, because rights given by BSD are a superset of these by GPL. Actually, I was pointing out a logical fallacy. I'll spell it out long here so everyone can see the point I was trying to make. Person A writes a device driver and releases it under a dual license. Person B modifies said device driver and licenses his changes under only one of the licenses on the device driver. Nobody complains. Person C modifies the same device driver and licenses his changes under the other license on the device driver. People start complaining. In this case either the actions of both persons B and C are legal - in which case neither person B or person C is likely to lose a lawsuit (or even face one) - or they are illegal, in which case the second a lawsuit is brought against person C, the same lawsuit must be brought against person B. The exact nature of the licenses and whether one is a superset or subset of the other doesn't matter. Either the action of making modifications licensed solely under one or the other of the two licenses on the original code-base is illegal or it isn't. snip out the straw-man The other thing is copyright notices. I think one can't legally alter someone else's licence conditions (in his/her name), unless something like that is explicitly permitted. Fully agreed. I've even said such myself. However, we're talking about derivative works. A derivative work may be, for example, GPL-licenced: Copyright (C) 1234 Joe the GPL lover licenced under the GPL as published but could lawfully use code originally licenced under BSD: Portions copyright (C) 1234 Bill the BSD lover originally licenced under no-ad BSD Thus his (Joe's) work is GPL only, but Bill's licence notice is intact as required by it (BSD). I've suggested that such be done in the future - if just because it *IS* how it should be done. IANAL, maybe you (all of us) should consult one if required. Would cost me money to consult a lawyer over this, but I do have a few friends that have completed law school and are waiting on the results of the BAR. They have told me that they are not legally allowed to dispense legal advice - but I got around that by asking them to recount what the law actually says. Apparently the above suggestion would meet the letter of the law. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole Linux stealing our code thing
On Monday 03 September 2007 14:26:29 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. Not after the licence has been given and accepted (and there might be restrictions), unless of course the licence contained such reservation. I hate to belabor the point, but you seem to be making the mistake of The license applies to the copyright holder that I've seen a lot of people make (and kept quiet about). The person holding the copyright has all the legal standing to revoke a license grant at any time. Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. If the license was of the signed contract type, or contained text stating that the copyright holder was giving up all rights of revocation (etc...) I could agree with you. As it stands, no Open Source license that I have seen used on a major project contains any part that does that. In fact, the GPL is the only license I can name (offhand) that even touches on the rights of the copyright holder - and then it is in the form of If you do X, Y or Z all rights granted under this license are automatically revoked. That is an automatic clause - not a limitation stating that the copyright holder can only revoke under those conditions. The person holding the copyright has quite a few rights - more than people believe - and not even the most generous of Open Source licenses (except those that contain text like granted in perpetuity or similar) even come close to being exempt from the holder of the copyright not being able to summarily revoke a given persons license. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: That whole Linux stealing our code thing
On Monday 03 September 2007 15:33:01 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: I hate to belabor the point, but you seem to be making the mistake of The license applies to the copyright holder Of course not. I'll take this at face value - I might have mis-parsed your earlier statements wrong. The person holding the copyright has all the legal standing to revoke a license grant at any time. Based on? US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) Licenses such as the GPL are not signed contracts, and that means there are limits to what effect they can have on the copyright holder. Perhaps that is your local laws, but I'd be surprised anyway. I wouldn't. The US Legal system is rather twisted. Do you sign contracts when shopping, or are you (and the shop) allowed to revoke the transaction after it's made (I'm not talking about shop's return policy)? A purchase is separate from a grant of copyright under license. If I purchase a book I have the right to read the book and I have the right to sell the book to someone else, but I have no other rights to it. But if I purchase something, there are rights that go along with said purchase. Under a license such as the GPL (I can't say the same for the BSD/ISC license - I haven't spent enough time studying it to know for sure) no money need change hands for access to the program *and* source. All the rights that anyone *BESIDES* the copyright holder have to the program and/or source comes from license. But since money has not changed hands, there is no further set of rights or guarantees - the copyright holder has not, in general, sold a copy of the work or granted any guarantee that the license will not be revoked. Is what you wrote only valid WRT licences? Yes. For contracts there is slightly different set of laws in play. Which country has such laws BTW? The USA. In Poland, I can't just go and revoke a statement of will if I haven't explicite reserved a right to do so. Obviously I can act contrary to the statement, and be held liable. Ah, see - in the US the license(s) in question (and licenses in general) are grants of rights, not a statements of will. If there are to be any limits on the rights of the copyright holder, under US law, they have to be explicitly stated in the license itself. (Truthfully, in the US a license should be read with an implicit All rights reserved) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Monday 03 September 2007 20:23:37 David Schwartz wrote: Wrong - I said You can't complain about Person A doing X when you let Person B do X without complaint. Yes, I can. There is no inconsistency between acting in one case and failing to act in another. We need not act in every possible case where we could act to preserve our right to act in a particular case. Sorry, I should have said that you cannot prosecute one person for doing something without prosecuting everyone that is doing it. Otherwise you have lost the case before it has started - no judge would allow such a one sided application of the law. To whit: you can't complain that Jiri has made changes to a dual-licensed work and only released his changes under one of the licenses on the work when somebody else - in this case Msr. Floeter - has done the same thing. First of all, I haven't complained about Jiri's changes. Second, I most certainly can. I can complain about one murder without complaining about every murder. There is no inconsistency whatsoever with acting in one case without having to act in every other conceivable case. Sorry, this ties back to the original statement and the implied threats of legal action by Theo and backed up by almost every OpenBSD developer that has participated in this discussion. It's a mis-statement of mine - see above. If you are going to prosecute one person for doing something, you have to prosecute everyone who does it. We can complain about or work to fight whatever injustices we like. There is no obligation to address every equal, or greater, injustice before working on the injustice of one's choice. Yes, of course. No, no confusion. You could care less about the code being dual-licensed. Your choice of subjects 'GPL weasels' speaks volumes. *My* choice of subjects?! You seem to have me confused with someone else entirely. Potentially - I am terrible with names and had assumed that you were the person who had forked the Stealing Our Code thread with the GPL weasels subject. If my assumption is faulty, then I apologize and ask your forgiveness for my false accusation. My sole points in this thread were to: 1) Correct some misunderstandings about how dual licenses actually work. This was, IIRC, already well understood by most of the people on the Linux Kernel side of things. (Alan Cox has given several quite lucid statements showing that he, at least, does understand this) 2) Explain *why* a file cannot really remain dual-licensed if it's part of the Linux kernel distribution. A file/files can have as many licenses on it as the developer wants, provided that at least one of them is the GPL(v2). That is because, for it to be legally distributed as part of the Linux Kernel it has to be done so under the auspices of the license on the Linux Kernel - the GPLv2. While I generally prefer the BSD license to the GPL license and tend to be a pretty vocal GPL critic, I have said many times that almost any *consistent* license is better for a large project than different licenses, even if they're compatible, on different files. I am critical of the GPL myself, as is Linus and a lot of people. (Linus himself has said, numerous times, that he is no fan of the GPL, but it is the best that exists (his words and opinion) - and I have heard similar sentiments from a lot of people.) I am not a fan of the BSD license because I'd like to be able to incorporate any changes someone might make back into the original code. There is no requirement in the BSD license for someone to make their changes to my code available to me - so I am not a fan of it. Doesn't matter if the BSD license or the GPL *PERMITS* it or not. The fact remains that the person making a work available under *ANY* form of copyright license has the right to revoke said grant of license to anyone. The GPL codifies certain situations in which the person would not, personally, have to revoke the license, but does not limit the original copyright holders rights (in that regard) in any way. I'm not sure where you're getting this from, but it's not true. Linus cannot decide tomorrow that nobody can distribute the Linux kernel anymore. In the US you have to explicitly waive rights for you to not have them (in regards to licenses). Although, considering what I have been informed of in regards to the law in Poland (and, seeing as how this has surprised a lot of people, likely a large number of other countries), to make sure those rights are reserved they should be explicitly spelled out in the text of the license. And the truth is that Linus could do that - if he required contributors to do a copyright assignment (which would make him the holder of the sole copyright on the Linux Kernel). Since Linus is *NOT* the sole copyright holder on Linux, he cannot do this. He could, if he was so inclined, perform such a license revocation on code he holds
Re: Fwd: That whole "Linux stealing our code" thing
(by the way, text in caps surrounded by *'s is meant to indicate vocal stress,
not volume)
On Sunday 02 September 2007 22:01:18 David Schwartz wrote:
> > So I appear to have a
> > right to convey the work under the GPL to a third party, who from me
> > receives no right to use it except under the GPL.
>
> Here's where your train goes off the rails. They do not receive any right
> to use it from you. They receive a license to use it under the GPL from the
> original author. Please read GPL section 6.
>
> " 6. Each time you redistribute the Program (or any work based on the
> Program), the recipient automatically receives a license from the
> original licensor to copy, distribute or modify the Program subject to
> these terms and conditions. You may not impose any further
> restrictions on the recipients' exercise of the rights granted herein.
> You are not responsible for enforcing compliance by third parties to
> this License."
>
> The GPL does not give you *any* right to extend anyone a license to code
> you did not author. (Nor can it as such an extension would have to be done
> in writing in most countries.) When you distribute a GPL'd work, the right
> to use every creative element in that work is licensed to the recipients
> directly from their respective authors. Under no circumstances does the GPL
> ever give you the ability to license someone else's work to a third party.
However, this is not what is happening here. Jiri has made changes that he has
licensed solely under the GPLv2. This means that he now becomes the
licensor - not Mr. Floeter or Mr. Leffler. *BUT* *ONLY* of the version of the
code containing his changes.
Mr. Floeter *CAN* request that his code be removed from said fork - his code
is solely licensed (AFAICT and IIRC) under the BSD/ISC license and was only
covered by the dual-license because it was integrated into a work that
carried said dual-license. (I'm not sure how well such a revocation would
work in reality, but it is Mr. Floeters right.)...
(Sam Leffler could do the same - but I'm not sure how well that would carry.)
> > * Alternatively, this software may be distributed under the terms of the
> > * GNU General Public License ("GPL") version 2 as published by the Free
> > * Software Foundation.
> >
> > The choice appears to be delegated to the recipient very clearly and
> > very specifically by the licencing on the file. It does not say that I
> > must convey the work under both licences. It quite specifically says I
> > may convey the work under whichever of the two I prefer (and probably
> > both if I wish). Clearly if that had not been the intent it would not
> > have included the clause giving the choice.
>
> Either license can grant you the right to distribute it, but how you get
> the rights to distribute has *NO* effect on the recipient. They receive a
> lawful copy and any rights the original author grants them under a license
> from that original author. You have no power to grant or modify rights to
> the original work.
Correct. Doesn't apply in the case of the code in question (unless the changes
that were made are so tiny as to not be copyrightable).
In this case the code is question is a modified version, which means that the
right to distribute said modified version now originates with the person
holding the copyright on the modifications. (Though their right to distribute
the code, in such a situation, is lessened quite a bit by the text of the
license they received the code under)
> This is a common misunderstanding.
No misunderstanding, really.
Alan seems to have given a bad example that doesn't apply to the situation
that is being discussed.
> Note that you may remove the text of either license from a dual-licensed
> file and redistribute under the other license because neither license
> requires you to retain the other license and both licenses give you the
> right otherwise to modify as you wish. But the removal of a license from a
> file has no effect on the grant of license. Your recipients still get a
> dual license to those protectable elements in the file that were placed
> under a dual license. You cannot stop the automatic grant.
Agreed. When re-distributing an un-modified copy of a work. When distributing
a modified work, the "work" has the license that the person who made the
modifications places on it. But individual files and pieces of code will
still retain their original license - this is how it works.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL weasels and the atheros stink
On Sunday 02 September 2007 22:01:17 David Schwartz wrote: > > Letting aside the legality of that change, why would such a change > > be needed ? The licensing is perfectly clear: the file is available > > under the ISC licence, OR the GPL licence. This doesn't cause any > > problem for the linux kernel. The ISC licence is perfectly compatible > > with the GPL (note to GPL trolls: this new licence does not have any > > advertizing clause, which was the ONLY issue with the old licence). And > > heck, they can use the code under the GPL licence. There is no > > incompatibility > > in there. > > Your entire argument is based on the false assumption that these licenses > are compatible. They are not. You cannot put code that was offered under > the GPLv2 into code that is licensed under the dual license and distribute > the result. Then go yell at Mr. Floeter. The code is dual-licensed and he put BSD-License only code in it. Because that's the *EXACT* *SAME* thing you're talking about. IANAL, but your argument is specious - if the code is dual-licensed and you are going to let one person add code to it that is only licensed under one of those licenses, you *CANNOT* complain when somebody else does it and chooses the other license. (Well, you can, but the complaint has no legal standing) > > The only possible issue is related to paranoia: if this file stays > > dual-licenced, some of its code may escape from the GPL shrine, and > > become available to the cuddly BSD people... but since their licence > > doesn't protect anything, it could used by the Evil Empire of Microsoft, > > or SCO, or whoever is the villain of the month. > > That's not the problem. The problem is that if the file stays > dual-licensed, everyone working on that file in the Linux kernel will have > to be careful not to put any GPLv2-only code into it. That's just > untenable. Any consistent license is better than different files being > under different licenses such that you can't cut and paste code between > files. Then why aren't you complaining about Mr. Floeters code ? His code doesn't maintain the dual-license. I think the reason is that you could care less about the "Dual License" and you just want the code - period. > > Let's extend the story a wee little bit. It seems that these days, some > > parts of the opensource community have gotten confident enough that they > > do not need the other part. We all know the situation is already fairly > > disymetric. The GPL is less free than the ISC licence for instance (for > > some definition of free), and practically, this makes it impossible to > > add GPL code to an ISC project without putting the project under the > > Aegis of the GPL licence. The reciprocal relationship does NOT hold. As > > you can see in various places, it is quite possible to put BSD code > > inside a GPL project without any issue (the FSF libiberty is a nice proof > > of that. And heck, the glibc as well... Read carefully past the COPYING > > file, you'll find numerous instances of BSD-like licences). > > If you embed protectable elements from GPLv2-only code into any of those > files, they are no longer dual-licensed. You wind up creating traps and > complexity that makes the code much harder to maintain. The same can be said of Floeters code. *ALL* of his code, IIRC, is *SINGLE-LICENSE*. ie: a complexity trap. But you aren't complaining about his code - you are complaining that somebody is doing the same thing, but is using the side of the dual-license you don't like. Nothing *LEGALLY* actionable there. > > Do you really think he's going to keep his work under a > > dual-licence, seeing > > how a bunch of rabid linux zealots are all but intent on stealing his > > code whenever they can. > > > > Nice going, GPL fan-boys... > > A dual-license is a compromise. One of the downsides is that you may force > large projects that are under one license or the other to fork the code. If > that bothers you, don't dual license. Exactly. If you want to only have your code available under a specific license but rely on dual-licensed code, you create a fork that contains the new code under that side of the license. For instance: Suppose I've written a new filesystem and released it with three licenses - CDDL, BSD/ISC and GPL(v2) - and a Linux developer decides to import my FS into Linux. But the code isn't optimal for Linux, so he fixes it - and only wants his code usable under the GPLv2 - he can do this - it just means that that fork isn't usable under the other two licenses. Note that the boundary of what a "work" consists of is complex - but as far as a computer program goes it is "the collection of source code needed to build the functional result" or "the functional result". This means that I can contribute as much code as I want to a project under whatever license I choose, but the project itself can have a different license. In the case of the code in question, that means that the second
Re: GPL weasels and the atheros stink
On Sunday 02 September 2007 22:01:17 David Schwartz wrote: Letting aside the legality of that change, why would such a change be needed ? The licensing is perfectly clear: the file is available under the ISC licence, OR the GPL licence. This doesn't cause any problem for the linux kernel. The ISC licence is perfectly compatible with the GPL (note to GPL trolls: this new licence does not have any advertizing clause, which was the ONLY issue with the old licence). And heck, they can use the code under the GPL licence. There is no incompatibility in there. Your entire argument is based on the false assumption that these licenses are compatible. They are not. You cannot put code that was offered under the GPLv2 into code that is licensed under the dual license and distribute the result. Then go yell at Mr. Floeter. The code is dual-licensed and he put BSD-License only code in it. Because that's the *EXACT* *SAME* thing you're talking about. IANAL, but your argument is specious - if the code is dual-licensed and you are going to let one person add code to it that is only licensed under one of those licenses, you *CANNOT* complain when somebody else does it and chooses the other license. (Well, you can, but the complaint has no legal standing) The only possible issue is related to paranoia: if this file stays dual-licenced, some of its code may escape from the GPL shrine, and become available to the cuddly BSD people... but since their licence doesn't protect anything, it could used by the Evil Empire of Microsoft, or SCO, or whoever is the villain of the month. That's not the problem. The problem is that if the file stays dual-licensed, everyone working on that file in the Linux kernel will have to be careful not to put any GPLv2-only code into it. That's just untenable. Any consistent license is better than different files being under different licenses such that you can't cut and paste code between files. Then why aren't you complaining about Mr. Floeters code ? His code doesn't maintain the dual-license. I think the reason is that you could care less about the Dual License and you just want the code - period. Let's extend the story a wee little bit. It seems that these days, some parts of the opensource community have gotten confident enough that they do not need the other part. We all know the situation is already fairly disymetric. The GPL is less free than the ISC licence for instance (for some definition of free), and practically, this makes it impossible to add GPL code to an ISC project without putting the project under the Aegis of the GPL licence. The reciprocal relationship does NOT hold. As you can see in various places, it is quite possible to put BSD code inside a GPL project without any issue (the FSF libiberty is a nice proof of that. And heck, the glibc as well... Read carefully past the COPYING file, you'll find numerous instances of BSD-like licences). If you embed protectable elements from GPLv2-only code into any of those files, they are no longer dual-licensed. You wind up creating traps and complexity that makes the code much harder to maintain. The same can be said of Floeters code. *ALL* of his code, IIRC, is *SINGLE-LICENSE*. ie: a complexity trap. But you aren't complaining about his code - you are complaining that somebody is doing the same thing, but is using the side of the dual-license you don't like. Nothing *LEGALLY* actionable there. snip Do you really think he's going to keep his work under a dual-licence, seeing how a bunch of rabid linux zealots are all but intent on stealing his code whenever they can. Nice going, GPL fan-boys... A dual-license is a compromise. One of the downsides is that you may force large projects that are under one license or the other to fork the code. If that bothers you, don't dual license. Exactly. If you want to only have your code available under a specific license but rely on dual-licensed code, you create a fork that contains the new code under that side of the license. For instance: Suppose I've written a new filesystem and released it with three licenses - CDDL, BSD/ISC and GPL(v2) - and a Linux developer decides to import my FS into Linux. But the code isn't optimal for Linux, so he fixes it - and only wants his code usable under the GPLv2 - he can do this - it just means that that fork isn't usable under the other two licenses. Note that the boundary of what a work consists of is complex - but as far as a computer program goes it is the collection of source code needed to build the functional result or the functional result. This means that I can contribute as much code as I want to a project under whatever license I choose, but the project itself can have a different license. In the case of the code in question, that means that the second Mr. Floeters code was distributed as a part of the whole work that constitutes the
Re: Ok, lets kill the 'PCI hidden behind bridge' message (was: pci=assign-busses)
On Monday 30 July 2007 14:35:13 Bernhard Kaindl wrote: > Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by > Yenta, so PCI does not have to warn about it. PCI could still warn about it > if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have > not seen a report where this would have been the case so I think we can > spare the kernel of that check (removes ~300 lines of asm) unless debugging > is done. > > History: The whole check was added in the days before we had the fixup > for this in Yenta and pci=assign-busses was the only way to get CardBus > cards detected on many (not all) of the machines which give this warning. The message triggers on systems without Cardbus at all. > In theory, there could be cases when this warning would be triggered and > it's not cardbus, then the warning should still apply, but I think this > should only be the case when working on a completely broken PCI setup, > but one may have already enabled the debug code in drivers/pci and the > patched check would then trigger. I wouldn't say totally broken. The last 5 computers I've owned have had this message. On only one could it even *remotely* be related to CardBus (my one year old laptop), and on one of them it does create problems for certain (NVidia) binary drivers. (and then pci=assign-busses doesn't do jack to clear the message) I'm not saying that binary drivers shouldn't be broken - but... DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, lets kill the 'PCI hidden behind bridge' message (was: pci=assign-busses)
On Monday 30 July 2007 14:35:13 Bernhard Kaindl wrote: snip Ok, lets kill the message. As Alois Nešpor also saw, that's fixed up by Yenta, so PCI does not have to warn about it. PCI could still warn about it if is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have not seen a report where this would have been the case so I think we can spare the kernel of that check (removes ~300 lines of asm) unless debugging is done. History: The whole check was added in the days before we had the fixup for this in Yenta and pci=assign-busses was the only way to get CardBus cards detected on many (not all) of the machines which give this warning. The message triggers on systems without Cardbus at all. In theory, there could be cases when this warning would be triggered and it's not cardbus, then the warning should still apply, but I think this should only be the case when working on a completely broken PCI setup, but one may have already enabled the debug code in drivers/pci and the patched check would then trigger. I wouldn't say totally broken. The last 5 computers I've owned have had this message. On only one could it even *remotely* be related to CardBus (my one year old laptop), and on one of them it does create problems for certain (NVidia) binary drivers. (and then pci=assign-busses doesn't do jack to clear the message) I'm not saying that binary drivers shouldn't be broken - but... snip DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Sunday 29 July 2007 16:00:22 Ray Lee wrote: > On 7/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote: > > If the problem is reading stuff back in from swap at the *same time* > > that the application is reading stuff from some user file system, and if > > that user file system is on the same drive as the swap partition > > (typical on laptops), then interleaving the user file system accesses > > with the swap partition accesses might overwhelm all other performance > > problems, due to the frequent long seeks between the two. > > Ah, so in a normal scenario where a working-set is getting faulted > back in, we have the swap storage as well as the file-backed stuff > that needs to be read as well. So even if swap is organized perfectly, > we're still seeking. Damn. That is one reason why I try to have swap on a device dedicated just for it. It helps keep the system from having to seek all over the drive for data. (I remember that this was recommended years ago with Windows - back when you could tell Windows where to put the swap file) > On the other hand, that explains another thing that swap prefetch > could be helping with -- if it preemptively faults the swap back in, > then the file-backed stuff can be faulted back more quickly, just by > the virtue of not needing to seek back and forth to swap for its > stuff. Hadn't thought of that. For it to really help swap-prefetch would have to be more aggressive. At the moment (if I'm reading the code correctly) the system has to have close to zero for it to kick in. A tunable knob controlling how much activity is too much for the prefetch to kick in would help with finding a sane default. IMHO it should be the one that provides the most benefit with the least hit to performance. > That also implies that people running with swap files rather than swap > partitions will see less of an issue. I should dig out my old compact > flash card and try putting swap on that for a week. Maybe. It all depends on how much seeking is needed to track down the pages in the swapfile and such. What would really help make the situation even better would be doing the log structured swap + cleaner. The log structured swap + cleaner should provide a performance boost by itself - add in the prefetch mechanism and the benefits are even more visible. Another way to improve performance would require making the page replacement mechanism more intelligent. There are bounds to what can be done in the kernel without negatively impacting performance, but, if I've read the code correctly, there might be a better way to decide which pages to evict. One way to do this would be to implement some mechanism that allows the system to choose a single group of contiguous pages (or, say, a large soft-page) over swapping out a single page at a time. (some form of memory defrag would also be nice, but I can't think of a way to do that without massively breaking everything) > > In case Andrew is so bored he read this far -- yes this wake-up sounds > > like user space code, with minimal kernel changes to support any > > particular lower level operation that we can't do already. > > He'd suggested using, uhm, ptrace_peek or somesuch for just such a > purpose. The second half of the issue is to know when and what to > target. The userspace suggestion that was thrown out earlier would have been as error-prone and problematic as FUSE. A solution like you suggest would be workable - its small and does a task that is best done in userspace (IMHO). (IIRC, the original suggestion involved merging maps2 and another patchset into mainline and using that, combined with PEEKTEXT to provide for a userspace swap daemon. Swap, IMHO, should never be handled outside the kernel) What might be useful is a userspace daemon that tracks memory pressure and uses a concise API to trigger various levels of prefetch and/or swap aggressiveness. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Sunday 29 July 2007 16:00:22 Ray Lee wrote: On 7/29/07, Paul Jackson [EMAIL PROTECTED] wrote: If the problem is reading stuff back in from swap at the *same time* that the application is reading stuff from some user file system, and if that user file system is on the same drive as the swap partition (typical on laptops), then interleaving the user file system accesses with the swap partition accesses might overwhelm all other performance problems, due to the frequent long seeks between the two. Ah, so in a normal scenario where a working-set is getting faulted back in, we have the swap storage as well as the file-backed stuff that needs to be read as well. So even if swap is organized perfectly, we're still seeking. Damn. That is one reason why I try to have swap on a device dedicated just for it. It helps keep the system from having to seek all over the drive for data. (I remember that this was recommended years ago with Windows - back when you could tell Windows where to put the swap file) On the other hand, that explains another thing that swap prefetch could be helping with -- if it preemptively faults the swap back in, then the file-backed stuff can be faulted back more quickly, just by the virtue of not needing to seek back and forth to swap for its stuff. Hadn't thought of that. For it to really help swap-prefetch would have to be more aggressive. At the moment (if I'm reading the code correctly) the system has to have close to zero for it to kick in. A tunable knob controlling how much activity is too much for the prefetch to kick in would help with finding a sane default. IMHO it should be the one that provides the most benefit with the least hit to performance. That also implies that people running with swap files rather than swap partitions will see less of an issue. I should dig out my old compact flash card and try putting swap on that for a week. Maybe. It all depends on how much seeking is needed to track down the pages in the swapfile and such. What would really help make the situation even better would be doing the log structured swap + cleaner. The log structured swap + cleaner should provide a performance boost by itself - add in the prefetch mechanism and the benefits are even more visible. Another way to improve performance would require making the page replacement mechanism more intelligent. There are bounds to what can be done in the kernel without negatively impacting performance, but, if I've read the code correctly, there might be a better way to decide which pages to evict. One way to do this would be to implement some mechanism that allows the system to choose a single group of contiguous pages (or, say, a large soft-page) over swapping out a single page at a time. (some form of memory defrag would also be nice, but I can't think of a way to do that without massively breaking everything) snip In case Andrew is so bored he read this far -- yes this wake-up sounds like user space code, with minimal kernel changes to support any particular lower level operation that we can't do already. He'd suggested using, uhm, ptrace_peek or somesuch for just such a purpose. The second half of the issue is to know when and what to target. The userspace suggestion that was thrown out earlier would have been as error-prone and problematic as FUSE. A solution like you suggest would be workable - its small and does a task that is best done in userspace (IMHO). (IIRC, the original suggestion involved merging maps2 and another patchset into mainline and using that, combined with PEEKTEXT to provide for a userspace swap daemon. Swap, IMHO, should never be handled outside the kernel) What might be useful is a userspace daemon that tracks memory pressure and uses a concise API to trigger various levels of prefetch and/or swap aggressiveness. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 17:06:50 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Daniel Hazelton wrote: > > On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > >> On Sat, 28 Jul 2007, Rene Herman wrote: > >>> On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >>>> On Fri, 27 Jul 2007, Rene Herman wrote: > >>>>> On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > >> nobody is arguing that swap prefetch helps in the second cast. > > > > Actually, I made a mistake when tracking the thread and reading the code > > for the patch and started to argue just that. But I have to admit I made > > a mistake - the patches author has stated (as Rene was kind enough to > > point out) that swap prefetch can't help when memory is filled. > > I stand corrected, thaks for speaking up and correcting your position. If you had made the statement before I decided to speak up you would have been correct :) Anyway, I try to always admit when I've made a mistake - its part of my philosophy. (There have been times when I haven't done it, but I'm trying to make that stop entirely) > >> what people are arguing is that there are situations where it helps for > >> the first case. on some machines and version of updatedb the nighly run > >> of updatedb can cause both sets of problems. but the nightly updatedb > >> run is not the only thing that can cause problems > > > > Solving the cache filling memory case is difficult. There have been a > > number of discussions about it. The simplest solution, IMHO, would be to > > place a (configurable) hard limit on the maximum size any of the kernels > > caches can grow to. (The only solution that was discussed, however, is a > > complex beast) > > limiting the size of the cache is also the wrong thing to do in many > situations. it's only right if the cache pushes out other data you care > about, if you are trying to do one thing as fast as you can you really do > want the system to use all the memory it can for the cache. After thinking about this you are partially correct. There are those sorts of situations where you want the system to use all the memory it can for caches. OTOH, if those situations could be described in some sort of simple heuristic, then a soft-limit that uses those heuristics to determine when to let the cache expand could exploit the benefits of having both a limited and unlimited cache. (And, potentially, if the heuristic has allowed a cache to expand beyond the limit then, when the heuristic no longer shows the oversize cache is no longer necessary it could trigger and automatic reclaim of that memory.) (I'm willing to help write and test code to do this exactly. There is no guarantee that I'll be able to help with more than testing - I don't understand the parts of the code involved all that well) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Rene Herman wrote: > > On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >> On Fri, 27 Jul 2007, Rene Herman wrote: > >> > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > > Questions about it: > >> > > Q) Does swap-prefetch help with this? > >> > > A) [From all reports I've seen (*)] > >> > > Yes, it does. > >> > > >> > No it does not. If updatedb filled memory to the point of causing > >> > swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and > >> > swap-prefetch hasn't any memory to prefetch into -- updatedb itself > >> > doesn't use any significant memory. > >> > >> however there are other programs which are known to take up significant > >> amounts of memory and will cause the issue being described (openoffice > >> for example) > >> > >> please don't get hung up on the text 'updatedb' and accept that there > >> are programs that do run intermittently and do use a significant amount > >> of ram and then free it. > > > > Different issue. One that's worth pursueing perhaps, but a different > > issue from the VFS caches issue that people have been trying to track > > down. > > people are trying to track down the problem of their machine being slow > until enough data is swapped back in to operate normally. > > in at some situations swap prefetch can help becouse something that used > memory freed it so there is free memory that could be filled with data > (which is something that Linux does agressivly in most other situations) > > in some other situations swap prefetch cannot help becouse useless data is > getting cached at the expense of useful data. > > nobody is arguing that swap prefetch helps in the second cast. Actually, I made a mistake when tracking the thread and reading the code for the patch and started to argue just that. But I have to admit I made a mistake - the patches author has stated (as Rene was kind enough to point out) that swap prefetch can't help when memory is filled. > what people are arguing is that there are situations where it helps for > the first case. on some machines and version of updatedb the nighly run of > updatedb can cause both sets of problems. but the nightly updatedb run is > not the only thing that can cause problems Solving the cache filling memory case is difficult. There have been a number of discussions about it. The simplest solution, IMHO, would be to place a (configurable) hard limit on the maximum size any of the kernels caches can grow to. (The only solution that was discussed, however, is a complex beast) > > but let's talk about the concept here for a little bit > > the design is to use CPU and I/O capacity that's otherwise idle to fill > free memory with data from swap. > > pro: >more ram has potentially useful data in it > > con: >it takes a little extra effort to give this memory to another app (the > page must be removed from the list and zeroed at the time it's needed, I > assume that the data is left in swap so that it doesn't have to be written > out again) > >it adds some complexity to the kernel (~500 lines IIRC from this thread) > >by undoing recent swapouts it can potentially mask problems with swapout > > it looks to me like unless the code was really bad (and after 23 months in > -mm it doesn't sound like it is) that the only significant con left is the > potential to mask other problems. I'll second this. But with the swap system itself having seen as heavy testing as it has I don't know if it would be masking other problems. That is why I've been asking "What is so wrong with it?" - while it definately doesn't help with programs that cause caches to balloon (that problem does need another solution) it does help to speed things up when a memory hog has exited. (And since its a pretty safe assumption that swap is going to be noticeably slower than RAM this patch seems to me to be a rather visible and obvious solution to that problem) > however there are many legitimate cases where it is definantly dong the > right thing (swapout was correct in pushing out the pages, but now the > cause of that preasure is gone). the amount of benifit from this will vary > from situation to situation, but it's not reasonable to claim that this > provides no benifit (you have benchmark numbers that show it in synthetic > benchmarks, and you have user reports that show it in the real-worlk) Exactly. Though I have seen posts which (to me at least) appear to claim exactly that. It was part of the reason why I got a bit
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 03:48:13 Mike Galbraith wrote: > On Fri, 2007-07-27 at 18:51 -0400, Daniel Hazelton wrote: > > Now, once more, I'm going to ask: What is so terribly wrong with swap > > prefetch? Why does it seem that everyone against it says "Its treating a > > symptom, so it can't go in"? > > And once again, I personally have nothing against swap-prefetch, or > something like it. I can see how it or something like it could be made > to improve the lives of people who get up in the morning to find their > apps sitting on disk due to memory pressure generated by over-night > system maintenance operations. > > The author himself however, says his implementation can't help with > updatedb (though people seem to be saying that it does), or anything > else that leaves memory full. That IMHO, makes it of questionable value > toward solving what people are saying they want swap-prefetch for in the > first place. Okay. I have to agree with the author that, in such a situation, it wouldn't help. However there are, without a doubt, other situations where it would help immensely. (memory hogs forcing everything to disk and quitting, one off tasks that don't balloon the cache (kernel compiles, et al) - in those situations swap prefetch would really shine.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 03:48:13 Mike Galbraith wrote: On Fri, 2007-07-27 at 18:51 -0400, Daniel Hazelton wrote: Now, once more, I'm going to ask: What is so terribly wrong with swap prefetch? Why does it seem that everyone against it says Its treating a symptom, so it can't go in? And once again, I personally have nothing against swap-prefetch, or something like it. I can see how it or something like it could be made to improve the lives of people who get up in the morning to find their apps sitting on disk due to memory pressure generated by over-night system maintenance operations. The author himself however, says his implementation can't help with updatedb (though people seem to be saying that it does), or anything else that leaves memory full. That IMHO, makes it of questionable value toward solving what people are saying they want swap-prefetch for in the first place. Okay. I have to agree with the author that, in such a situation, it wouldn't help. However there are, without a doubt, other situations where it would help immensely. (memory hogs forcing everything to disk and quitting, one off tasks that don't balloon the cache (kernel compiles, et al) - in those situations swap prefetch would really shine.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: On Sat, 28 Jul 2007, Rene Herman wrote: On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. No it does not. If updatedb filled memory to the point of causing swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch hasn't any memory to prefetch into -- updatedb itself doesn't use any significant memory. however there are other programs which are known to take up significant amounts of memory and will cause the issue being described (openoffice for example) please don't get hung up on the text 'updatedb' and accept that there are programs that do run intermittently and do use a significant amount of ram and then free it. Different issue. One that's worth pursueing perhaps, but a different issue from the VFS caches issue that people have been trying to track down. people are trying to track down the problem of their machine being slow until enough data is swapped back in to operate normally. in at some situations swap prefetch can help becouse something that used memory freed it so there is free memory that could be filled with data (which is something that Linux does agressivly in most other situations) in some other situations swap prefetch cannot help becouse useless data is getting cached at the expense of useful data. nobody is arguing that swap prefetch helps in the second cast. Actually, I made a mistake when tracking the thread and reading the code for the patch and started to argue just that. But I have to admit I made a mistake - the patches author has stated (as Rene was kind enough to point out) that swap prefetch can't help when memory is filled. what people are arguing is that there are situations where it helps for the first case. on some machines and version of updatedb the nighly run of updatedb can cause both sets of problems. but the nightly updatedb run is not the only thing that can cause problems Solving the cache filling memory case is difficult. There have been a number of discussions about it. The simplest solution, IMHO, would be to place a (configurable) hard limit on the maximum size any of the kernels caches can grow to. (The only solution that was discussed, however, is a complex beast) but let's talk about the concept here for a little bit the design is to use CPU and I/O capacity that's otherwise idle to fill free memory with data from swap. pro: more ram has potentially useful data in it con: it takes a little extra effort to give this memory to another app (the page must be removed from the list and zeroed at the time it's needed, I assume that the data is left in swap so that it doesn't have to be written out again) it adds some complexity to the kernel (~500 lines IIRC from this thread) by undoing recent swapouts it can potentially mask problems with swapout it looks to me like unless the code was really bad (and after 23 months in -mm it doesn't sound like it is) that the only significant con left is the potential to mask other problems. I'll second this. But with the swap system itself having seen as heavy testing as it has I don't know if it would be masking other problems. That is why I've been asking What is so wrong with it? - while it definately doesn't help with programs that cause caches to balloon (that problem does need another solution) it does help to speed things up when a memory hog has exited. (And since its a pretty safe assumption that swap is going to be noticeably slower than RAM this patch seems to me to be a rather visible and obvious solution to that problem) however there are many legitimate cases where it is definantly dong the right thing (swapout was correct in pushing out the pages, but now the cause of that preasure is gone). the amount of benifit from this will vary from situation to situation, but it's not reasonable to claim that this provides no benifit (you have benchmark numbers that show it in synthetic benchmarks, and you have user reports that show it in the real-worlk) Exactly. Though I have seen posts which (to me at least) appear to claim exactly that. It was part of the reason why I got a bit incensed. (The other was that it looked like the kernel devs with the ultra-powerful machines were claiming 'I don't see the problem on my machine, so it doesn't exist'. That sort of attitude is fine, in some cases, but not, IMHO, where performance is concerned) there are lots of things in the kernel who's job is to pre-fill the memroy with data that may (or may not) be useful in the future. this is just another method of filling the cache. it does so my saying the user wanted these pages in the recent past
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 17:06:50 [EMAIL PROTECTED] wrote: On Sat, 28 Jul 2007, Daniel Hazelton wrote: On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: On Sat, 28 Jul 2007, Rene Herman wrote: On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: nobody is arguing that swap prefetch helps in the second cast. Actually, I made a mistake when tracking the thread and reading the code for the patch and started to argue just that. But I have to admit I made a mistake - the patches author has stated (as Rene was kind enough to point out) that swap prefetch can't help when memory is filled. I stand corrected, thaks for speaking up and correcting your position. If you had made the statement before I decided to speak up you would have been correct :) Anyway, I try to always admit when I've made a mistake - its part of my philosophy. (There have been times when I haven't done it, but I'm trying to make that stop entirely) what people are arguing is that there are situations where it helps for the first case. on some machines and version of updatedb the nighly run of updatedb can cause both sets of problems. but the nightly updatedb run is not the only thing that can cause problems Solving the cache filling memory case is difficult. There have been a number of discussions about it. The simplest solution, IMHO, would be to place a (configurable) hard limit on the maximum size any of the kernels caches can grow to. (The only solution that was discussed, however, is a complex beast) limiting the size of the cache is also the wrong thing to do in many situations. it's only right if the cache pushes out other data you care about, if you are trying to do one thing as fast as you can you really do want the system to use all the memory it can for the cache. After thinking about this you are partially correct. There are those sorts of situations where you want the system to use all the memory it can for caches. OTOH, if those situations could be described in some sort of simple heuristic, then a soft-limit that uses those heuristics to determine when to let the cache expand could exploit the benefits of having both a limited and unlimited cache. (And, potentially, if the heuristic has allowed a cache to expand beyond the limit then, when the heuristic no longer shows the oversize cache is no longer necessary it could trigger and automatic reclaim of that memory.) (I'm willing to help write and test code to do this exactly. There is no guarantee that I'll be able to help with more than testing - I don't understand the parts of the code involved all that well) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 19:29:19 Andi Kleen wrote: > > Any faults in that reasoning? > > GNU sort uses a merge sort with temporary files on disk. Not sure > how much it keeps in memory during that, but it's probably less > than 150MB. At some point the dirty limit should kick in and write back the > data of the temporary files; so it's not quite the same as anonymous > memory. But it's not that different given. Yes, this should occur. But how many programs use temporary files like that? >From what I can tell FireFox and OpenOffice both keep all their data in memory, only using a single file for some buffering purposes. When they get pushed out by a memory hog (either short term or long term) it takes several seconds for them to be swapped back in. (I'm on a P4-1.3GHz machine with 1G of ram and rarely run more than four programs (Mail Client, XChat, FireFox and a console window) and I've seen this lag in FireFox when switching to it after starting OOo. I've also seen the same sort of lag when exiting OOo. I'll see about getting some numbers about this) > It would be better to measure than to guess. At least Andrew's measurements > on 128MB actually didn't show updatedb being really that big a problem. I agree. As I've said previously, it isn't updatedb itself which causes the problem. It's the way the VFS cache seems to just expand and expand - to the point of evicting pages to make room for itself. However, I may be wrong about that - I haven't actually tested it for myself, just looked at the numbers and other information that has been posted in this thread. > Perhaps some people have much more files or simply a less efficient > updatedb implementation? Yes, it could be the proliferation of files. It could also be some other sort of problem that is exposing a corner-case in the VFS cache or the MM. I, personally, am of the opinion that it is likely the aforementioned corner case for people reporting the "updatedb" problem. If it is, then swap-prefetch is just papering over the problem. However I do not have the knowledge and understanding of the subsystems involved to be able to do much more than make a (probably wrong) guess. > I guess the people who complain here that loudly really need to supply > some real numbers. I've seen numerous "real numbers" posted about this. As was said earlier in the thread "every time numbers are posted they are claimed to be no good". But hey, nobodies perfect :) Anyway, the discussion seems to be turning to the technical merits of swap-prefetch... Now, a completely different question: During the research (and lots of thinking) I've been doing while this thread has been going on I've often wondered why swap prefetch wasn't already in the kernel. The problem of slow swap-in has long been known, and, given current hardware, the optimal solution would be some sort of data prefetch - similar to what is done to speed up normal disk reads. Swap prefetch looks like it does exactly that. The algo could be argued over and/or improved (to suggest ways to do that I'd have to give it more than a 10 minute look) but it does provide a speed-up. This speed increase will probably be enjoyed more by the home users, but the performance increase could also help on enterprise systems. Now I'll be the first one to admit that there is a trade-off there - it will cause more power to be used because the disk's don't get a chance to spin down (or go through a cycle every time the prefetch system starts) but that could, potentially, be alleviated by having "laptop mode" switch it off. (And no, I'm not claiming that it is perfect - but then, what is when its first merged into the kernel?) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 18:08:44 Mike Galbraith wrote: > On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote: > > On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > > > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > > > So hrm. Are we sure that updatedb is the problem? There are quite a > > > > few heavyweight things which happen in the wee small hours. > > > > > > The balance in _my_ world seems just fine. I don't let any of those > > > system maintenance things run while I'm using the system, and it > > > doesn't bother me if my working set has to be reconstructed after > > > heavy-weight maintenance things are allowed to run. I'm not seeing > > > anything I wouldn't expect to see when running a job the size of > > > updatedb. > > > > > > -Mike > > > > Do you realize you've totally missed the point? > > Did you notice that I didn't make one disparaging remark about the patch > or the concept behind it? Did you notice that I took _my time_ to > test, to actually look at the problem? No, you're too busy running > your mouth to appreciate the efforts of others. If you're done being an ass, take note of the fact that I never even said you were doing that. What I was commenting on was the fact that you (and a lot of the other developers) seem to keep saying "It doesn't happen here, so it doesn't matter!" - ie: If I don't see something happening, it doesn't matter. > > > Do yourself a favor, go dig into the VM source. Read it, understand it > (not terribly easy), _then_ come back and preach to me. I've been trying to do that since the thread started. Note that you snipped where I said (and I'm going to paraphrase myself) "There is another way to fix this, but I don't have the understanding necessary". Now, once more, I'm going to ask: What is so terribly wrong with swap prefetch? Why does it seem that everyone against it says "Its treating a symptom, so it can't go in"? Try coming up with an answer that isn't "I don't see the problem on my $10K system" or similar - try explaining it based on the *technical* merits. Does it cause the processor cache to get thrashed? Does it create locking problems? I stand by my statements, as vitriolic as you and Rene seem to want to get over it. So far in this thread I have not seen one bit of *technical* discussion over the merits, just the bits I've simplified and stated before. > Have a nice day. I am. You being nasty when somebody gets fed up with a line of BS doesn't stop me from having a nice day. Only thing that could make my life any better would be to have the questions I've asked answered, rather than having supposedly intelligent people act like trolls. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 14:16:32 Rene Herman wrote: > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > > Updatedb or another process that uses the FS heavily runs on a users > > 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory > > pressure that causes other applications to be swapped to disk. In the > > morning the user has to wait for the system to swap those applications > > back in. > > > > Questions about it: > > Q) Does swap-prefetch help with this? > > A) [From all reports I've seen (*)] Yes, it does. > > No it does not. If updatedb filled memory to the point of causing swapping > (which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch > hasn't any memory to prefetch into -- updatedb itself doesn't use any > significant memory. Check the attitude at the door then re-read what I actually said: > > Updatedb or another process that uses the FS heavily runs on a users > > 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory > > pressure that causes other applications to be swapped to disk. In the > > morning the user has to wait for the system to swap those applications > > back in. I never said that it was the *program* itself - or *any* specific program (I used "Updatedb" because it has been the big name in the discussion) - doing the filling of memory. I actually said that the problem is that the kernel's caches - VFS and others - will grow *WITHOUT* *LIMIT*, filling all available memory. Swap prefetch on its own will not alleviate *all* of the problem, but it appears to fix enough of it that the problem doesn't seem to bother people anymore. (As I noted later on there are things that can be changes that would also fix things. Those changes, however, are quite tricky and involve changes to the page faulting mechanism, the way the various caches work and a number of other things) In light of the fact that swap prefetch appears to solve the problem for the people that have been vocal about it, and because it is a less intrusive change than the other potential solutions, I'd like to know why all the complaints and arguments against it come down to "Its treating the symptom". I mean it - because I fail to see how it isn't getting at the root of the problem - which is, pretty much, that Swap has classically been and, in the case of most modern systems, still is damned slow. By prefetching those pages that have most recently been evicted the problem of "slow swap" is being directly addressed. You want to know what causes the problem? The current design of the caches. They will extend without much limit, to the point of actually pushing pages to disk so they can grow even more. > Here's swap-prefetch's author saying the same: > > http://lkml.org/lkml/2007/2/9/112 > > | It can't help the updatedb scenario. Updatedb leaves the ram full and > | swap prefetch wants to cost as little as possible so it will never > | move anything out of ram in preference for the pages it wants to swap > | back in. > > Now please finally either understand this, or tell us how we're wrong. > > Rene. I already did. You completely ignored it because I happened to use the magic words "updatedb" and "swap prefetch". Did I ever say it was about "updatedb" in particular? You've got the statement in the part of my post that you quoted. Nope, appears that I used the name as a specific example - and one that has been used previously in the thread. Now drop the damned attitude and start using your brain. Okay? DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: > On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: > > On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > More sophisticated testing is needed - there's something in > > > ext3-tools which will mmap, page in and hold a file for you. > > > > So much for that theory. afaict mmapped, active pagecache is immune to > > updatedb activity. It just sits there while updatedb continues munching > > away at the slab and blockdev pagecache which it instantiated. I assume > > we're never getting the VM into enough trouble to tip it over the > > start-reclaiming-mapped-pages threshold (ie: /proc/sys/vm/swappiness). > > > > Start the updatedb on this 128MB machine with 80MB of mapped pagecache, > > it falls to 55MB fairly soon and then never changes. > > > > So hrm. Are we sure that updatedb is the problem? There are quite a few > > heavyweight things which happen in the wee small hours. > > The balance in _my_ world seems just fine. I don't let any of those > system maintenance things run while I'm using the system, and it doesn't > bother me if my working set has to be reconstructed after heavy-weight > maintenance things are allowed to run. I'm not seeing anything I > wouldn't expect to see when running a job the size of updatedb. > > -Mike Do you realize you've totally missed the point? It isn't about what is fine in the Kernel Developers world, but what is fine in the *USERS* world. There are dozens of big businesses pushing Linux for Enterprise performance. Rather than discussing the merit of those patches - some of which just improve the performance of a specific application by 1 or 2 percent - they get a nod and go into the kernel. But when a group of users that don't represent one of those businesses says "Hey, this helps with problems I see on my system" there is a big discussion and ultimately those patches get rejected. Why? Because they'll give an example using a program that they see causing part of the problem and be told "Use program X - it does things differently and shouldn't cause the problem" or "But what causes the problem to happen? The patch treats a symptom of a larger problem". The fucked up part of that is that the (mass of) kernel developers will see a similar report saying "mySQL has a performance problem because of X, this fixes it" and not blink twice - even if it is "treating the symptom and not the cause". It's this attitude more than anything that caused Con to "retire" - at least that is the impression I got from the interviews he's given. (The exact impression was "I'm sick of the kernel developers doing everything they can to help enterprise users and ignoring the home users") So... The problem: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. Q) Why does it help? A) Because it pro-actively swaps stuff back-in when the memory pressure that caused it to be swapped out is gone. Q) What causes the problem? A) The VFS layer not keeping a limited cache. Instead the VFS will chew through available memory in the name of "increasing performance". Solution(s) to the problem: 1) Limit the amount of memory the pagecache and other VFS caches can consume 2) Implement swap prefetch If I had a (more) complete understanding of how the VFS cache(s) work I'd try to code a patch to do #1 myself. Patches to do #2 already exist and have been shown to work for the users that have tried it. My question is thus, simply: What is the reason that it is argued against?(**) DRH PS: Yes, I realize I've repeated some people from earlier in this thread, but it seems that people have been forgetting the point. (*) I've followed this thread and all of its splinters. The reports that are in them, where the person making the report has a system that has the limited memory needed for the problem to exhibit itself, all show that swap-prefetch helps. (**) No, I won't settle for "Its treating a symptom". The fact is that this isn't a *SYMPTOM* of anything. It treats the cause of the lag the users that have less than (for the sake of argument) 1G of memory are seeing. And no, changing userspace isn't a solution - updatedb may be the program that has been used as an example, but there are others. The proper fix is to change the kernel to either make the situation impossible (limit the VFS and other kernel caches) or make the situation as painless as possible (implement swap prefetch to alleviate the lag of swapping data back in). -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: On Fri, 27 Jul 2007 01:47:49 -0700 Andrew Morton [EMAIL PROTECTED] wrote: More sophisticated testing is needed - there's something in ext3-tools which will mmap, page in and hold a file for you. So much for that theory. afaict mmapped, active pagecache is immune to updatedb activity. It just sits there while updatedb continues munching away at the slab and blockdev pagecache which it instantiated. I assume we're never getting the VM into enough trouble to tip it over the start-reclaiming-mapped-pages threshold (ie: /proc/sys/vm/swappiness). Start the updatedb on this 128MB machine with 80MB of mapped pagecache, it falls to 55MB fairly soon and then never changes. So hrm. Are we sure that updatedb is the problem? There are quite a few heavyweight things which happen in the wee small hours. The balance in _my_ world seems just fine. I don't let any of those system maintenance things run while I'm using the system, and it doesn't bother me if my working set has to be reconstructed after heavy-weight maintenance things are allowed to run. I'm not seeing anything I wouldn't expect to see when running a job the size of updatedb. -Mike Do you realize you've totally missed the point? It isn't about what is fine in the Kernel Developers world, but what is fine in the *USERS* world. There are dozens of big businesses pushing Linux for Enterprise performance. Rather than discussing the merit of those patches - some of which just improve the performance of a specific application by 1 or 2 percent - they get a nod and go into the kernel. But when a group of users that don't represent one of those businesses says Hey, this helps with problems I see on my system there is a big discussion and ultimately those patches get rejected. Why? Because they'll give an example using a program that they see causing part of the problem and be told Use program X - it does things differently and shouldn't cause the problem or But what causes the problem to happen? The patch treats a symptom of a larger problem. The fucked up part of that is that the (mass of) kernel developers will see a similar report saying mySQL has a performance problem because of X, this fixes it and not blink twice - even if it is treating the symptom and not the cause. It's this attitude more than anything that caused Con to retire - at least that is the impression I got from the interviews he's given. (The exact impression was I'm sick of the kernel developers doing everything they can to help enterprise users and ignoring the home users) So... The problem: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. Q) Why does it help? A) Because it pro-actively swaps stuff back-in when the memory pressure that caused it to be swapped out is gone. Q) What causes the problem? A) The VFS layer not keeping a limited cache. Instead the VFS will chew through available memory in the name of increasing performance. Solution(s) to the problem: 1) Limit the amount of memory the pagecache and other VFS caches can consume 2) Implement swap prefetch If I had a (more) complete understanding of how the VFS cache(s) work I'd try to code a patch to do #1 myself. Patches to do #2 already exist and have been shown to work for the users that have tried it. My question is thus, simply: What is the reason that it is argued against?(**) DRH PS: Yes, I realize I've repeated some people from earlier in this thread, but it seems that people have been forgetting the point. (*) I've followed this thread and all of its splinters. The reports that are in them, where the person making the report has a system that has the limited memory needed for the problem to exhibit itself, all show that swap-prefetch helps. (**) No, I won't settle for Its treating a symptom. The fact is that this isn't a *SYMPTOM* of anything. It treats the cause of the lag the users that have less than (for the sake of argument) 1G of memory are seeing. And no, changing userspace isn't a solution - updatedb may be the program that has been used as an example, but there are others. The proper fix is to change the kernel to either make the situation impossible (limit the VFS and other kernel caches) or make the situation as painless as possible (implement swap prefetch to alleviate the lag of swapping data back in). -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 14:16:32 Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. No it does not. If updatedb filled memory to the point of causing swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch hasn't any memory to prefetch into -- updatedb itself doesn't use any significant memory. Check the attitude at the door then re-read what I actually said: Updatedb or another process that uses the FS heavily runs on a users 256MB P3-800 (when it is idle) and the VFS caches grow, causing memory pressure that causes other applications to be swapped to disk. In the morning the user has to wait for the system to swap those applications back in. I never said that it was the *program* itself - or *any* specific program (I used Updatedb because it has been the big name in the discussion) - doing the filling of memory. I actually said that the problem is that the kernel's caches - VFS and others - will grow *WITHOUT* *LIMIT*, filling all available memory. Swap prefetch on its own will not alleviate *all* of the problem, but it appears to fix enough of it that the problem doesn't seem to bother people anymore. (As I noted later on there are things that can be changes that would also fix things. Those changes, however, are quite tricky and involve changes to the page faulting mechanism, the way the various caches work and a number of other things) In light of the fact that swap prefetch appears to solve the problem for the people that have been vocal about it, and because it is a less intrusive change than the other potential solutions, I'd like to know why all the complaints and arguments against it come down to Its treating the symptom. I mean it - because I fail to see how it isn't getting at the root of the problem - which is, pretty much, that Swap has classically been and, in the case of most modern systems, still is damned slow. By prefetching those pages that have most recently been evicted the problem of slow swap is being directly addressed. You want to know what causes the problem? The current design of the caches. They will extend without much limit, to the point of actually pushing pages to disk so they can grow even more. Here's swap-prefetch's author saying the same: http://lkml.org/lkml/2007/2/9/112 | It can't help the updatedb scenario. Updatedb leaves the ram full and | swap prefetch wants to cost as little as possible so it will never | move anything out of ram in preference for the pages it wants to swap | back in. Now please finally either understand this, or tell us how we're wrong. Rene. I already did. You completely ignored it because I happened to use the magic words updatedb and swap prefetch. Did I ever say it was about updatedb in particular? You've got the statement in the part of my post that you quoted. Nope, appears that I used the name as a specific example - and one that has been used previously in the thread. Now drop the damned attitude and start using your brain. Okay? DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 18:08:44 Mike Galbraith wrote: On Fri, 2007-07-27 at 13:45 -0400, Daniel Hazelton wrote: On Friday 27 July 2007 06:25:18 Mike Galbraith wrote: On Fri, 2007-07-27 at 03:00 -0700, Andrew Morton wrote: So hrm. Are we sure that updatedb is the problem? There are quite a few heavyweight things which happen in the wee small hours. The balance in _my_ world seems just fine. I don't let any of those system maintenance things run while I'm using the system, and it doesn't bother me if my working set has to be reconstructed after heavy-weight maintenance things are allowed to run. I'm not seeing anything I wouldn't expect to see when running a job the size of updatedb. -Mike Do you realize you've totally missed the point? Did you notice that I didn't make one disparaging remark about the patch or the concept behind it? Did you notice that I took _my time_ to test, to actually look at the problem? No, you're too busy running your mouth to appreciate the efforts of others. If you're done being an ass, take note of the fact that I never even said you were doing that. What I was commenting on was the fact that you (and a lot of the other developers) seem to keep saying It doesn't happen here, so it doesn't matter! - ie: If I don't see something happening, it doesn't matter. snips load of useless spleen venting Do yourself a favor, go dig into the VM source. Read it, understand it (not terribly easy), _then_ come back and preach to me. I've been trying to do that since the thread started. Note that you snipped where I said (and I'm going to paraphrase myself) There is another way to fix this, but I don't have the understanding necessary. Now, once more, I'm going to ask: What is so terribly wrong with swap prefetch? Why does it seem that everyone against it says Its treating a symptom, so it can't go in? Try coming up with an answer that isn't I don't see the problem on my $10K system or similar - try explaining it based on the *technical* merits. Does it cause the processor cache to get thrashed? Does it create locking problems? I stand by my statements, as vitriolic as you and Rene seem to want to get over it. So far in this thread I have not seen one bit of *technical* discussion over the merits, just the bits I've simplified and stated before. Have a nice day. I am. You being nasty when somebody gets fed up with a line of BS doesn't stop me from having a nice day. Only thing that could make my life any better would be to have the questions I've asked answered, rather than having supposedly intelligent people act like trolls. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Friday 27 July 2007 19:29:19 Andi Kleen wrote: Any faults in that reasoning? GNU sort uses a merge sort with temporary files on disk. Not sure how much it keeps in memory during that, but it's probably less than 150MB. At some point the dirty limit should kick in and write back the data of the temporary files; so it's not quite the same as anonymous memory. But it's not that different given. Yes, this should occur. But how many programs use temporary files like that? From what I can tell FireFox and OpenOffice both keep all their data in memory, only using a single file for some buffering purposes. When they get pushed out by a memory hog (either short term or long term) it takes several seconds for them to be swapped back in. (I'm on a P4-1.3GHz machine with 1G of ram and rarely run more than four programs (Mail Client, XChat, FireFox and a console window) and I've seen this lag in FireFox when switching to it after starting OOo. I've also seen the same sort of lag when exiting OOo. I'll see about getting some numbers about this) It would be better to measure than to guess. At least Andrew's measurements on 128MB actually didn't show updatedb being really that big a problem. I agree. As I've said previously, it isn't updatedb itself which causes the problem. It's the way the VFS cache seems to just expand and expand - to the point of evicting pages to make room for itself. However, I may be wrong about that - I haven't actually tested it for myself, just looked at the numbers and other information that has been posted in this thread. Perhaps some people have much more files or simply a less efficient updatedb implementation? Yes, it could be the proliferation of files. It could also be some other sort of problem that is exposing a corner-case in the VFS cache or the MM. I, personally, am of the opinion that it is likely the aforementioned corner case for people reporting the updatedb problem. If it is, then swap-prefetch is just papering over the problem. However I do not have the knowledge and understanding of the subsystems involved to be able to do much more than make a (probably wrong) guess. I guess the people who complain here that loudly really need to supply some real numbers. I've seen numerous real numbers posted about this. As was said earlier in the thread every time numbers are posted they are claimed to be no good. But hey, nobodies perfect :) Anyway, the discussion seems to be turning to the technical merits of swap-prefetch... Now, a completely different question: During the research (and lots of thinking) I've been doing while this thread has been going on I've often wondered why swap prefetch wasn't already in the kernel. The problem of slow swap-in has long been known, and, given current hardware, the optimal solution would be some sort of data prefetch - similar to what is done to speed up normal disk reads. Swap prefetch looks like it does exactly that. The algo could be argued over and/or improved (to suggest ways to do that I'd have to give it more than a 10 minute look) but it does provide a speed-up. This speed increase will probably be enjoyed more by the home users, but the performance increase could also help on enterprise systems. Now I'll be the first one to admit that there is a trade-off there - it will cause more power to be used because the disk's don't get a chance to spin down (or go through a cycle every time the prefetch system starts) but that could, potentially, be alleviated by having laptop mode switch it off. (And no, I'm not claiming that it is perfect - but then, what is when its first merged into the kernel?) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Pata support for IDE Controller 82801G ICH7 in Linux 2.6.22
On Sunday 22 July 2007 18:03:06 Bartek wrote:
> 2007/7/22, Alan Cox <[EMAIL PROTECTED]>:
> > > > 00:1f.1 0101: 8086:27df (rev 02)
> > >
> > > Ok, this controller is supported.
> > > Did you forgot about CONFIG_PATA_MPIIX=y?
> >
> > MPIIX is for early Intel laptop (pentium era).
> >
> > If the chip is in AHCI mode then CONFIG_AHCI may be what is missing
>
> I made a few tests. First I booted my comp with Ubuntu Live Feisty
> Fawn, checked modules which are loaded, and interesting ones are:
> ata_piix, ata_generic, libata, scsi_mod, sg, sr_mod, sd_mod
> ls /dev/sda* showed:
> /dev/sda{1,2,3,4}.
> So I recompiled the kernel with these options (marking all these
> drivers as a modules, in the previous situation they were modules, as
> well as compiled directly), and tried to boot. Nothing worked. The
> same situation appeared: Waiting for root file system...
> Second, I installed a Debian distribution kernel
> (linux-image-2.6.22-1-686) and booted from it. It used an old IDE
> driver, not PATA. So again no success.
> According to AHCI, my chip is rather not that kind. Ubuntu does not
> load any AHCI modul. In my previous kernel compilations I tried that
> option as well. It did not work.
This sounds like a problem I ran into when I tried to boot a 2.6.21 kernel
using libata with Ubuntu Edgy installed. The init script on the initramfs
failed at the same point - not a problem with the drivers, but a problem with
what the scripts are looking for. I'd suggest looking at the scripts on the
initramfs - its been my experience that they are the culprit and not the
kernel itself.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Pata support for IDE Controller 82801G ICH7 in Linux 2.6.22
On Sunday 22 July 2007 18:03:06 Bartek wrote:
2007/7/22, Alan Cox [EMAIL PROTECTED]:
00:1f.1 0101: 8086:27df (rev 02)
Ok, this controller is supported.
Did you forgot about CONFIG_PATA_MPIIX=y?
MPIIX is for early Intel laptop (pentium era).
If the chip is in AHCI mode then CONFIG_AHCI may be what is missing
I made a few tests. First I booted my comp with Ubuntu Live Feisty
Fawn, checked modules which are loaded, and interesting ones are:
ata_piix, ata_generic, libata, scsi_mod, sg, sr_mod, sd_mod
ls /dev/sda* showed:
/dev/sda{1,2,3,4}.
So I recompiled the kernel with these options (marking all these
drivers as a modules, in the previous situation they were modules, as
well as compiled directly), and tried to boot. Nothing worked. The
same situation appeared: Waiting for root file system...
Second, I installed a Debian distribution kernel
(linux-image-2.6.22-1-686) and booted from it. It used an old IDE
driver, not PATA. So again no success.
According to AHCI, my chip is rather not that kind. Ubuntu does not
load any AHCI modul. In my previous kernel compilations I tried that
option as well. It did not work.
This sounds like a problem I ran into when I tried to boot a 2.6.21 kernel
using libata with Ubuntu Edgy installed. The init script on the initramfs
failed at the same point - not a problem with the drivers, but a problem with
what the scripts are looking for. I'd suggest looking at the scripts on the
initramfs - its been my experience that they are the culprit and not the
kernel itself.
DRH
--
Dialup is like pissing through a pipette. Slow and excruciatingly painful.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
On Saturday 30 June 2007 08:02:16 Joerg Schilling wrote: > Willy Tarreau <[EMAIL PROTECTED]> wrote: > > Jörg, > > > > On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote: > > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: > > > > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > > By the way, your mailer seems to be sometimes omitting > > > > > > In-Reply-To: and References: headers, which RFC2822 says you > > > > > > SHOULD include in replies. > > > > > > > > > > Sending such accusation without knowing the reason is not polite. > > > > > > > > It's not an accusation -- it's merely an observation. You may not > > > > have noticed that your mailer was misbehaving; now you _do_ know, and > > > > if you care about RFC compliance you might want to fix it. You're not > > > > _obliged_ to fix it, of course. I just thought you'd like to know. > > > > > > Well there you are: my mailer is definitely NOT missbehaving. > > > Please do not repeat similar accusations when not knowing the reason. > > > > Attacking people who suggest to you they *may* have noticed an anomaly is > > not polite at all, childish at best, and counter-productive in any case. > > Well, then please write this to the person who did attack me for no reason! > > What he did is typical trollish behavior, as he tried to turn a technical > based discussion into a flame war for no reason. > > Jörg Jörg - I see no attack. What I do see is a quite friendly notification that your mail program appears to be omitting those headers in certain mails and that such action is in violation of a published standard. Your response was inflammatory, rude and very trollish. And when the person calmly restated himself and the reason he made the original comment you again responded in an extremely unpleasant manner. When notified that your behavior was incorrect you pointed fingers and yelled "He started it!" - something that *CHILDREN* do. Since it appears that you act like a child its time to add you to my killfile again. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Linux Kernel include files
On Saturday 30 June 2007 08:02:16 Joerg Schilling wrote: Willy Tarreau [EMAIL PROTECTED] wrote: Jörg, On Thu, Jun 28, 2007 at 12:39:57PM +0200, Joerg Schilling wrote: David Woodhouse [EMAIL PROTECTED] wrote: On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote: David Woodhouse [EMAIL PROTECTED] wrote: By the way, your mailer seems to be sometimes omitting In-Reply-To: and References: headers, which RFC2822 says you SHOULD include in replies. Sending such accusation without knowing the reason is not polite. It's not an accusation -- it's merely an observation. You may not have noticed that your mailer was misbehaving; now you _do_ know, and if you care about RFC compliance you might want to fix it. You're not _obliged_ to fix it, of course. I just thought you'd like to know. Well there you are: my mailer is definitely NOT missbehaving. Please do not repeat similar accusations when not knowing the reason. Attacking people who suggest to you they *may* have noticed an anomaly is not polite at all, childish at best, and counter-productive in any case. Well, then please write this to the person who did attack me for no reason! What he did is typical trollish behavior, as he tried to turn a technical based discussion into a flame war for no reason. Jörg Jörg - I see no attack. What I do see is a quite friendly notification that your mail program appears to be omitting those headers in certain mails and that such action is in violation of a published standard. Your response was inflammatory, rude and very trollish. And when the person calmly restated himself and the reason he made the original comment you again responded in an extremely unpleasant manner. When notified that your behavior was incorrect you pointed fingers and yelled He started it! - something that *CHILDREN* do. Since it appears that you act like a child its time to add you to my killfile again. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
