* [GIT PATCH] more Driver core patches for 2.6.19 @ 2006-12-13 19:52 Greg KH [not found] ` <1166039585152-git-send-email-greg@kroah.com> 2006-12-13 20:12 ` [GIT PATCH] more Driver core patches for 2.6.19 Linus Torvalds 0 siblings, 2 replies; 239+ messages in thread From: Greg KH @ 2006-12-13 19:52 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel Here are some more driver core patches for 2.6.19 They contain: - minor driver core bugfixes and memory savings - debugfs bugfixes and inotify support added. - userspace io driver interface added. This allows the ability to write userspace drivers for some types of hardware much easier than before, going through a simple interface to get accesses to irqs and memory regions. A small kernel portion is still needed to handle the irq properly, but that is it. - other minor cleanups and fixes. All of these patches have been in the -mm tree for a while. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h Documentation/DocBook/kernel-api.tmpl | 4 + Documentation/DocBook/uio-howto.tmpl | 434 +++++++++++++++++++++++ drivers/Kconfig | 1 + drivers/Makefile | 1 + drivers/base/class.c | 2 + drivers/base/platform.c | 4 +- drivers/uio/Kconfig | 39 ++ drivers/uio/Makefile | 4 + drivers/uio/uio.c | 618 +++++++++++++++++++++++++++++++++ drivers/uio/uio_dummy.c | 174 +++++++++ drivers/uio/uio_events.c | 119 +++++++ drivers/uio/uio_irq.c | 86 +++++ drivers/uio/uio_parport.c | 84 +++++ fs/debugfs/inode.c | 39 ++- include/linux/platform_device.h | 2 +- include/linux/uio_driver.h | 71 ++++ kernel/module.c | 25 ++ kernel/power/Kconfig | 9 +- 18 files changed, 1700 insertions(+), 16 deletions(-) create mode 100644 Documentation/DocBook/uio-howto.tmpl create mode 100644 drivers/uio/Kconfig create mode 100644 drivers/uio/Makefile create mode 100644 drivers/uio/uio.c create mode 100644 drivers/uio/uio_dummy.c create mode 100644 drivers/uio/uio_events.c create mode 100644 drivers/uio/uio_irq.c create mode 100644 drivers/uio/uio_parport.c create mode 100644 include/linux/uio_driver.h --------------- Akinobu Mita (1): driver core: delete virtual directory on class_unregister() Andrew Morton (1): Driver core: "platform_driver_probe() can save codespace": save codespace David Brownell (1): Driver core: deprecate PM_LEGACY, default it to N Hans J. Koch (4): UIO: Add the User IO core code UIO: Documentation UIO: dummy test module for the uio core UIO: irq test module for the uio core Kay Sievers (1): Driver core: show "initstate" of module Mathieu Desnoyers (5): DebugFS : inotify create/mkdir support DebugFS : coding style fixes DebugFS : file/directory creation error handling DebugFS : more file/directory creation error handling DebugFS : file/directory removal fix Scott Wood (1): Driver core: Make platform_device_add_data accept a const pointer ^ permalink raw reply [flat|nested] 239+ messages in thread
[parent not found: <1166039585152-git-send-email-greg@kroah.com>]
[parent not found: <11660395913232-git-send-email-greg@kroah.com>]
[parent not found: <11660395951158-git-send-email-greg@kroah.com>]
[parent not found: <11660395998-git-send-email-greg@kroah.com>]
* [PATCH 5/14] Driver core: show "initstate" of module [not found] ` <11660395998-git-send-email-greg@kroah.com> @ 2006-12-13 19:52 ` Greg KH 2006-12-13 19:52 ` [PATCH 6/14] driver core: delete virtual directory on class_unregister() Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:52 UTC (permalink / raw) To: linux-kernel; +Cc: Kay Sievers, Greg Kroah-Hartman From: Kay Sievers <kay.sievers@vrfy.org> Show the initialization state(live, coming, going) of the module: $ cat /sys/module/usbcore/initstate live Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- kernel/module.c | 25 +++++++++++++++++++++++++ 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/kernel/module.c b/kernel/module.c index d9eae45..b565eae 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -824,9 +824,34 @@ static inline void module_unload_init(struct module *mod) } #endif /* CONFIG_MODULE_UNLOAD */ +static ssize_t show_initstate(struct module_attribute *mattr, + struct module *mod, char *buffer) +{ + const char *state = "unknown"; + + switch (mod->state) { + case MODULE_STATE_LIVE: + state = "live"; + break; + case MODULE_STATE_COMING: + state = "coming"; + break; + case MODULE_STATE_GOING: + state = "going"; + break; + } + return sprintf(buffer, "%s\n", state); +} + +static struct module_attribute initstate = { + .attr = { .name = "initstate", .mode = 0444, .owner = THIS_MODULE }, + .show = show_initstate, +}; + static struct module_attribute *modinfo_attrs[] = { &modinfo_version, &modinfo_srcversion, + &initstate, #ifdef CONFIG_MODULE_UNLOAD &refcnt, #endif -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 6/14] driver core: delete virtual directory on class_unregister() 2006-12-13 19:52 ` [PATCH 5/14] Driver core: show "initstate" of module Greg KH @ 2006-12-13 19:52 ` Greg KH 2006-12-13 19:52 ` [PATCH 7/14] DebugFS : inotify create/mkdir support Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:52 UTC (permalink / raw) To: linux-kernel; +Cc: Akinobu Mita, Greg Kroah-Hartman From: Akinobu Mita <akinobu.mita@gmail.com> Class virtual directory is created as the need arises. But it is not deleted when the class is unregistered. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/base/class.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/base/class.c b/drivers/base/class.c index f098881..8bf2ca2 100644 --- a/drivers/base/class.c +++ b/drivers/base/class.c @@ -163,6 +163,8 @@ int class_register(struct class * cls) void class_unregister(struct class * cls) { pr_debug("device class '%s': unregistering\n", cls->name); + if (cls->virtual_dir) + kobject_unregister(cls->virtual_dir); remove_class_attrs(cls); subsystem_unregister(&cls->subsys); } -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 7/14] DebugFS : inotify create/mkdir support 2006-12-13 19:52 ` [PATCH 6/14] driver core: delete virtual directory on class_unregister() Greg KH @ 2006-12-13 19:52 ` Greg KH 2006-12-13 19:52 ` [PATCH 8/14] DebugFS : coding style fixes Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:52 UTC (permalink / raw) To: linux-kernel; +Cc: Mathieu Desnoyers, Mathieu Desnoyers, Greg Kroah-Hartman From: Mathieu Desnoyers <compudj@krystal.dyndns.org> Add inotify create and mkdir events to DebugFS. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/inode.c | 12 ++++++++++-- 1 files changed, 10 insertions(+), 2 deletions(-) diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index 137d76c..020da4c 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -24,6 +24,7 @@ #include <linux/kobject.h> #include <linux/namei.h> #include <linux/debugfs.h> +#include <linux/fsnotify.h> #define DEBUGFS_MAGIC 0x64626720 @@ -87,15 +88,22 @@ static int debugfs_mkdir(struct inode *dir, struct dentry *dentry, int mode) mode = (mode & (S_IRWXUGO | S_ISVTX)) | S_IFDIR; res = debugfs_mknod(dir, dentry, mode, 0); - if (!res) + if (!res) { inc_nlink(dir); + fsnotify_mkdir(dir, dentry); + } return res; } static int debugfs_create(struct inode *dir, struct dentry *dentry, int mode) { + int res; + mode = (mode & S_IALLUGO) | S_IFREG; - return debugfs_mknod(dir, dentry, mode, 0); + res = debugfs_mknod(dir, dentry, mode, 0); + if (!res) + fsnotify_create(dir, dentry); + return res; } static inline int debugfs_positive(struct dentry *dentry) -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 8/14] DebugFS : coding style fixes 2006-12-13 19:52 ` [PATCH 7/14] DebugFS : inotify create/mkdir support Greg KH @ 2006-12-13 19:52 ` Greg KH 2006-12-13 19:53 ` [PATCH 9/14] DebugFS : file/directory creation error handling Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:52 UTC (permalink / raw) To: linux-kernel; +Cc: Mathieu Desnoyers, Mathieu Desnoyers, Greg Kroah-Hartman From: Mathieu Desnoyers <compudj@krystal.dyndns.org> Minor coding style fixes along the way : 80 cols and a white space. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/inode.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index 020da4c..05d1a9c 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -55,7 +55,8 @@ static struct inode *debugfs_get_inode(struct super_block *sb, int mode, dev_t d inode->i_op = &simple_dir_inode_operations; inode->i_fop = &simple_dir_operations; - /* directory inodes start off with i_nlink == 2 (for "." entry) */ + /* directory inodes start off with i_nlink == 2 + * (for "." entry) */ inc_nlink(inode); break; } @@ -143,7 +144,7 @@ static int debugfs_create_by_name(const char *name, mode_t mode, * block. A pointer to that is in the struct vfsmount that we * have around. */ - if (!parent ) { + if (!parent) { if (debugfs_mount && debugfs_mount->mnt_sb) { parent = debugfs_mount->mnt_sb->s_root; } -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 9/14] DebugFS : file/directory creation error handling 2006-12-13 19:52 ` [PATCH 8/14] DebugFS : coding style fixes Greg KH @ 2006-12-13 19:53 ` Greg KH 2006-12-13 19:53 ` [PATCH 10/14] DebugFS : more " Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: Mathieu Desnoyers, Mathieu Desnoyers, Greg Kroah-Hartman From: Mathieu Desnoyers <compudj@krystal.dyndns.org> Fix error handling of file and directory creation in DebugFS. The error path should release the file system because no _remove will be called for this erroneous creation. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/inode.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index 05d1a9c..d6c5fb5 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -206,13 +206,15 @@ struct dentry *debugfs_create_file(const char *name, mode_t mode, pr_debug("debugfs: creating file '%s'\n",name); - error = simple_pin_fs(&debug_fs_type, &debugfs_mount, &debugfs_mount_count); + error = simple_pin_fs(&debug_fs_type, &debugfs_mount, + &debugfs_mount_count); if (error) goto exit; error = debugfs_create_by_name(name, mode, parent, &dentry); if (error) { dentry = NULL; + simple_release_fs(&debugfs_mount, &debugfs_mount_count); goto exit; } -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 10/14] DebugFS : more file/directory creation error handling 2006-12-13 19:53 ` [PATCH 9/14] DebugFS : file/directory creation error handling Greg KH @ 2006-12-13 19:53 ` Greg KH 2006-12-13 19:53 ` [PATCH 11/14] DebugFS : file/directory removal fix Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: Mathieu Desnoyers, Mathieu Desnoyers, Greg Kroah-Hartman From: Mathieu Desnoyers <compudj@krystal.dyndns.org> Correct dentry count to handle creation errors. This patch puts a dput at the file creation instead of the file removal : lookup_one_len already returns a dentry with reference count of 1. Then, the dget() in simple_mknod increments it when the dentry is associated with a file. In a scenario where simple_create or simple_mkdir returns an error, this would lead to an unwanted increment of the reference counter, therefore making file removal impossible. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/inode.c | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index d6c5fb5..554f4a9 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -162,6 +162,7 @@ static int debugfs_create_by_name(const char *name, mode_t mode, error = debugfs_mkdir(parent->d_inode, *dentry, mode); else error = debugfs_create(parent->d_inode, *dentry, mode); + dput(*dentry); } else error = PTR_ERR(*dentry); mutex_unlock(&parent->d_inode->i_mutex); @@ -273,6 +274,7 @@ EXPORT_SYMBOL_GPL(debugfs_create_dir); void debugfs_remove(struct dentry *dentry) { struct dentry *parent; + int ret = 0; if (!dentry) return; @@ -284,11 +286,15 @@ void debugfs_remove(struct dentry *dentry) mutex_lock(&parent->d_inode->i_mutex); if (debugfs_positive(dentry)) { if (dentry->d_inode) { - if (S_ISDIR(dentry->d_inode->i_mode)) - simple_rmdir(parent->d_inode, dentry); - else + if (S_ISDIR(dentry->d_inode->i_mode)) { + ret = simple_rmdir(parent->d_inode, dentry); + if (ret) + printk(KERN_ERR + "DebugFS rmdir on %s failed : " + "directory not empty.\n", + dentry->d_name.name); + } else simple_unlink(parent->d_inode, dentry); - dput(dentry); } } mutex_unlock(&parent->d_inode->i_mutex); -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 11/14] DebugFS : file/directory removal fix 2006-12-13 19:53 ` [PATCH 10/14] DebugFS : more " Greg KH @ 2006-12-13 19:53 ` Greg KH 2006-12-13 19:53 ` [PATCH 12/14] Driver core: "platform_driver_probe() can save codespace": save codespace Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: Mathieu Desnoyers, Mathieu Desnoyers, Greg Kroah-Hartman From: Mathieu Desnoyers <compudj@krystal.dyndns.org> Fix file and directory removal in debugfs. Add inotify support for file removal. The following scenario : create dir a create dir a/b cd a/b (some process goes in cwd a/b) rmdir a/b rmdir a fails due to the fact that "a" appears to be non empty. It is because the "b" dentry is not deleted from "a" and still in use. The same problem happens if "b" is a file. d_delete is nice enough to know when it needs to unhash and free the dentry if nothing else is using it or, if someone is using it, to remove it from the hash queues and wait for it to be deleted when it has no users. The nice side-effect of this fix is that it calls the file removal notification. Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- fs/debugfs/inode.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c index 554f4a9..c692487 100644 --- a/fs/debugfs/inode.c +++ b/fs/debugfs/inode.c @@ -286,6 +286,7 @@ void debugfs_remove(struct dentry *dentry) mutex_lock(&parent->d_inode->i_mutex); if (debugfs_positive(dentry)) { if (dentry->d_inode) { + dget(dentry); if (S_ISDIR(dentry->d_inode->i_mode)) { ret = simple_rmdir(parent->d_inode, dentry); if (ret) @@ -295,6 +296,9 @@ void debugfs_remove(struct dentry *dentry) dentry->d_name.name); } else simple_unlink(parent->d_inode, dentry); + if (!ret) + d_delete(dentry); + dput(dentry); } } mutex_unlock(&parent->d_inode->i_mutex); -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 12/14] Driver core: "platform_driver_probe() can save codespace": save codespace 2006-12-13 19:53 ` [PATCH 11/14] DebugFS : file/directory removal fix Greg KH @ 2006-12-13 19:53 ` Greg KH 2006-12-13 19:53 ` [PATCH 13/14] Driver core: Make platform_device_add_data accept a const pointer Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: Andrew Morton, Greg Kroah-Hartman From: Andrew Morton <akpm@osdl.org> This function can be __init Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/base/platform.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index d1df4a0..0338289 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -473,7 +473,7 @@ EXPORT_SYMBOL_GPL(platform_driver_unregister); * Returns zero if the driver registered and bound to a device, else returns * a negative error code and with the driver not registered. */ -int platform_driver_probe(struct platform_driver *drv, +int __init_or_module platform_driver_probe(struct platform_driver *drv, int (*probe)(struct platform_device *)) { int retval, code; -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 13/14] Driver core: Make platform_device_add_data accept a const pointer 2006-12-13 19:53 ` [PATCH 12/14] Driver core: "platform_driver_probe() can save codespace": save codespace Greg KH @ 2006-12-13 19:53 ` Greg KH 2006-12-13 19:53 ` [PATCH 14/14] Driver core: deprecate PM_LEGACY, default it to N Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: Scott Wood, Andrew Morton, Greg Kroah-Hartman From: Scott Wood <scottwood@freescale.com> platform_device_add_data() makes a copy of the data that is given to it, and thus the parameter can be const. This removes a warning when data from get_property() on powerpc is handed to platform_device_add_data(), as get_property() returns a const pointer. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/base/platform.c | 2 +- include/linux/platform_device.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 0338289..f9c903b 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -212,7 +212,7 @@ EXPORT_SYMBOL_GPL(platform_device_add_resources); * pointer. The memory associated with the platform data will be freed * when the platform device is released. */ -int platform_device_add_data(struct platform_device *pdev, void *data, size_t size) +int platform_device_add_data(struct platform_device *pdev, const void *data, size_t size) { void *d; diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index 20f47b8..8bbd459 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -39,7 +39,7 @@ extern struct platform_device *platform_device_register_simple(char *, unsigned extern struct platform_device *platform_device_alloc(const char *name, unsigned int id); extern int platform_device_add_resources(struct platform_device *pdev, struct resource *res, unsigned int num); -extern int platform_device_add_data(struct platform_device *pdev, void *data, size_t size); +extern int platform_device_add_data(struct platform_device *pdev, const void *data, size_t size); extern int platform_device_add(struct platform_device *pdev); extern void platform_device_del(struct platform_device *pdev); extern void platform_device_put(struct platform_device *pdev); -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* [PATCH 14/14] Driver core: deprecate PM_LEGACY, default it to N 2006-12-13 19:53 ` [PATCH 13/14] Driver core: Make platform_device_add_data accept a const pointer Greg KH @ 2006-12-13 19:53 ` Greg KH 0 siblings, 0 replies; 239+ messages in thread From: Greg KH @ 2006-12-13 19:53 UTC (permalink / raw) To: linux-kernel; +Cc: David Brownell, David Brownell, Greg Kroah-Hartman From: David Brownell <david-b@pacbell.net> Deprecate the old "legacy" PM API, and more importantly default it to "n". Virtually nothing in-tree uses it any more. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- kernel/power/Kconfig | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig index 710ed08..ed29622 100644 --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -20,13 +20,14 @@ config PM sending the processor to sleep and saving power. config PM_LEGACY - bool "Legacy Power Management API" + bool "Legacy Power Management API (DEPRECATED)" depends on PM - default y + default n ---help--- - Support for pm_register() and friends. + Support for pm_register() and friends. This old API is obsoleted + by the driver model. - If unsure, say Y. + If unsure, say N. config PM_DEBUG bool "Power Management Debug Support" -- 1.4.4.2 ^ permalink raw reply related [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 19:52 [GIT PATCH] more Driver core patches for 2.6.19 Greg KH [not found] ` <1166039585152-git-send-email-greg@kroah.com> @ 2006-12-13 20:12 ` Linus Torvalds 2006-12-13 20:31 ` Greg KH ` (2 more replies) 1 sibling, 3 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 20:12 UTC (permalink / raw) To: Greg KH; +Cc: Andrew Morton, linux-kernel On Wed, 13 Dec 2006, Greg KH wrote: > > - userspace io driver interface added. This allows the ability > to write userspace drivers for some types of hardware much > easier than before, going through a simple interface to get > accesses to irqs and memory regions. A small kernel portion > is still needed to handle the irq properly, but that is it. Ok, what kind of ass-hat idiotic thing is this? irqreturn_t uio_irq_handler(int irq, void *dev_id) { return IRQ_HANDLED; } exactly what is the point here? No way will I pull this kind of crap. You just seem to have guaranteed a dead machine if the irq is level-triggered, since it will keep on happening forever. Please remove. YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT! It's really that easy. The irq handler has to be _entirely_ in kernel space. No user-space ass-hattery here. And I don't care one whit if it happens to work on parport with an old legacy ISA interrupt that is edge-triggered. That's not even the interesting case. Never will be. NAK NAK NAK NAK. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:12 ` [GIT PATCH] more Driver core patches for 2.6.19 Linus Torvalds @ 2006-12-13 20:31 ` Greg KH 2006-12-13 20:58 ` Linus Torvalds 2006-12-13 20:38 ` Michael K. Edwards 2006-12-13 21:14 ` Benjamin Herrenschmidt 2 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 20:31 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, tglx On Wed, Dec 13, 2006 at 12:12:04PM -0800, Linus Torvalds wrote: > > > On Wed, 13 Dec 2006, Greg KH wrote: > > > > - userspace io driver interface added. This allows the ability > > to write userspace drivers for some types of hardware much > > easier than before, going through a simple interface to get > > accesses to irqs and memory regions. A small kernel portion > > is still needed to handle the irq properly, but that is it. > > Ok, what kind of ass-hat idiotic thing is this? > > irqreturn_t uio_irq_handler(int irq, void *dev_id) > { > return IRQ_HANDLED; > } > > exactly what is the point here? No way will I pull this kind of crap. You > just seem to have guaranteed a dead machine if the irq is level-triggered, > since it will keep on happening forever. It's a stupid test module for the uio core for isa devices. It's not the main code, or core. > Please remove. > > YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT! I agree, that's why this code doesn't let userspace sort it out. You have to have a kernel driver to handle the irq. > It's really that easy. The irq handler has to be _entirely_ in kernel > space. No user-space ass-hattery here. Agreed. > And I don't care one whit if it happens to work on parport with an old > legacy ISA interrupt that is edge-triggered. That's not even the > interesting case. Never will be. I agree. But that's all that this test module did. It handled an isa interrupt that was edge triggered. > NAK NAK NAK NAK. Ok, I can pull this example module out if you want, but people seem to want examples these days. If I do that, any objection to the rest? thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:31 ` Greg KH @ 2006-12-13 20:58 ` Linus Torvalds 2006-12-13 21:08 ` Linus Torvalds ` (4 more replies) 0 siblings, 5 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 20:58 UTC (permalink / raw) To: Greg KH; +Cc: Andrew Morton, linux-kernel, tglx On Wed, 13 Dec 2006, Greg KH wrote: > > It's a stupid test module for the uio core for isa devices. It's not > the main code, or core. Doesn't matter. IT IS SO FUNDAMENTALLY AND HORRIBLY WRONG THAT I REFUSE TO HAVE IT IN MY TREE. As an "example", the _only_ thing it can possibly ever do is to just confuse people - in other words, it's an _anti_example, not a real one. > Ok, I can pull this example module out if you want, but people seem to > want examples these days. If I do that, any objection to the rest? I'm really not convinced about the user-mode thing unless somebody can show me a good reason for it. Not just some "wouldn't it be nice" kind of thing. A real, honest-to-goodness reason that we actually _want_ to see used. No features just for features sake. So please push the tree without this userspace IO driver at all. And if you actually have a real user, not just an example, that is worthy and shows why such a driver in user space is actually a good thing, _then_ we can push that. In other words, I'd like to see code that uses this that is actually _better_ than an in-kernel driver in some way. For USB, the user-mode thing made sense. You have tons of random devices, and the abstraction level is higher to begin with. Quite frankly, I simply don't even see the same being true for something like this. Btw: there's one driver we _know_ we want to support in user space, and that's the X kind of direct-rendering thing. So if you can show that this driver infrastructure actually makes sense as a replacement for the DRI layer, then _that_ would be a hell of a convincing argument. There may be others. Feel free to fill in the blank: ________. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:58 ` Linus Torvalds @ 2006-12-13 21:08 ` Linus Torvalds 2006-12-13 21:15 ` Arjan van de Ven 2006-12-13 21:36 ` Thomas Gleixner ` (3 subsequent siblings) 4 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 21:08 UTC (permalink / raw) To: Greg KH; +Cc: Andrew Morton, linux-kernel, tglx On Wed, 13 Dec 2006, Linus Torvalds wrote: > > Btw: there's one driver we _know_ we want to support in user space, and > that's the X kind of direct-rendering thing. So if you can show that this > driver infrastructure actually makes sense as a replacement for the DRI > layer, then _that_ would be a hell of a convincing argument. Btw, the other side of this argument is that if a user-space driver infrastructure can _not_ help the DRI kind of situation, then it's largely by definition not interesting. Merging something like that would just mean that we end up with multiple _different_ user-space helper infrastructure shells, which sounds distinctly unpalatable. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:08 ` Linus Torvalds @ 2006-12-13 21:15 ` Arjan van de Ven 2006-12-14 9:30 ` Muli Ben-Yehuda 0 siblings, 1 reply; 239+ messages in thread From: Arjan van de Ven @ 2006-12-13 21:15 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel, tglx On Wed, 2006-12-13 at 13:08 -0800, Linus Torvalds wrote: > > On Wed, 13 Dec 2006, Linus Torvalds wrote: > > > > Btw: there's one driver we _know_ we want to support in user space, and > > that's the X kind of direct-rendering thing. So if you can show that this > > driver infrastructure actually makes sense as a replacement for the DRI > > layer, then _that_ would be a hell of a convincing argument. > > Btw, the other side of this argument is that if a user-space driver > infrastructure can _not_ help the DRI kind of situation, then it's largely with DRI you have the case where "something" needs to do security validation of the commands that are sent to the card. (to avoid a non-privileged user to DMA all over your memory) That and a tiny bit of resource management is the bulk of the kernel DRM code... and I don't think userspace can do it fundamentally better. Sure you could pipe things to a root daemon instead of doing a system call. But I don't see that being superior. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:15 ` Arjan van de Ven @ 2006-12-14 9:30 ` Muli Ben-Yehuda 2006-12-14 10:13 ` Hans-Jürgen Koch 0 siblings, 1 reply; 239+ messages in thread From: Muli Ben-Yehuda @ 2006-12-14 9:30 UTC (permalink / raw) To: Arjan van de Ven Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel, tglx On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote: > with DRI you have the case where "something" needs to do security > validation of the commands that are sent to the card. (to avoid a > non-privileged user to DMA all over your memory) We also have the interesting case where your card is behind an isolation-capable IOMMU, so if you let userspace program it, you need a userspace-accessible DMA-API for IOMMU mappings (or to pre-map everything in the IOMMU, which loses on some of the benefits of isolation-capable IOMMUs (i.e., only map what you need to use right now)). Cheers, Muli ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:30 ` Muli Ben-Yehuda @ 2006-12-14 10:13 ` Hans-Jürgen Koch 0 siblings, 0 replies; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 10:13 UTC (permalink / raw) To: linux-kernel Am Donnerstag, 14. Dezember 2006 10:30 schrieb Muli Ben-Yehuda: > On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote: > > > with DRI you have the case where "something" needs to do security > > validation of the commands that are sent to the card. (to avoid a > > non-privileged user to DMA all over your memory) > > We also have the interesting case where your card is behind an > isolation-capable IOMMU, so if you let userspace program it, you need > a userspace-accessible DMA-API for IOMMU mappings (or to pre-map > everything in the IOMMU, which loses on some of the benefits of > isolation-capable IOMMUs (i.e., only map what you need to use right > now)). Userspace IO (UIO) was never intended to replace all kinds of possible drivers. We wanted to address the situation where a manufacturer of industrial I/O cards wants to do a large part of his driver in userspace to simplify his development process. That's all. Most of these I/O cards have registers or dual ported RAM that can be mapped to userspace. This is possible with a standard kernel and is done every day. Problem is that you can't handle interrupts. UIO simply adds this capability and offers a standardized interface. The code Greg added to his tree can do this for most hardware found on industrial IO boards. That's all we wanted to achieve for now. If somebody wants to support more sophisticated things, suggestions are welcome. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:58 ` Linus Torvalds 2006-12-13 21:08 ` Linus Torvalds @ 2006-12-13 21:36 ` Thomas Gleixner 2006-12-13 21:46 ` Benjamin Herrenschmidt ` (2 subsequent siblings) 4 siblings, 0 replies; 239+ messages in thread From: Thomas Gleixner @ 2006-12-13 21:36 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel On Wed, 2006-12-13 at 12:58 -0800, Linus Torvalds wrote: > In other words, I'd like to see code that uses this that is actually > _better_ than an in-kernel driver in some way. > > For USB, the user-mode thing made sense. You have tons of random devices, > and the abstraction level is higher to begin with. Quite frankly, I simply > don't even see the same being true for something like this. We started to work on this for industrial I/O devices. Many of them are dual port memory based, others are dedicated chips for motion control or field busses. The design requires to have an in kernel stub driver with interrupt handler which is capable to handle shared interrupts. User space _cannot_ override an irq_disable(), it just has access to the chip registers of the device, which is possible right now as well. The risk, that such a driver stalls the kernel is exactly the same as the risk you have with any other badly written driver. This is a real world example of such a drivers interrupt handler: /* * The chip specific portion of the interrupt handler. The framework code * takes care of userspace notification when we return IRQ_HANDLED */ static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg) { /* Check, if this interrupt is originated from the SERCOS chip */ if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK)) return IRQ_NONE; /* Acknowledge the chip interrupts */ sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1); sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2); return IRQ_HANDLED; } With a full kernel driver we need: 1. Interrupt handler check interrupt acknowledge interrupt copy data from/to chip into a kernel buffer wakeup user space task 2. read data from driver, which goes through copy to user 3. do calculations 4. write data to driver, which goes through copy from user After changing the driver concept we have only: 1. Interrupt handler check interrupt acknowledge interrupt wakeup user space task 2. User space task handles the mmaped chip directly The change gave a serious performance gain in the range of 20% after the application was optimized for dealing with the chip directly. There are tons of such exotic hardware devices out there, which now have either a closed source driver or an out of tree patch with an horrible amount of individual ioctl functions to get to the same point with less performance. > Btw: there's one driver we _know_ we want to support in user space, and > that's the X kind of direct-rendering thing. So if you can show that this > driver infrastructure actually makes sense as a replacement for the DRI > layer, then _that_ would be a hell of a convincing argument. I did not look closely into that, but I think that it is a valid usage candidate. The interface of graphic cards is user space mappable and it probably needs some interrupt handling + notification mechanism as well as the devices mentioned above. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:58 ` Linus Torvalds 2006-12-13 21:08 ` Linus Torvalds 2006-12-13 21:36 ` Thomas Gleixner @ 2006-12-13 21:46 ` Benjamin Herrenschmidt 2006-12-13 23:40 ` Greg KH 2006-12-14 8:49 ` Duncan Sands 4 siblings, 0 replies; 239+ messages in thread From: Benjamin Herrenschmidt @ 2006-12-13 21:46 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel, tglx > Btw: there's one driver we _know_ we want to support in user space, and > that's the X kind of direct-rendering thing. So if you can show that this > driver infrastructure actually makes sense as a replacement for the DRI > layer, then _that_ would be a hell of a convincing argument. And even X is trying to move away from that at least partially... With the DRI driver handling IRQs and processing command buffers... except for cards with multiple hardware contexts, but then, we are in a case similar to Infiniband where the HW is -designed- to have specific areas mapped into user space, and there is still a kernel driver to arbitrate, decide who gets what, establish those mappings, etc... Thus X isn't even a good example :-) Ben. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:58 ` Linus Torvalds ` (2 preceding siblings ...) 2006-12-13 21:46 ` Benjamin Herrenschmidt @ 2006-12-13 23:40 ` Greg KH 2006-12-14 8:49 ` Duncan Sands 4 siblings, 0 replies; 239+ messages in thread From: Greg KH @ 2006-12-13 23:40 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andrew Morton, linux-kernel, tglx On Wed, Dec 13, 2006 at 12:58:24PM -0800, Linus Torvalds wrote: > I'm really not convinced about the user-mode thing unless somebody can > show me a good reason for it. Not just some "wouldn't it be nice" kind of > thing. A real, honest-to-goodness reason that we actually _want_ to see > used. > > No features just for features sake. Ok, Thomas just showed at least one example of where this interface is a big advantage over the all-in-kernel model. I'll work with him and try to dig up other real examples before submitting this code again. In the mean time, I'll leave it in my tree and it will get some more exposure in the -mm releases. > So please push the tree without this userspace IO driver at all. Done. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ It contains the changes listed below. thanks, greg k-h drivers/base/class.c | 2 ++ drivers/base/platform.c | 4 ++-- fs/debugfs/inode.c | 39 ++++++++++++++++++++++++++++++--------- include/linux/platform_device.h | 2 +- kernel/module.c | 25 +++++++++++++++++++++++++ kernel/power/Kconfig | 9 +++++---- 6 files changed, 65 insertions(+), 16 deletions(-) --------------- Akinobu Mita (1): driver core: delete virtual directory on class_unregister() Andrew Morton (1): Driver core: "platform_driver_probe() can save codespace": save codespace David Brownell (1): Driver core: deprecate PM_LEGACY, default it to N Kay Sievers (1): Driver core: show "initstate" of module Mathieu Desnoyers (5): DebugFS : inotify create/mkdir support DebugFS : coding style fixes DebugFS : file/directory creation error handling DebugFS : more file/directory creation error handling DebugFS : file/directory removal fix Scott Wood (1): Driver core: Make platform_device_add_data accept a const pointer ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:58 ` Linus Torvalds ` (3 preceding siblings ...) 2006-12-13 23:40 ` Greg KH @ 2006-12-14 8:49 ` Duncan Sands 2006-12-14 9:56 ` Hans-Jürgen Koch 2006-12-14 12:27 ` James Courtier-Dutton 4 siblings, 2 replies; 239+ messages in thread From: Duncan Sands @ 2006-12-14 8:49 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel, tglx > I'm really not convinced about the user-mode thing unless somebody can > show me a good reason for it. Not just some "wouldn't it be nice" kind of > thing. A real, honest-to-goodness reason that we actually _want_ to see > used. Qemu? It would be nice if emulators could directly drive hardware: useful for reverse engineering windows drivers for example. Duncan. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 8:49 ` Duncan Sands @ 2006-12-14 9:56 ` Hans-Jürgen Koch 2006-12-14 11:51 ` Olivier Galibert ` (3 more replies) 2006-12-14 12:27 ` James Courtier-Dutton 1 sibling, 4 replies; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 9:56 UTC (permalink / raw) To: linux-kernel Am Donnerstag, 14. Dezember 2006 09:49 schrieb Duncan Sands: > > I'm really not convinced about the user-mode thing unless somebody can > > show me a good reason for it. Not just some "wouldn't it be nice" kind of > > thing. A real, honest-to-goodness reason that we actually _want_ to see > > used. > > Qemu? It would be nice if emulators could directly drive hardware: > useful for reverse engineering windows drivers for example. I really think there is a big misunderstanding in this whole discussion. Userspace IO (UIO) was never intended to be a generic userspace interface to all kinds of hardware. I completely agree with Linus and all others who expressed that opinion that a full-fledged kernel module is the, let's say, most beautiful way of writing a driver. But it's not always the best way. Let's look at a real world example: A small German manufacturer produces high-end AD converter cards. He sells 100 pieces per year, only in Germany and only with Windows drivers. He would now like to make his cards work with Linux. He has two driver programmers with little experience in writing Linux kernel drivers. What do you tell him? Write a large kernel module from scratch? Completely rewrite his code because it uses floating point arithmetics? And even if they did that, do we really want it? Do we want to add large kernel modules for each exotic card? With UIO, everything becomes much cleaner: * They let somebody write the small kernel module they need to handle interrupts in a _clean_ way. This module can easily be checked and could even be included in a mainline kernel. * They do the rest in userspace, with all the libraries and tools they're used to. That's what they _can_ do. Note that this is a _technical_ reason. I'm not talking about all that licensing possibilities that were discussed here. UIO's intention is to allow manufacturers of industrial IO hardware to support Linux without the need to hire half a dozen experienced kernel developers. It makes their kernels more stable and easier to maintain. We don't get flooded with requests to include large modules for exotic hardware into the mainline kernel. The alternative is what we have at the moment: Manufacturers don't support Linux at all, because it's too difficult to handle for them, or they do it in a way that either violates our licence or leads to unstable customized kernels (or both). So, your qemu suggestion is certainly interesting. But, really, we never thought of such a general thing while we were working at that code. I thought I had to make that clear. Reading this thread, one could get the impression we wanted to start a revolution and handle all hardware in userspace from now on. This is definetly wrong. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:56 ` Hans-Jürgen Koch @ 2006-12-14 11:51 ` Olivier Galibert 2006-12-14 12:45 ` Hans-Jürgen Koch 2006-12-14 12:39 ` Alan ` (2 subsequent siblings) 3 siblings, 1 reply; 239+ messages in thread From: Olivier Galibert @ 2006-12-14 11:51 UTC (permalink / raw) To: linux-kernel On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote: > A small German manufacturer produces high-end AD converter cards. He sells > 100 pieces per year, only in Germany and only with Windows drivers. He would > now like to make his cards work with Linux. He has two driver programmers > with little experience in writing Linux kernel drivers. What do you tell him? > Write a large kernel module from scratch? Completely rewrite his code > because it uses floating point arithmetics? Write a small kernel module which: - create a device node per-card - read the data from the A/D as fast as possible and buffer it in main memory without touching it - implements a read interface to read data from the buffer - implement ioctls for whatever controls you need And that's it. All the rest can be done in userspace, safely, with floating point, C++ and everything. If the driver programmers are worth their pay, their driver is probably already split logically at where the userspace-kernel interface would be. And small means small, like 200 lines or so, more if you want to have fun with sysfs, poll, aio and their ilk, but that's not a necessity. OG. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 11:51 ` Olivier Galibert @ 2006-12-14 12:45 ` Hans-Jürgen Koch 2006-12-14 19:16 ` Olivier Galibert 0 siblings, 1 reply; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 12:45 UTC (permalink / raw) To: Olivier Galibert, linux-kernel Am Donnerstag, 14. Dezember 2006 12:51 schrieb Olivier Galibert: > On Thu, Dec 14, 2006 at 10:56:03AM +0100, Hans-Jürgen Koch wrote: > > A small German manufacturer produces high-end AD converter cards. He sells > > 100 pieces per year, only in Germany and only with Windows drivers. He would > > now like to make his cards work with Linux. He has two driver programmers > > with little experience in writing Linux kernel drivers. What do you tell him? > > Write a large kernel module from scratch? Completely rewrite his code > > because it uses floating point arithmetics? > > Write a small kernel module which: What you suggest is not a "small kernel module". It's what we have now, writing a complete driver. > - create a device node per-card That's what UIO does, plus some standard sysfs files, that tell you e.g. the size of the cards memory you can map. There are standard file names that allow you e.g. to automatically search for all registered uio drivers and their properties. > - read the data from the A/D as fast as possible and buffer it in main > memory without touching it If the card already has that data in its dual port RAM, you do an unneccessary copy. > - implements a read interface to read data from the buffer Here you do the next unneccessary copy. > - implement ioctls for whatever controls you need Implementing ioctls for everything is bad coding style and a has bad performance. I said "high-end AD card", that means you have a signal processor on that board, want to download firmware to it and so on. You end up copying lots of data between user space and kernel space. > > And that's it. Yes, that's a complete kernel driver that you'd never get into a mainline kernel. Furthermore, the card manufacturer would have to employ at least two experienced Linux _kernel_ programmers. That's too much for a small company who's business is something different. > All the rest can be done in userspace, safely, with > floating point, C++ and everything. If the driver programmers are > worth their pay, their driver is probably already split logically at > where the userspace-kernel interface would be. > > And small means small, like 200 lines or so, more if you want to have > fun with sysfs, poll, aio and their ilk, but that's not a necessity. You can achieve 100 lines with uio, including sysfs and poll. What you describe would never fit in 200 lines for a non-trivial card. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 12:45 ` Hans-Jürgen Koch @ 2006-12-14 19:16 ` Olivier Galibert 0 siblings, 0 replies; 239+ messages in thread From: Olivier Galibert @ 2006-12-14 19:16 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 2665 bytes --] On Thu, Dec 14, 2006 at 01:45:16PM +0100, Hans-Jürgen Koch wrote: > What you suggest is not a "small kernel module". It's what we have now, > writing a complete driver. Who says a complete driver has to be big? > That's what UIO does, plus some standard sysfs files, that tell you e.g. > the size of the cards memory you can map. There are standard file names > that allow you e.g. to automatically search for all registered uio > drivers and their properties. Which makes the userspace code much more complex than needed. > If the card already has that data in its dual port RAM, you do an > unneccessary copy. Unnecessary only if [card data rate]*[maximum userspace latency] < [dual port ram size]. Doing the buffering in the kernel where it belongs changes the right part of the equation to [buffer size], which can be orders of magnitude way bigger. And you can have the card DMA into the buffer directly if you feel like it. > > - implements a read interface to read data from the buffer > > Here you do the next unneccessary copy. You can mmap, you can splice(), none is really hard. > > - implement ioctls for whatever controls you need > > Implementing ioctls for everything is bad coding style and a has bad > performance. I thought the ALSA guys always said their stuff was high performance? In any case, if ioctl is too slow for your controls, it means that your ioctls are too low level, as in register access instead of "reboot card at address x". And uio, with its lack of protection against wandering interrupts, can't cut it. > I said "high-end AD card", that means you have a > signal processor on that board, want to download firmware to it > and so on. You end up copying lots of data between user space > and kernel space. You're allowed to implement write() too. > Yes, that's a complete kernel driver that you'd never get into > a mainline kernel. Furthermore, the card manufacturer would have to > employ at least two experienced Linux _kernel_ programmers. That's > too much for a small company who's business is something different. So they have a choice between learning a minimum of linux kernel internals, or a minimum of uio. I suspect the hidden kinks of uio and relative lack of documentation make the kernel route *way* easier. > You can achieve 100 lines with uio, including sysfs and poll. What you > describe would never fit in 200 lines for a non-trivial card. Ok, 200 is an exaggeration. Here is a 600-lines 2.4 driver that does what I say, with direct dma to the internal buffer from the card and userland-driven firmware upload. I know that a 2.6 version would actually be smaller. OG. [-- Attachment #2: iiadc64.c --] [-- Type: text/x-csrc, Size: 14658 bytes --] //========================= Official Notice =============================== // // "This software was developed at the National Institute of Standards // and Technology by employees of the Federal Government in the course of // their official duties. Pursuant to Title 17 Section 105 of the United // States Code this software is not subject to copyright protection and // is in the public domain. // // The NIST Data Flow System (NDFS) is an experimental system and is // offered AS IS. NIST assumes no responsibility whatsoever for its use // by other parties, and makes no guarantees and NO WARRANTIES, EXPRESS // OR IMPLIED, about its quality, reliability, fitness for any purpose, // or any other characteristic. // // We would appreciate acknowledgement if the software is used. // // This software can be redistributed and/or modified freely provided // that any derivative works bear some notice that they are derived from // it, and any modified versions bear some notice that they have been // modified from the original." // //========================================================================= #include <linux/version.h> #include <linux/module.h> #include <linux/delay.h> #include <linux/errno.h> #include <linux/fs.h> #include <linux/kernel.h> #include <linux/major.h> #include <linux/slab.h> #include <linux/mm.h> #include <linux/poll.h> #include <linux/pci.h> #include <linux/signal.h> #include <asm/io.h> #include <linux/ioport.h> #include <asm/pgtable.h> #include <asm/page.h> #include <linux/sched.h> #include <asm/segment.h> #include <linux/types.h> #include <linux/wrapper.h> #include <linux/interrupt.h> #include <linux/kmod.h> #include <linux/vmalloc.h> #include <linux/init.h> #include "iiadc64.h" #define DEBUG_AL(format, a...) printk(KERN_WARNING format, ##a) #define DEBUG_ER(format, a...) printk(KERN_WARNING format, ##a) #define DEBUG_WR(format, a...) printk(KERN_WARNING format, ##a) #define DEBUG_IN(format, a...) printk(KERN_WARNING format, ##a) #define DEBUG_TR(format, a...) printk(KERN_WARNING format, ##a) enum{ MODE_MEMORY, MODE_RING, MODE_MAILBOX }; enum{ RING_SIZE = 4096*4096 }; static int iiadc64_open(struct inode *, struct file *); static int iiadc64_release(struct inode *, struct file *); static int iiadc64_ioctl(struct inode *, struct file *, unsigned int, unsigned long); static ssize_t iiadc64_read(struct file *, char *, size_t, loff_t *); static ssize_t iiadc64_write(struct file *, const char *, size_t, loff_t *); static struct file_operations iiadc64_fops = { open: iiadc64_open, release: iiadc64_release, ioctl: iiadc64_ioctl, read: iiadc64_read, write: iiadc64_write }; struct iiadc64_state { struct pci_dev *dev; unsigned long iobase; unsigned int irq; unsigned char *memory; int access_mode, access_mbox; int irqen; int irqtick; int ring_rpos, ring_wpos; int dropouts; spinlock_t lock; #if LINUX_VERSION_CODE >= 0x20300 wait_queue_head_t ring_wait; #else struct wait_queue *ring_wait; #endif } is; /* [DaveM] I've recoded most of this so that: * 1) It's easier to tell what is happening * 2) It's more portable, especially for translating things * out of vmalloc mapped areas in the kernel. * 3) Less unnecessary translations happen. * * The code used to assume that the kernel vmalloc mappings * existed in the page tables of every process, this is simply * not guarenteed. We now use pgd_offset_k which is the * defined way to get at the kernel page tables. */ /* Given PGD from the address space's page table, return the kernel * virtual mapping of the physical memory mapped at ADR. */ static inline unsigned long uvirt_to_kva(pgd_t *pgd, unsigned long adr) { unsigned long ret = 0UL; pmd_t *pmd; pte_t *ptep, pte; if (!pgd_none(*pgd)) { pmd = pmd_offset(pgd, adr); if (!pmd_none(*pmd)) { ptep = pte_offset(pmd, adr); pte = *ptep; if(pte_present(pte)) { ret = (unsigned long) page_address(pte_page(pte)); ret |= (adr & (PAGE_SIZE - 1)); } } } return ret; } static inline unsigned long uvirt_to_bus(unsigned long adr) { unsigned long kva, ret; kva = uvirt_to_kva(pgd_offset(current->mm, adr), adr); ret = virt_to_bus((void *)kva); return ret; } static inline unsigned long kvirt_to_bus(unsigned long adr) { unsigned long va, kva, ret; va = VMALLOC_VMADDR(adr); kva = uvirt_to_kva(pgd_offset_k(va), va); ret = virt_to_bus((void *)kva); return ret; } /* Here we want the physical address of the memory. * This is used when initializing the contents of the * area and marking the pages as reserved. */ static inline unsigned long kvirt_to_pa(unsigned long adr) { unsigned long va, kva, ret; va = VMALLOC_VMADDR(adr); kva = uvirt_to_kva(pgd_offset_k(va), va); ret = __pa(kva); return ret; } static void * rvmalloc(signed long size) { void * mem; unsigned long adr, page; mem=vmalloc_32(size); if (mem) { memset(mem, 0, size); /* Clear the ram out, no junk to the user */ adr=(unsigned long) mem; while (size > 0) { page = kvirt_to_pa(adr); mem_map_reserve(virt_to_page(__va(page))); adr+=PAGE_SIZE; size-=PAGE_SIZE; } } return mem; } static void rvfree(void * mem, signed long size) { unsigned long adr, page; if (mem) { adr=(unsigned long) mem; while (size > 0) { page = kvirt_to_pa(adr); mem_map_unreserve(virt_to_page(__va(page))); adr+=PAGE_SIZE; size-=PAGE_SIZE; } vfree(mem); } } static unsigned int iiadc64_mailbox_read(int box) { int counter = 100000; int mask = 0xf0000 << (box*4); while(!(inl(is.iobase + 0x34) & mask) && (--counter)); if(!counter) DEBUG_ER("iiadc64: Timeout on mailbox %d read\n", box); return inl(is.iobase + 0x10 + 4*box); } static int iiadc64_mailbox_check_read(int box) { int mask = 0xf0000 << (box*4); return (inl(is.iobase + 0x34) & mask) != 0; } static void iiadc64_mailbox_write(int box, unsigned int data) { int counter = 100000; int mask = 0xf << box; while((inl(is.iobase + 0x34) & mask) && (--counter)); if(!counter) DEBUG_ER("iiadc64: Timeout on mailbox %d write\n", box); outl(data, is.iobase + 4*box); } static void iiadc64_irq(int irq, void *dev_id, struct pt_regs *regs) { unsigned int istat; istat = inl(is.iobase + 0x38); if(istat & 0x20000) { unsigned int request = iiadc64_mailbox_read(1); if(request == 1) { spin_lock(&is.lock); is.ring_wpos = 0; is.ring_rpos = 0; is.dropouts = 0; spin_unlock(&is.lock); iiadc64_mailbox_write(0, 0); } else { int delta; int csize; request *= 4096; delta = request - is.ring_wpos; if(delta < 0) delta += RING_SIZE; spin_lock(&is.lock); csize = is.ring_wpos - is.ring_rpos; if(csize < 0) csize += RING_SIZE; if(csize + delta > RING_SIZE) is.dropouts++; is.ring_wpos = request; is.irqtick++; spin_unlock(&is.lock); wake_up_interruptible(&is.ring_wait); } } if(istat & 0x800000) outl(istat, is.iobase + 0x38); } static void iiadc64_reset(void) { unsigned int intcsr; unsigned int timeout; unsigned int val; if(is.irqen) intcsr = 0x003f1400; else intcsr = 0x003f0000; outl(intcsr, is.iobase + 0x38); outl(0x0f000000, is.iobase + 0x3c); timeout = HZ/10; do { current->state = TASK_INTERRUPTIBLE; timeout = schedule_timeout(timeout); } while (timeout); outl(0x00000000, is.iobase + 0x3c); timeout = HZ/5; do { current->state = TASK_INTERRUPTIBLE; timeout = schedule_timeout(timeout); } while (timeout); if(is.irqen) outl(0x00000600, is.iobase + 0x3c); val = iiadc64_mailbox_read(0); if(val != 0x1f) DEBUG_ER("iiadc64: Wrong value in mailbox 0 after reset : %08x\n", val); else DEBUG_IN("iiadc64: Reset successful\n"); while(iiadc64_mailbox_check_read(0)) (void)iiadc64_mailbox_read(0); is.ring_rpos = 0; is.ring_wpos = 0; } static int iiadc64_open(struct inode *inode, struct file *file) { is.access_mode = MODE_MEMORY; is.irqtick = 0; is.ring_wpos = is.ring_rpos = 0; is.dropouts = 0; if(request_irq(is.irq, iiadc64_irq, SA_SHIRQ, "iiadc64", &is)) { DEBUG_ER("iiadc64: Couldn't get shared irq %d\n", is.irq); return -EIO; } is.irqen = 1; iiadc64_reset(); MOD_INC_USE_COUNT; return 0; } static int iiadc64_release(struct inode *inode, struct file *file) { is.irqen = 0; iiadc64_reset(); free_irq(is.irq, &is); MOD_DEC_USE_COUNT; return 0; } static int iiadc64_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long param) { switch(cmd) { case II_RESET: iiadc64_reset(); break; case II_MODE_MEMORY: is.access_mode = MODE_MEMORY; break; case II_MODE_RING: is.access_mode = MODE_RING; break; case II_MODE_MAILBOX: { int mbox, err; err = get_user(mbox, (int *)param); if(err) return err; if(mbox<0 || mbox>3) return -EINVAL; is.access_mode = MODE_MAILBOX; is.access_mbox = mbox; break; } case II_PCI_TABLE: { unsigned int adr; int err; int i; err = get_user(adr, (unsigned int *)param); if(err) return err; for(i=0; i<RING_SIZE/4096; i++) { iiadc64_mailbox_write(0, 1); iiadc64_mailbox_write(0, adr++); iiadc64_mailbox_write(0, kvirt_to_bus((unsigned long)is.memory+i*4096)); } break; } case II_RUN: { unsigned int adr; int err; err = get_user(adr, (unsigned int *)param); if(err) return err; iiadc64_mailbox_write(0, 3); iiadc64_mailbox_write(0, adr); break; } default: return -ENOTTY; } return 0; } static ssize_t iiadc64_read(struct file *file, char *buf, size_t size, loff_t *offset) { switch(is.access_mode) { case MODE_MEMORY: { size_t cur_size; int adr = *offset / 4; cur_size = size; while(cur_size > 0) { size_t block_size = cur_size; unsigned int *data = (unsigned int *)is.memory; size_t cb_size; if(block_size > PAGE_SIZE) block_size = PAGE_SIZE; cur_size -= block_size; cb_size = block_size; while(cb_size) { iiadc64_mailbox_write(0, 2); iiadc64_mailbox_write(0, adr++); *data++ = iiadc64_mailbox_read(0); cb_size -= 4; } if(copy_to_user(buf, (const void *)is.memory, block_size)) return -EFAULT; buf += block_size; } *offset += size; return size; } case MODE_RING: { size_t cur_size; unsigned long flags; int avail, dropouts; cur_size = size; while(cur_size) { size_t block_size; spin_lock_irqsave(&is.lock, flags); while(is.ring_wpos == is.ring_rpos) { spin_unlock_irqrestore(&is.lock, flags); interruptible_sleep_on(&is.ring_wait); if (signal_pending(current)) { DEBUG_TR("iiadc64: ERESTARTSYS\n"); return -ERESTARTSYS; } spin_lock_irqsave(&is.lock, flags); } avail = is.ring_wpos - is.ring_rpos; spin_unlock_irqrestore(&is.lock, flags); if(avail < 0) avail += RING_SIZE; block_size = cur_size; if(block_size > avail) block_size = avail; if(block_size + is.ring_rpos > RING_SIZE) block_size = RING_SIZE - is.ring_rpos; if(copy_to_user(buf, (const void *)(is.memory + is.ring_rpos), block_size)) return -EFAULT; spin_lock_irqsave(&is.lock, flags); is.ring_rpos += block_size; if(is.ring_rpos == RING_SIZE) is.ring_rpos = 0; dropouts = is.dropouts; is.dropouts = 0; spin_unlock_irqrestore(&is.lock, flags); if(dropouts) DEBUG_ER("iiadc64: Dropout detected\n"); buf += block_size; cur_size -= block_size; } *offset += size; return size; } case MODE_MAILBOX: { size_t cur_size = size; for(;;) { unsigned int val = iiadc64_mailbox_read(is.access_mbox); if(put_user(val, (unsigned int *)buf)) return -EFAULT; buf += sizeof(unsigned int); if(cur_size <= sizeof(unsigned int)) break; cur_size -= sizeof(unsigned int); } *offset += size; return size; } default: return -ENOTTY; } } static ssize_t iiadc64_write(struct file *file, const char *buf, size_t size, loff_t *offset) { switch(is.access_mode) { case MODE_MEMORY: { size_t cur_size; int adr = *offset / 4; cur_size = size; while(cur_size > 0) { size_t block_size = cur_size; unsigned int *data = (unsigned int *)is.memory; if(block_size > PAGE_SIZE) block_size = PAGE_SIZE; if(copy_from_user((void *)is.memory, buf, block_size)) return -EFAULT; buf += block_size; cur_size -= block_size; while(block_size) { iiadc64_mailbox_write(0, 1); iiadc64_mailbox_write(0, adr++); iiadc64_mailbox_write(0, *data++); block_size -= 4; } } *offset += size; return size; } case MODE_MAILBOX: { size_t cur_size = size; for(;;) { unsigned int val; if(get_user(val, (unsigned int *)buf)) return -EFAULT; iiadc64_mailbox_write(is.access_mbox, val); buf += sizeof(unsigned int); if(cur_size <= sizeof(unsigned int)) break; cur_size -= sizeof(unsigned int); } *offset += size; return size; } default: return -ENOTTY; } } #ifdef MODULE int init_module(void) #else int iiadc64_init(void) #endif { DEBUG_AL("IIADC64 minimal kernel driver (c) 1999 Olivier Galibert\n"); is.dev = pci_find_device(0x10e8, 0x807f, 0); if(!is.dev) { DEBUG_ER("iiadc64: Unable to find the DSP board\n"); return -EIO; } #if LINUX_VERSION_CODE >= 0x20400 if(pci_enable_device(is.dev)) return -EIO; pci_set_master(is.dev); is.iobase = pci_resource_start(is.dev, 0); #else is.iobase = is.dev->base_address[0] & PCI_BASE_ADDRESS_IO_MASK; #endif is.irq = is.dev->irq; is.memory = rvmalloc(RING_SIZE); if(!is.memory) { DEBUG_ER("iiadc64: Couldn't allocate ring buffer\n"); return -EIO; } if (register_chrdev(II_MAJOR, "iiadc64", &iiadc64_fops)) { DEBUG_ER("iiadc64: Unable to register character device\n"); return -EIO; } DEBUG_IN("iiadc64: DSP board found, io at 0x%lx, irq %u\n", is.iobase, is.irq); #if LINUX_VERSION_CODE >= 0x20300 init_waitqueue_head(&is.ring_wait); #else is.ring_wait = 0; init_waitqueue(&is.ring_wait); #endif is.lock = SPIN_LOCK_UNLOCKED; iiadc64_reset(); return 0; } #ifdef MODULE void cleanup_module(void) { rvfree(is.memory, RING_SIZE); unregister_chrdev(II_MAJOR, "iiadc64"); } #endif [-- Attachment #3: iiadc64.h --] [-- Type: text/x-chdr, Size: 1477 bytes --] //========================= Official Notice =============================== // // "This software was developed at the National Institute of Standards // and Technology by employees of the Federal Government in the course of // their official duties. Pursuant to Title 17 Section 105 of the United // States Code this software is not subject to copyright protection and // is in the public domain. // // The NIST Data Flow System (NDFS) is an experimental system and is // offered AS IS. NIST assumes no responsibility whatsoever for its use // by other parties, and makes no guarantees and NO WARRANTIES, EXPRESS // OR IMPLIED, about its quality, reliability, fitness for any purpose, // or any other characteristic. // // We would appreciate acknowledgement if the software is used. // // This software can be redistributed and/or modified freely provided // that any derivative works bear some notice that they are derived from // it, and any modified versions bear some notice that they have been // modified from the original." // //========================================================================= #ifndef __IIADC64_H #define __IIADC64_H #include <linux/ioctl.h> #define II_MAJOR 121 #define II_RESET _IO(II_MAJOR, 0) #define II_MODE_MEMORY _IO(II_MAJOR, 1) #define II_MODE_RING _IO(II_MAJOR, 2) #define II_MODE_MAILBOX _IOR(II_MAJOR, 3, int) #define II_PCI_TABLE _IOR(II_MAJOR, 4, unsigned int) #define II_RUN _IOR(II_MAJOR, 5, unsigned int) #endif ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:56 ` Hans-Jürgen Koch 2006-12-14 11:51 ` Olivier Galibert @ 2006-12-14 12:39 ` Alan 2006-12-14 13:08 ` Hans-Jürgen Koch 2006-12-14 17:02 ` Jan Engelhardt 2006-12-14 17:34 ` Bernd Petrovitsch 3 siblings, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 12:39 UTC (permalink / raw) To: Hans-Jürgen Koch; +Cc: linux-kernel On Thu, 14 Dec 2006 10:56:03 +0100 Hans-Jürgen Koch <hjk@linutronix.de> wrote: > * They let somebody write the small kernel module they need to handle > interrupts in a _clean_ way. This module can easily be checked and could > even be included in a mainline kernel. And might as well do the mmap work as well. I'm not clear what uio gives us that a decently written pair of PCI and platform template drivers for people to use would not do more cleanly. Also many of these cases you might not want stuff in userspace but the uio model would push it that way which seems to be an unfortunate side effect. Yes some probably do want to go that way but not all. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 12:39 ` Alan @ 2006-12-14 13:08 ` Hans-Jürgen Koch 0 siblings, 0 replies; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 13:08 UTC (permalink / raw) To: Alan; +Cc: linux-kernel Am Donnerstag, 14. Dezember 2006 13:39 schrieb Alan: > On Thu, 14 Dec 2006 10:56:03 +0100 > Hans-Jürgen Koch <hjk@linutronix.de> wrote: > > > * They let somebody write the small kernel module they need to handle > > interrupts in a _clean_ way. This module can easily be checked and could > > even be included in a mainline kernel. > > And might as well do the mmap work as well. I'm not clear what uio gives > us that a decently written pair of PCI and platform template drivers for > people to use would not do more cleanly. * Creation of /dev device files. * Creation of standardized sysfs files. * Interrupt registration and handling. * mmap for physical and logical memory. * read, poll, and fasync for interrupt handling. * a predefined, clean design that the hardware manufacturer can use. > > Also many of these cases you might not want stuff in userspace but the > uio model would push it that way which seems to be an unfortunate side > effect. Yes some probably do want to go that way but not all. Alright, but everybody has the choice. If the alternative is to have no Linux drivers at all because it's too expensive, then somebody might consider UIO. To have the big parts of the driver in userspace allows them to remain stable across different kernel versions. Driver updates can take place without changing the kernel. For some manufacturers these will be strong arguments in favor of UIO. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:56 ` Hans-Jürgen Koch 2006-12-14 11:51 ` Olivier Galibert 2006-12-14 12:39 ` Alan @ 2006-12-14 17:02 ` Jan Engelhardt 2006-12-14 17:17 ` Hans-Jürgen Koch 2006-12-16 20:13 ` Lee Revell 2006-12-14 17:34 ` Bernd Petrovitsch 3 siblings, 2 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:02 UTC (permalink / raw) To: Hans-Jürgen Koch; +Cc: linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 544 bytes --] On Dec 14 2006 10:56, Hans-Jürgen Koch wrote: > >A small German manufacturer produces high-end AD converter cards. He sells >100 pieces per year, only in Germany and only with Windows drivers. He would >now like to make his cards work with Linux. He has two driver programmers >with little experience in writing Linux kernel drivers. What do you tell him? >Write a large kernel module from scratch? Completely rewrite his code >because it uses floating point arithmetics? They use floating point in (Windows) kernelspace? Oh my. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:02 ` Jan Engelhardt @ 2006-12-14 17:17 ` Hans-Jürgen Koch 2006-12-14 17:57 ` Jan Engelhardt 2006-12-16 20:13 ` Lee Revell 1 sibling, 1 reply; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 17:17 UTC (permalink / raw) To: Jan Engelhardt; +Cc: linux-kernel Am Donnerstag, 14. Dezember 2006 18:02 schrieb Jan Engelhardt: > > On Dec 14 2006 10:56, Hans-Jürgen Koch wrote: > > > >A small German manufacturer produces high-end AD converter cards. He sells > >100 pieces per year, only in Germany and only with Windows drivers. He would > >now like to make his cards work with Linux. He has two driver programmers > >with little experience in writing Linux kernel drivers. What do you tell him? > >Write a large kernel module from scratch? Completely rewrite his code > >because it uses floating point arithmetics? > > They use floating point in (Windows) kernelspace? Oh my. To be honest, I never really understood where kernel space starts and user space ends in Windows, so I'm not sure about this :-) Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:17 ` Hans-Jürgen Koch @ 2006-12-14 17:57 ` Jan Engelhardt 0 siblings, 0 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:57 UTC (permalink / raw) To: Hans-Jürgen Koch; +Cc: linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 480 bytes --] On Dec 14 2006 18:17, Hans-Jürgen Koch wrote: >> >> They use floating point in (Windows) kernelspace? Oh my. > >To be honest, I never really understood where kernel space starts and user space >ends in Windows, so I'm not sure about this :-) Well, in Windows 95/98 you could do inportb (inb) and friends from "userspace" without an extra kernel driver. Maybe it just always ran in kernelspace, explains why many say 95/98 was less stable than the NT-based versions. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:02 ` Jan Engelhardt 2006-12-14 17:17 ` Hans-Jürgen Koch @ 2006-12-16 20:13 ` Lee Revell 2006-12-16 20:28 ` Jan Engelhardt 1 sibling, 1 reply; 239+ messages in thread From: Lee Revell @ 2006-12-16 20:13 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Hans-Jürgen Koch, linux-kernel On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote: > On Dec 14 2006 10:56, Hans-Jürgen Koch wrote: > > > >A small German manufacturer produces high-end AD converter cards. He sells > >100 pieces per year, only in Germany and only with Windows drivers. He would > >now like to make his cards work with Linux. He has two driver programmers > >with little experience in writing Linux kernel drivers. What do you tell him? > >Write a large kernel module from scratch? Completely rewrite his code > >because it uses floating point arithmetics? > > They use floating point in (Windows) kernelspace? Oh my. Yes, definitely. For example lots of Windows sound drivers do AC3 decoding in kernelspace. Of course the vendors usually lie and say it's done in hardware... Lee ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-16 20:13 ` Lee Revell @ 2006-12-16 20:28 ` Jan Engelhardt 0 siblings, 0 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-16 20:28 UTC (permalink / raw) To: Lee Revell; +Cc: Hans-Jürgen Koch, linux-kernel On Dec 16 2006 15:13, Lee Revell wrote: >On Thu, 2006-12-14 at 18:02 +0100, Jan Engelhardt wrote: >> >> They use floating point in (Windows) kernelspace? Oh my. > >Yes, definitely. Explains why Windows is so slow ;-) [FPU restore and stuff...] On that matter, when does the Linux kernel do proper FPU handling? At context switches? If so, would not that make a kthread fpu-capable? >For example lots of Windows sound drivers do AC3 decoding in kernelspace. >Of course the vendors usually lie and say it's done in hardware... They don't need to lie, the user buys it anyway... -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:56 ` Hans-Jürgen Koch ` (2 preceding siblings ...) 2006-12-14 17:02 ` Jan Engelhardt @ 2006-12-14 17:34 ` Bernd Petrovitsch 2006-12-14 17:47 ` Hans-Jürgen Koch 3 siblings, 1 reply; 239+ messages in thread From: Bernd Petrovitsch @ 2006-12-14 17:34 UTC (permalink / raw) To: Hans-Jürgen Koch; +Cc: linux-kernel On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote: [....] > A small German manufacturer produces high-end AD converter cards. He sells > 100 pieces per year, only in Germany and only with Windows drivers. He would > now like to make his cards work with Linux. He has two driver programmers > with little experience in writing Linux kernel drivers. What do you tell him? > Write a large kernel module from scratch? Completely rewrite his code > because it uses floating point arithmetics? Find a Linux kernel guru/company and pay him/them for -) an evaluation if it is "better" (for whatever better means) to port the driver or write it from scratch and -) do the better thing. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:34 ` Bernd Petrovitsch @ 2006-12-14 17:47 ` Hans-Jürgen Koch 2006-12-14 17:59 ` Bernd Petrovitsch 0 siblings, 1 reply; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 17:47 UTC (permalink / raw) To: Bernd Petrovitsch; +Cc: linux-kernel Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch: > On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote: > [....] > > A small German manufacturer produces high-end AD converter cards. He sells > > 100 pieces per year, only in Germany and only with Windows drivers. He would > > now like to make his cards work with Linux. He has two driver programmers > > with little experience in writing Linux kernel drivers. What do you tell him? > > Write a large kernel module from scratch? Completely rewrite his code > > because it uses floating point arithmetics? > > Find a Linux kernel guru/company and pay him/them for > -) an evaluation if it is "better" (for whatever better means) to port > the driver > or write it from scratch and > -) do the better thing. Good idea - whatever "porting" means. There are lots of Windows drivers out there that are also partly user space using that Kithara stuff. They have most of their driver in a dll. So that is similar to what we want with UIO - except that we handle interrupts in a clean way, they don't. If you need to port such a driver, simply writing a kernel module and a user space library would change so much of the concept that you can start rewriting it from scratch. And you'll have a large kernel module to maintain. OK, the guru/company can earn money with it, at least as long as the customer doesn't realize it is not the best solution for him. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:47 ` Hans-Jürgen Koch @ 2006-12-14 17:59 ` Bernd Petrovitsch 0 siblings, 0 replies; 239+ messages in thread From: Bernd Petrovitsch @ 2006-12-14 17:59 UTC (permalink / raw) To: Hans-Jürgen Koch; +Cc: linux-kernel On Thu, 2006-12-14 at 18:47 +0100, Hans-Jürgen Koch wrote: > Am Donnerstag, 14. Dezember 2006 18:34 schrieb Bernd Petrovitsch: > > On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote: > > [....] > > > A small German manufacturer produces high-end AD converter cards. He sells > > > 100 pieces per year, only in Germany and only with Windows drivers. He would > > > now like to make his cards work with Linux. He has two driver programmers > > > with little experience in writing Linux kernel drivers. What do you tell him? > > > Write a large kernel module from scratch? Completely rewrite his code > > > because it uses floating point arithmetics? > > > > Find a Linux kernel guru/company and pay him/them for > > -) an evaluation if it is "better" (for whatever better means) to port > > the driver > > or write it from scratch and > > -) do the better thing. > > Good idea - whatever "porting" means. There are lots of Windows drivers out there Yes, I didn't want to open that can of worms. > that are also partly user space using that Kithara stuff. They have most of their > driver in a dll. So that is similar to what we want with UIO - except that we > handle interrupts in a clean way, they don't. > If you need to port such a driver, simply writing a kernel module and a user space > library would change so much of the concept that you can start rewriting it from Of course, if "better" means "as cheap as possible no matter what", this is probably the way to go. Tough luck if you get into technical problems ..... > scratch. And you'll have a large kernel module to maintain. OK, the guru/company > can earn money with it, at least as long as the customer doesn't realize it is > not the best solution for him. Depending on the definition of "best". Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 8:49 ` Duncan Sands 2006-12-14 9:56 ` Hans-Jürgen Koch @ 2006-12-14 12:27 ` James Courtier-Dutton 1 sibling, 0 replies; 239+ messages in thread From: James Courtier-Dutton @ 2006-12-14 12:27 UTC (permalink / raw) To: Duncan Sands; +Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel, tglx Duncan Sands wrote: >> I'm really not convinced about the user-mode thing unless somebody can >> show me a good reason for it. Not just some "wouldn't it be nice" kind of >> thing. A real, honest-to-goodness reason that we actually _want_ to see >> used. > > Qemu? It would be nice if emulators could directly drive hardware: > useful for reverse engineering windows drivers for example. > > Duncan. I have reverse engineered many windows drivers, and what you suggest is not at all helpful. For reverse engineering, one wants to see what is happening. I.e. capture all the IO, MMIO and DMA accesses. Your suggestion bypasses this possibility. For reverse engineering windows drivers, one puts breakpoints in the HAL.DLL code or replaces the HAL.DLL code with a debugging version of it while actually running windows. Your approach runs into problems. e.g There is a register on the card that sets the DMA base address, but you don't know which register this is. If you let the driver inside QEMU write to this register, it will write values suitable for the Virtual machine instead of values suitable to for host OS. The DMA transaction will write all over the wrong memory location resulting in CRASH. One might be able to get round some of these problem with a combination of QEMU and a hacked up HAL.DLL, but it will be complicated. James ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:12 ` [GIT PATCH] more Driver core patches for 2.6.19 Linus Torvalds 2006-12-13 20:31 ` Greg KH @ 2006-12-13 20:38 ` Michael K. Edwards 2006-12-13 21:02 ` Greg KH 2006-12-13 21:03 ` Linus Torvalds 2006-12-13 21:14 ` Benjamin Herrenschmidt 2 siblings, 2 replies; 239+ messages in thread From: Michael K. Edwards @ 2006-12-13 20:38 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel On 12/13/06, Linus Torvalds <torvalds@osdl.org> wrote: > Ok, what kind of ass-hat idiotic thing is this? C'mon, Linus, tell us how you _really_ feel. Seriously, though, please please pretty please do not allow a facility for "going through a simple interface to get accesses to irqs and memory regions" into the mainline kernel, with or without toy ISA examples. Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a "driver". The correct description is more like "porting shim for MMU-less RTOS tasks"; and if the BSP vendors of the world can make a nickel supplying them, more power to them. Just not in mainline, please. Cheers, - Michael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:38 ` Michael K. Edwards @ 2006-12-13 21:02 ` Greg KH 2006-12-13 21:32 ` Martin Bligh 2006-12-13 21:48 ` Michael K. Edwards 2006-12-13 21:03 ` Linus Torvalds 1 sibling, 2 replies; 239+ messages in thread From: Greg KH @ 2006-12-13 21:02 UTC (permalink / raw) To: Michael K. Edwards; +Cc: Linus Torvalds, Andrew Morton, linux-kernel On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: > Seriously, though, please please pretty please do not allow a facility > for "going through a simple interface to get accesses to irqs and > memory regions" into the mainline kernel, with or without toy ISA > examples. Why? X does it today :) > Embedded systems integrators have enough trouble with chip vendors who > think that exposing the device registers to userspace constitutes a > "driver". Yes, and because of this, they create binary only drivers today. Lots of them. All over the place. Doing crazy stupid crap in kernelspace. Then there are people who do irq stuff in userspace but get it wrong. I've seen that happen many times in lots of different research papers and presentations. This interface does it correctly, and it allows those people who for some reason feel they do want to keep their logic in non-gpl code, to do it. It also allows code that needs floating point to not be in the kernel and in one instance using this interface actually sped up the device because of the lack of the need to go between kernel and userspace a bunch of times. > The correct description is more like "porting shim for MMU-less RTOS > tasks"; and if the BSP vendors of the world can make a nickel > supplying them, more power to them. Just not in mainline, please. Again, X does this today, and does does lots of other applications. This is a way to do it in a sane manner, to keep people who want to do floating point out of the kernel, and to make some embedded people much happier to use Linux, gets them from being so mad at Linux because we keep changing the internal apis, and makes me happier as they stop violating my copyright by creating closed drivers in the kernel. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:02 ` Greg KH @ 2006-12-13 21:32 ` Martin Bligh 2006-12-13 21:47 ` Andrew Morton 2006-12-13 21:48 ` Michael K. Edwards 1 sibling, 1 reply; 239+ messages in thread From: Martin Bligh @ 2006-12-13 21:32 UTC (permalink / raw) To: Greg KH; +Cc: Michael K. Edwards, Linus Torvalds, Andrew Morton, linux-kernel Greg KH wrote: > On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: >> Seriously, though, please please pretty please do not allow a facility >> for "going through a simple interface to get accesses to irqs and >> memory regions" into the mainline kernel, with or without toy ISA >> examples. > > Why? X does it today :) Umm ... and you're trying to use the current X model for a positive example of what we should be doing? that's ... interesting. >> Embedded systems integrators have enough trouble with chip vendors who >> think that exposing the device registers to userspace constitutes a >> "driver". > > Yes, and because of this, they create binary only drivers today. Lots > of them. All over the place. Doing crazy stupid crap in kernelspace. So let's come out and ban binary modules, rather than pussyfooting around, if that's what we actually want to do. It comes down to a question of whether we have enough leverage to push them into doing what we want, or not - are we prepared to call their bluff? The current half-assed solution of chipping slowly away at things by making them EXPORT_SYMBOL_GPL one by one makes little sense - would be better if we actually made an affirmative decision one way or the other. And yes, I know which side of that argument you'd fall on ;-) > Again, X does this today, and does does lots of other applications. > This is a way to do it in a sane manner, to keep people who want to do > floating point out of the kernel, and to make some embedded people much > happier to use Linux, gets them from being so mad at Linux because we > keep changing the internal apis, and makes me happier as they stop > violating my copyright by creating closed drivers in the kernel. I don't see how this really any different than letting them create GPL shims to export data to binary modules (aside from all the legal wanking over minutae details, which really isn't that interesting). M. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:32 ` Martin Bligh @ 2006-12-13 21:47 ` Andrew Morton 2006-12-13 22:09 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards 0 siblings, 2 replies; 239+ messages in thread From: Andrew Morton @ 2006-12-13 21:47 UTC (permalink / raw) To: Martin Bligh; +Cc: Greg KH, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh <mbligh@mbligh.org> wrote: > So let's come out and ban binary modules, rather than pussyfooting > around, if that's what we actually want to do. Give people 12 months warning (time to work out what they're going to do, talk with the legal dept, etc) then make the kernel load only GPL-tagged modules. I think I'd favour that. It would aid those people who are trying to obtain device specs, and who are persuading organisations to GPL their drivers. (Whereas the patch which is proposed in this thread hinders those people) ^ permalink raw reply [flat|nested] 239+ messages in thread
* GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-13 21:47 ` Andrew Morton @ 2006-12-13 22:09 ` Greg KH 2006-12-14 0:32 ` Greg KH 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards 1 sibling, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-13 22:09 UTC (permalink / raw) To: Andrew Morton Cc: Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote: > On Wed, 13 Dec 2006 13:32:50 -0800 > Martin Bligh <mbligh@mbligh.org> wrote: > > > So let's come out and ban binary modules, rather than pussyfooting > > around, if that's what we actually want to do. > > Give people 12 months warning (time to work out what they're going to do, > talk with the legal dept, etc) then make the kernel load only GPL-tagged > modules. > > I think I'd favour that. It would aid those people who are trying to > obtain device specs, and who are persuading organisations to GPL their drivers. Ok, I have no objection to that at all. I'll whip up such a patch in a bit to spit out kernel log messages whenever such a module is loaded so that people have some warning. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-13 22:09 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH @ 2006-12-14 0:32 ` Greg KH 2006-12-14 0:43 ` Jonathan Corbet 2006-12-24 14:27 ` Pavel Machek 0 siblings, 2 replies; 239+ messages in thread From: Greg KH @ 2006-12-14 0:32 UTC (permalink / raw) To: Andrew Morton Cc: Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, Dec 13, 2006 at 02:09:11PM -0800, Greg KH wrote: > On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote: > > On Wed, 13 Dec 2006 13:32:50 -0800 > > Martin Bligh <mbligh@mbligh.org> wrote: > > > > > So let's come out and ban binary modules, rather than pussyfooting > > > around, if that's what we actually want to do. > > > > Give people 12 months warning (time to work out what they're going to do, > > talk with the legal dept, etc) then make the kernel load only GPL-tagged > > modules. > > > > I think I'd favour that. It would aid those people who are trying to > > obtain device specs, and who are persuading organisations to GPL their drivers. > > Ok, I have no objection to that at all. I'll whip up such a patch in a > bit to spit out kernel log messages whenever such a module is loaded so > that people have some warning. Here you go. The wording for the feature-removal-schedule.txt file could probably be cleaned up. Any suggestions would be welcome. thanks, greg k-h ----------- From: Greg Kroah-Hartmna <gregkh@suse.de> Subject: Notify non-GPL module loading will be going away in January 2008 Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- Documentation/feature-removal-schedule.txt | 9 +++++++++ kernel/module.c | 6 +++++- 2 files changed, 14 insertions(+), 1 deletion(-) --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt +++ gregkh-2.6/Documentation/feature-removal-schedule.txt @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --------------------------- + +What: non GPL licensed modules will able to be loaded successfully. +When: January 2008 +Why: Numerous kernel developers feel that loading non-GPL drivers into the + kernel violates the license of the kernel and their copyright. + +Who: Greg Kroah-Hartman <greg@kroah.com> or <gregkh@suse.de> + +--------------------------- --- gregkh-2.6.orig/kernel/module.c +++ gregkh-2.6/kernel/module.c @@ -1393,9 +1393,13 @@ static void set_license(struct module *m license = "unspecified"; if (!license_is_gpl_compatible(license)) { - if (!(tainted & TAINT_PROPRIETARY_MODULE)) + if (!(tainted & TAINT_PROPRIETARY_MODULE)) { printk(KERN_WARNING "%s: module license '%s' taints " "kernel.\n", mod->name, license); + printk(KERN_WARNING "%s: This module will not be able " + "to be loaded after January 1, 2008 due to its " + "license.\n", mod->name); + } add_taint_module(mod, TAINT_PROPRIETARY_MODULE); } } ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:32 ` Greg KH @ 2006-12-14 0:43 ` Jonathan Corbet 2006-12-14 0:55 ` Greg KH 2006-12-14 10:36 ` Alan 2006-12-24 14:27 ` Pavel Machek 1 sibling, 2 replies; 239+ messages in thread From: Jonathan Corbet @ 2006-12-14 0:43 UTC (permalink / raw) To: Greg KH Cc: Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Greg's patch: > + printk(KERN_WARNING "%s: This module will not be able " > + "to be loaded after January 1, 2008 due to its " > + "license.\n", mod->name); If you're going to go ahead with this, shouldn't the message say that the module will not be loadable into *kernels released* after January 1, 2008? I bet a lot of people would read the above to say that their system will just drop dead of a New Year's hangover, and they'll freak. I wouldn't want to be the one getting all the email at that point... jon ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:43 ` Jonathan Corbet @ 2006-12-14 0:55 ` Greg KH 2006-12-14 1:00 ` Linus Torvalds ` (6 more replies) 2006-12-14 10:36 ` Alan 1 sibling, 7 replies; 239+ messages in thread From: Greg KH @ 2006-12-14 0:55 UTC (permalink / raw) To: Jonathan Corbet Cc: Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, Dec 13, 2006 at 05:43:29PM -0700, Jonathan Corbet wrote: > Greg's patch: > > > + printk(KERN_WARNING "%s: This module will not be able " > > + "to be loaded after January 1, 2008 due to its " > > + "license.\n", mod->name); > > If you're going to go ahead with this, shouldn't the message say that > the module will not be loadable into *kernels released* after January 1, > 2008? I bet a lot of people would read the above to say that their > system will just drop dead of a New Year's hangover, and they'll freak. > I wouldn't want to be the one getting all the email at that point... Heh, good point. An updated version is below. Oh, and for those who have asked me how we would enforce this after this date if this decision is made, I'd like to go on record that I will be glad to take whatever legal means necessary to stop people from violating this. Someone also mentioned that we could just put a nice poem into the kernel module image in order to be able to enforce our copyright license in any court of law. Full bellies of fish Penguins sleep under the moon Dream of wings that fly thanks, greg k-h -------------- From: Greg Kroah-Hartmna <gregkh@suse.de> Subject: Notify non-GPL module loading will be going away in January 2008 Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- Documentation/feature-removal-schedule.txt | 9 +++++++++ kernel/module.c | 7 ++++++- 2 files changed, 15 insertions(+), 1 deletion(-) --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt +++ gregkh-2.6/Documentation/feature-removal-schedule.txt @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --------------------------- + +What: non GPL licensed modules will able to be loaded successfully. +When: January 2008 +Why: Numerous kernel developers feel that loading non-GPL drivers into the + kernel violates the license of the kernel and their copyright. + +Who: Greg Kroah-Hartman <greg@kroah.com> <gregkh@novell.com> + +--------------------------- --- gregkh-2.6.orig/kernel/module.c +++ gregkh-2.6/kernel/module.c @@ -1393,9 +1393,14 @@ static void set_license(struct module *m license = "unspecified"; if (!license_is_gpl_compatible(license)) { - if (!(tainted & TAINT_PROPRIETARY_MODULE)) + if (!(tainted & TAINT_PROPRIETARY_MODULE)) { printk(KERN_WARNING "%s: module license '%s' taints " "kernel.\n", mod->name, license); + printk(KERN_WARNING "%s: This module will not be able " + "to be loaded in any kernel released after " + "January 1, 2008 due to its license.\n", + mod->name); + } add_taint_module(mod, TAINT_PROPRIETARY_MODULE); } } ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH @ 2006-12-14 1:00 ` Linus Torvalds 2006-12-14 1:08 ` Michael K. Edwards 2006-12-14 1:30 ` Grzegorz Kulewski ` (5 subsequent siblings) 6 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 1:00 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, 13 Dec 2006, Greg KH wrote: > > Full bellies of fish > Penguins sleep under the moon > Dream of wings that fly Snif. That touched me deep inside. Linus PS. Or maybe it was the curry I ate yesterday. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 1:00 ` Linus Torvalds @ 2006-12-14 1:08 ` Michael K. Edwards 0 siblings, 0 replies; 239+ messages in thread From: Michael K. Edwards @ 2006-12-14 1:08 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, linux-kernel fish for birds alone? no, teach suits how to leave more fish to go around Cheers, - Michael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH 2006-12-14 1:00 ` Linus Torvalds @ 2006-12-14 1:30 ` Grzegorz Kulewski 2006-12-14 1:58 ` Greg KH 2006-12-14 4:15 ` Linus Torvalds ` (4 subsequent siblings) 6 siblings, 1 reply; 239+ messages in thread From: Grzegorz Kulewski @ 2006-12-14 1:30 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Hi, I think that... On Wed, 13 Dec 2006, Greg KH wrote: > From: Greg Kroah-Hartmna <gregkh@suse.de> ... (most probably) there... > Subject: Notify non-GPL module loading will be going away in January 2008 > > Numerous kernel developers feel that loading non-GPL drivers into the > kernel violates the license of the kernel and their copyright. Because > of this, a one year notice for everyone to address any non-GPL > compatible modules has been set. > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> ... or (less probably) there... is a typo in your name. :-) Thanks, Grzegorz Kulewski PS. Are you _really_ sure you want this change accepted into mainline kernel? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 1:30 ` Grzegorz Kulewski @ 2006-12-14 1:58 ` Greg KH 0 siblings, 0 replies; 239+ messages in thread From: Greg KH @ 2006-12-14 1:58 UTC (permalink / raw) To: Grzegorz Kulewski Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Thu, Dec 14, 2006 at 02:30:26AM +0100, Grzegorz Kulewski wrote: > Hi, > > I think that... > > On Wed, 13 Dec 2006, Greg KH wrote: > >From: Greg Kroah-Hartmna <gregkh@suse.de> > > ... (most probably) there... > > >Subject: Notify non-GPL module loading will be going away in January 2008 > > > >Numerous kernel developers feel that loading non-GPL drivers into the > >kernel violates the license of the kernel and their copyright. Because > >of this, a one year notice for everyone to address any non-GPL > >compatible modules has been set. > > > >Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > ... or (less probably) there... > > is a typo in your name. :-) Heh, thanks. I've also fixed up the wording in the feature-removal-schedule.txt file to say: What: non-GPL-licensed modules will no longer be loaded. The wording I had before was not very easy to understand. > PS. Are you _really_ sure you want this change accepted into mainline > kernel? Yes, I do. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH 2006-12-14 1:00 ` Linus Torvalds 2006-12-14 1:30 ` Grzegorz Kulewski @ 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 5:39 ` Martin J. Bligh ` (9 more replies) 2006-12-14 5:10 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Bill Nottingham ` (3 subsequent siblings) 6 siblings, 10 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 4:15 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, 13 Dec 2006, Greg KH wrote: > > Numerous kernel developers feel that loading non-GPL drivers into the > kernel violates the license of the kernel and their copyright. Because > of this, a one year notice for everyone to address any non-GPL > compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid "shell game" drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of "derived work". It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I happen to believe that there shouldn't be technical measures that keep me from watching my DVD or listening to my music on whatever device I damn well please. Fair use, man. But it should go the other way too: we should not try to assert _our_ copyright rules on other peoples code that wasn't derived from ours, or assert _our_ technical measures that keep people from combining things their way. If people take our code, they'd better behave according to our rules. But we shouldn't have to behave according to the RIAA rules just because we _listen_ to their music. Similarly, nobody should be forced to behave according to our rules just because they _use_ our system. There's a big difference between "copy" and "use". It's exatcly the same issue whether it's music or code. You can't re-distribute other peoples music (becuase it's _their_ copyright), but they shouldn't put limits on how you personally _use_ it (because it's _your_ life). Same goes for code. Copyright is about _distribution_, not about use. We shouldn't limit how people use the code. Oh, well. I realize nobody is likely going to listen to me, and everybody has their opinion set in stone. That said, I'm going to suggest that you people talk to your COMPANY LAWYERS on this, and I'm personally not going to merge that particular code unless you can convince the people you work for to merge it first. In other words, you guys know my stance. I'll not fight the combined opinion of other kernel developers, but I sure as hell won't be the first to merge this, and I sure as hell won't have _my_ tree be the one that causes this to happen. So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees first. This is not something where we use my tree as a way to get it to other trees. This is something where the push had better come from the other direction. Because I think it's stupid. So use somebody else than me to push your political agendas, please. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds @ 2006-12-14 5:39 ` Martin J. Bligh 2006-12-14 6:01 ` Hua Zhong ` (3 more replies) 2006-12-14 7:24 ` Jeffrey V. Merkey ` (8 subsequent siblings) 9 siblings, 4 replies; 239+ messages in thread From: Martin J. Bligh @ 2006-12-14 5:39 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Linus Torvalds wrote: > > On Wed, 13 Dec 2006, Greg KH wrote: >> Numerous kernel developers feel that loading non-GPL drivers into the >> kernel violates the license of the kernel and their copyright. Because >> of this, a one year notice for everyone to address any non-GPL >> compatible modules has been set. > > Btw, I really think this is shortsighted. > > It will only result in _exactly_ the crap we were just trying to avoid, > namely stupid "shell game" drivers that don't actually help anything at > all, and move code into user space instead. I don't think pushing the drivers into userspace is a good idea at all, that wasn't what I was getting at. Pushing the problem into a different space doesn't fix it. IMHO, we're not a microkernel, and drivers for hardware belong in the kernel. Whether we allow binary kernel modules or not, I don't think we should allow an API for userspace drivers - obviously that's not my call, it's yours, but at least I don't want my opinion / intent misinterpreted. > What was the point again? > > Was the point to alienate people by showing how we're less about the > technology than about licenses? The point of banning binary drivers would be to leverage hardware companies into either releasing open source drivers, or the specs for someone else to write them. Whether we have that much leverage is debatable ... I suspect we do in some cases and not in others. It'll cause some pain, as well as some gain, but I think we'd live through it pretty well, personally. The details of the legal minutiae are, I feel, less interesting than what goal we want to acheive. If we decided to get rid of binary drivers, we could likely find a way to achieve that. Is it a worthwhile goal? I've done both Linux support, where binary drivers are involved, before, as well as supporting Sequent's Dynix/PTX in the face of a similar situation with CA Unicenter. It makes life extremely difficult, if not impossible for a support organisation, for fairly obvious and well known reasons. When there are two binary drivers from different vendors in there, any semblence of support becomes farcical. The Ubuntu feisty fawn mess was a dangerous warning bell of where we're going. If we don't stand up at some point, and ban binary drivers, we will, I fear, end up with an unsustainable ecosystem for Linux when binary drivers become pervasive. I don't want to see Linux destroyed like that. I don't think the motive behind what we decide to do should be decided by legal stuff, though I'm sure we'd have to wade through that to implement it. It's not about that ... it's about what kind of ecosystem we want to create, and whether that can be successful or not. Indeed, there are good arguments both for and against binary drivers on that basis. But please can we have the pragmatic argument about what we want to achieve, and why ... rather than the legal / religious arguments about licenses? The law is a tool, not an end in itself. If you don't feel it's legitimate to leverage that tool to achieve a pragmatic end, fair enough. But please don't assume that the motivation was legal / religious, at least not on my part. Perhaps, in the end, we will decide we'd like to ban binary drivers, but can't. Either for pragmatic reasons (e.g. we don't have enough leverage to create the hardware support base), or for legal ones (we don't think it's enforcable). But we seem to be muddled between those different reasons right now, at least it seems that way to me. I think allowing binary hardware drivers in userspace hurts our ability to leverage companies to release hardware specs. The 'grey water' of binary kernel drivers convinces a lot of them to release stuff, and Greg and others have pushed that cause, all credit to them. In one way, it does make the kernel easier to support, but I don't think it really helps much to make a supportable *system*. M. ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 5:39 ` Martin J. Bligh @ 2006-12-14 6:01 ` Hua Zhong 2006-12-14 11:14 ` Alan 2006-12-14 8:03 ` James Morris ` (2 subsequent siblings) 3 siblings, 1 reply; 239+ messages in thread From: Hua Zhong @ 2006-12-14 6:01 UTC (permalink / raw) To: 'Martin J. Bligh', 'Linus Torvalds' Cc: 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel > I think allowing binary hardware drivers in userspace hurts > our ability to leverage companies to release hardware specs. If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 6:01 ` Hua Zhong @ 2006-12-14 11:14 ` Alan 2006-12-14 11:31 ` Hans-Jürgen Koch 0 siblings, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 11:14 UTC (permalink / raw) To: Hua Zhong Cc: 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel On Wed, 13 Dec 2006 22:01:15 -0800 "Hua Zhong" <hzhong@gmail.com> wrote: > > I think allowing binary hardware drivers in userspace hurts > > our ability to leverage companies to release hardware specs. > > If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground? The FUSE file system interface provides a clean disciplined interface which allows an fs to live in user space. The uio layer (if its ever fixed and cleaned up) provides some basic hooks that allow a user space program to arbitarily control hardware and make a nasty undebuggable mess. uio also doesn't handle hotplug, pci and other "small" matters. Now if you wanted to make uio useful at minimum you would need - PCI support - The ability to mark sets of I/O addresses for the card as "unmappable", "read only", "read-write", "any read/root write", "root read/write" - A proper IRQ handler - A DMA interface - The ability to describe sharing rules Which actually is a description of the core of the DRM layer. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 11:14 ` Alan @ 2006-12-14 11:31 ` Hans-Jürgen Koch 2006-12-14 12:42 ` Alan 0 siblings, 1 reply; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 11:31 UTC (permalink / raw) To: Alan Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel Am Donnerstag, 14. Dezember 2006 12:14 schrieb Alan: > On Wed, 13 Dec 2006 22:01:15 -0800 > "Hua Zhong" <hzhong@gmail.com> wrote: > > > > I think allowing binary hardware drivers in userspace hurts > > > our ability to leverage companies to release hardware specs. > > > > If filesystems can be in user space, why can't drivers be in user space? On what *technical* ground? > > The FUSE file system interface provides a clean disciplined interface > which allows an fs to live in user space. The uio layer (if its ever > fixed and cleaned up) provides some basic hooks that allow a user space > program to arbitarily control hardware and make a nasty undebuggable mess. You think it's easier for a manufacturer of industrial IO cards to debug a (large) kernel module? > > uio also doesn't handle hotplug, pci and other "small" matters. uio is supposed to be a very thin layer. Hotplug and PCI are already handled by other subsystems. > > Now if you wanted to make uio useful at minimum you would need > The majority of industrial IO cards have registers and/or dual port RAM that can be mapped to user space (even today). We want to add a simple way to handle interrupts for such cards. That's all. The fact that there might be some sort of hardware/interrupts/situations where this is not possible or not so simple isn't that important at the moment. We can extend the UIO system if somebody actually requires these extensions. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 11:31 ` Hans-Jürgen Koch @ 2006-12-14 12:42 ` Alan 2006-12-14 12:54 ` Hans-Jürgen Koch 2006-12-14 12:55 ` Jan Engelhardt 0 siblings, 2 replies; 239+ messages in thread From: Alan @ 2006-12-14 12:42 UTC (permalink / raw) To: Hans-Jürgen Koch Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel On Thu, 14 Dec 2006 12:31:16 +0100 Hans-Jürgen Koch <hjk@linutronix.de> wrote: > You think it's easier for a manufacturer of industrial IO cards to > debug a (large) kernel module? You think its any easier to debug because the code now runs in ring 3 but accessing I/O space. > > uio also doesn't handle hotplug, pci and other "small" matters. > > uio is supposed to be a very thin layer. Hotplug and PCI are already > handled by other subsystems. And if you have a PCI or a hotplug card ? How many industrial I/O cards are still ISA btw ? Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 12:42 ` Alan @ 2006-12-14 12:54 ` Hans-Jürgen Koch 2006-12-14 16:59 ` Greg KH 2006-12-14 12:55 ` Jan Engelhardt 1 sibling, 1 reply; 239+ messages in thread From: Hans-Jürgen Koch @ 2006-12-14 12:54 UTC (permalink / raw) To: Alan Cc: Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan: > On Thu, 14 Dec 2006 12:31:16 +0100 > Hans-Jürgen Koch <hjk@linutronix.de> wrote: > > You think it's easier for a manufacturer of industrial IO cards to > > debug a (large) kernel module? > > You think its any easier to debug because the code now runs in ring 3 but > accessing I/O space. For the intended audience, yes. > > > > > uio also doesn't handle hotplug, pci and other "small" matters. > > > > uio is supposed to be a very thin layer. Hotplug and PCI are already > > handled by other subsystems. > > And if you have a PCI or a hotplug card ? How many industrial I/O cards > are still ISA btw ? Who is talking about ISA? All cards we had in mind are PCI. Of course you have to do the usual initialization work in your probe/release or init/exit functions. These are just a few lines you find in any beginners device-driver-writing book. I don't think that the UIO framework could simplify that in a sensible way. Hans ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 12:54 ` Hans-Jürgen Koch @ 2006-12-14 16:59 ` Greg KH 2006-12-14 18:26 ` Alan 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-14 16:59 UTC (permalink / raw) To: Hans-J??rgen Koch Cc: Alan, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel On Thu, Dec 14, 2006 at 01:54:24PM +0100, Hans-J??rgen Koch wrote: > Am Donnerstag, 14. Dezember 2006 13:42 schrieb Alan: > > > > uio also doesn't handle hotplug, pci and other "small" matters. > > > > > > uio is supposed to be a very thin layer. Hotplug and PCI are already > > > handled by other subsystems. > > > > And if you have a PCI or a hotplug card ? How many industrial I/O cards > > are still ISA btw ? > > Who is talking about ISA? All cards we had in mind are PCI. Of course > you have to do the usual initialization work in your probe/release or > init/exit functions. These are just a few lines you find in any > beginners device-driver-writing book. I don't think that the UIO > framework could simplify that in a sensible way. Agreed, you still have to write a kernel driver to handle the pci probe/disconnect functions and the pci id stuff to use the uio core properly. That's not in question here at all and please don't think that uio even attempts to handle this, as that is not what it's job is. Think of uio as just a "class" of driver, like input or v4l. It's still up to the driver writer to provide a proper bus interface to the hardware (pci, usb, etc.) in order for the device to work at all. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:59 ` Greg KH @ 2006-12-14 18:26 ` Alan 2006-12-14 21:16 ` Greg KH 0 siblings, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 18:26 UTC (permalink / raw) To: Greg KH Cc: Hans-J??rgen Koch, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel > Think of uio as just a "class" of driver, like input or v4l. It's still > up to the driver writer to provide a proper bus interface to the > hardware (pci, usb, etc.) in order for the device to work at all. Understood. That leads me to ask another question of the folks who deal with a lot of these cards. How many could reasonably be described by the following bar to map, offset, length, ro/rw, root/user, local-offset (x n ?) interrupt function or null It seems if we have a lot of this kind of card that all fit that pattern it might actually get more vendors submitting updates if we had a single pci driver that took a struct of the above as the device_id field so vendors had to write five lines of IRQ code, a struct and update a PCI table ? That seems to have mostly worked with all the parallel/serial boards. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:26 ` Alan @ 2006-12-14 21:16 ` Greg KH 0 siblings, 0 replies; 239+ messages in thread From: Greg KH @ 2006-12-14 21:16 UTC (permalink / raw) To: Alan Cc: Hans-J??rgen Koch, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel On Thu, Dec 14, 2006 at 06:26:26PM +0000, Alan wrote: > > Think of uio as just a "class" of driver, like input or v4l. It's still > > up to the driver writer to provide a proper bus interface to the > > hardware (pci, usb, etc.) in order for the device to work at all. > > Understood. That leads me to ask another question of the folks who deal > with a lot of these cards. How many could reasonably be described by the > following > > bar to map, offset, length, ro/rw, root/user, local-offset > (x n ?) > interrupt function or null > > It seems if we have a lot of this kind of card that all fit that pattern > it might actually get more vendors submitting updates if we had a single > pci driver that took a struct of the above as the device_id field so > vendors had to write five lines of IRQ code, a struct and update a PCI > table ? That seems to have mostly worked with all the parallel/serial > boards. I think that something like this might work out, and it would be a good goal to get there eventually. But I would like to see a few drivers using the uio core to see where we can consolidate things like this first. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 12:42 ` Alan 2006-12-14 12:54 ` Hans-Jürgen Koch @ 2006-12-14 12:55 ` Jan Engelhardt 2006-12-14 13:10 ` Arjan van de Ven 1 sibling, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 12:55 UTC (permalink / raw) To: Alan Cc: Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 749 bytes --] On Dec 14 2006 12:42, Alan wrote: >On Thu, 14 Dec 2006 12:31:16 +0100 >Hans-Jürgen Koch <hjk@linutronix.de> wrote: >> You think it's easier for a manufacturer of industrial IO cards to >> debug a (large) kernel module? > >You think its any easier to debug because the code now runs in ring 3 but >accessing I/O space. A NULL fault won't oops the system, but of course the wrong inb/inw/inl() or outb* can fubar the machine. >> > uio also doesn't handle hotplug, pci and other "small" matters. >> >> uio is supposed to be a very thin layer. Hotplug and PCI are already >> handled by other subsystems. > >And if you have a PCI or a hotplug card ? How many industrial I/O cards >are still ISA btw ? Something called PC104 out there. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 12:55 ` Jan Engelhardt @ 2006-12-14 13:10 ` Arjan van de Ven 2006-12-14 17:17 ` Jan Engelhardt 0 siblings, 1 reply; 239+ messages in thread From: Arjan van de Ven @ 2006-12-14 13:10 UTC (permalink / raw) To: Jan Engelhardt Cc: Alan, Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote: > On Dec 14 2006 12:42, Alan wrote: > >On Thu, 14 Dec 2006 12:31:16 +0100 > >Hans-Jürgen Koch <hjk@linutronix.de> wrote: > >> You think it's easier for a manufacturer of industrial IO cards to > >> debug a (large) kernel module? > > > >You think its any easier to debug because the code now runs in ring 3 but > >accessing I/O space. > > A NULL fault won't oops the system, .. except when the userspace driver crashes as a result and then the hw still crashes the hw (for example via an irq storm or by tying the PCI bus or .. ) ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 13:10 ` Arjan van de Ven @ 2006-12-14 17:17 ` Jan Engelhardt 2006-12-17 10:54 ` Geert Uytterhoeven 0 siblings, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:17 UTC (permalink / raw) To: Arjan van de Ven Cc: Alan, Hans-Jürgen Koch, Hua Zhong, 'Martin J. Bligh', 'Linus Torvalds', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Michael K. Edwards', linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 768 bytes --] On Dec 14 2006 14:10, Arjan van de Ven wrote: >On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote: >> >On Thu, 14 Dec 2006 12:31:16 +0100 >> >Hans-Jürgen Koch wrote: >> > >> >You think its any easier to debug because the code now runs in ring 3 but >> >accessing I/O space. >> >> A NULL fault won't oops the system, > >.. except when the userspace driver crashes as a result and then the hw >still crashes the hw (for example via an irq storm or by tying the PCI >bus or .. ) hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers (dangling references f.ex.) However, if the userspace part is dead, no one acknowledges the irq, hence an irq storm (if not caused by writing bogus stuff into registers) should not happen. > > -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:17 ` Jan Engelhardt @ 2006-12-17 10:54 ` Geert Uytterhoeven 0 siblings, 0 replies; 239+ messages in thread From: Geert Uytterhoeven @ 2006-12-17 10:54 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Linux Kernel Development [-- Attachment #1: Type: TEXT/PLAIN, Size: 1156 bytes --] On Thu, 14 Dec 2006, Jan Engelhardt wrote: > On Dec 14 2006 14:10, Arjan van de Ven wrote: > >On Thu, 2006-12-14 at 13:55 +0100, Jan Engelhardt wrote: > >> >On Thu, 14 Dec 2006 12:31:16 +0100 > >> >Hans-Jürgen Koch wrote: > >> > > >> >You think its any easier to debug because the code now runs in ring 3 but > >> >accessing I/O space. > >> > >> A NULL fault won't oops the system, > > > >.. except when the userspace driver crashes as a result and then the hw > >still crashes the hw (for example via an irq storm or by tying the PCI > >bus or .. ) > > hw crashes the hw? Anyway, yes it might happen, the more with non-NULL pointers > (dangling references f.ex.) > However, if the userspace part is dead, no one acknowledges the irq, hence an > irq storm (if not caused by writing bogus stuff into registers) should not > happen. Shared level IRQ? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 5:39 ` Martin J. Bligh 2006-12-14 6:01 ` Hua Zhong @ 2006-12-14 8:03 ` James Morris 2006-12-14 15:39 ` Adrian Bunk 2006-12-14 13:07 ` Dave Jones 2006-12-14 14:12 ` Ben Collins 3 siblings, 1 reply; 239+ messages in thread From: James Morris @ 2006-12-14 8:03 UTC (permalink / raw) To: Martin J. Bligh Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Wed, 13 Dec 2006, Martin J. Bligh wrote: > The point of banning binary drivers would be to leverage hardware > companies into either releasing open source drivers, or the specs for > someone else to write them. IMHO, it's up to the users to decide if they want to keep buying hardware which leads to inferior support, less reliability, decreased security and all of the other ills associated with binary drivers. Let them also choose distributions which enact the binary driver policies they agree with. Linux is precisely not about forcing people to do things. - James -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 8:03 ` James Morris @ 2006-12-14 15:39 ` Adrian Bunk 2006-12-14 20:08 ` David Schwartz 0 siblings, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 15:39 UTC (permalink / raw) To: James Morris Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 03:03:10AM -0500, James Morris wrote: > On Wed, 13 Dec 2006, Martin J. Bligh wrote: > > > The point of banning binary drivers would be to leverage hardware > > companies into either releasing open source drivers, or the specs for > > someone else to write them. > > IMHO, it's up to the users to decide if they want to keep buying hardware > which leads to inferior support, less reliability, decreased security and > all of the other ills associated with binary drivers. Let them also > choose distributions which enact the binary driver policies they agree > with. >... Unfortunately, we are living in an economic system with the strong tendency to create oligopolys. Situations with only 1-3 manufacturers you can choose from are quite common (consider e.g. the 3D graphics market). If you aren't a big company with big market power but a simple costumer who needs such hardware you have zero choice if all manufactorers only offer binary-only drivers at best. And there's also the common misconception all costumers had enough information when buying something. If you are a normal Linux user and buy some hardware labelled "runs under Linux", it could turn out that's with a Windows driver running under ndiswrapper... > - James cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:39 ` Adrian Bunk @ 2006-12-14 20:08 ` David Schwartz 2006-12-15 14:05 ` Paolo Ornati 2006-12-17 10:11 ` Geert Uytterhoeven 0 siblings, 2 replies; 239+ messages in thread From: David Schwartz @ 2006-12-14 20:08 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > And there's also the common misconception all costumers had enough > information when buying something. If you are a normal Linux user and > buy some hardware labelled "runs under Linux", it could turn out that's > with a Windows driver running under ndiswrapper... That is something that I think is well worth fixing. Doesn't Linus own the trademark 'Linux'? How about some rules for use of that trademark and a 'Works with Linux' logo that can only be used if the hardware specifications are provided? Let them provide a closed-source driver if they want. Let them provide user-space applications for which no source is provided if they want. But don't let them use the logo unless they release sufficient information to allow people to develop their own drivers and applications to interface with the hardware. That makes it clear that it's not about giving us the fruits of years of your own work but that it's about enabling us to do our own work. (I would have no objection to also requiring them to provide a minimal open-source driver. I'm not trying to work out the exact terms here, just get the idea out.) DS ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 20:08 ` David Schwartz @ 2006-12-15 14:05 ` Paolo Ornati 2006-12-17 10:11 ` Geert Uytterhoeven 1 sibling, 0 replies; 239+ messages in thread From: Paolo Ornati @ 2006-12-15 14:05 UTC (permalink / raw) To: davids; +Cc: Linux-Kernel@Vger. Kernel. Org On Thu, 14 Dec 2006 12:08:11 -0800 "David Schwartz" <davids@webmaster.com> wrote: > > That is something that I think is well worth fixing. Doesn't Linus own the > trademark 'Linux'? How about some rules for use of that trademark and a > 'Works with Linux' logo that can only be used if the hardware specifications > are provided? > > Let them provide a closed-source driver if they want. Let them provide > user-space applications for which no source is provided if they want. But > don't let them use the logo unless they release sufficient information to > allow people to develop their own drivers and applications to interface with > the hardware. This is the same I think, but not Linux specific: http://wiki.duskglow.com/tiki-index.php?page=Open+Hardware+Foundation ------------------------------------------------------------------ P. Mc Namara 12 Jul 06: about the OHF foundation providing "certificates" for hardware, I'd propose (...) levels. * First, any company that pledges full and complete interface and behavioral documentation for a device, any docs necessary to make the device do everything it is designed to do, and makes it publicly available under nothing more cumbersome than the basic copyright that exists on all written works receives one certificate. Somebody else used "community friendly" or something similar. I don't know what to call it. Perhaps just "Open Documentation" (...) * A company that contributes back to the community during the development of a device get labeled "Community Supporter" or something similar. * A company that enters into a legal agreement to release the entire RTL and supporting information for a project at a given point in the future (far enough ahead to protect the companies commercial viability) can get the "Open Hardware" certificate. ------------------------------------------------------------------ -- Paolo Ornati Linux 2.6.18 on x86_64 ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 20:08 ` David Schwartz 2006-12-15 14:05 ` Paolo Ornati @ 2006-12-17 10:11 ` Geert Uytterhoeven 2006-12-17 10:56 ` Rafael J. Wysocki ` (2 more replies) 1 sibling, 3 replies; 239+ messages in thread From: Geert Uytterhoeven @ 2006-12-17 10:11 UTC (permalink / raw) To: David Schwartz; +Cc: Linux-Kernel@Vger. Kernel. Org On Thu, 14 Dec 2006, David Schwartz wrote: > > And there's also the common misconception all costumers had enough > > information when buying something. If you are a normal Linux user and > > buy some hardware labelled "runs under Linux", it could turn out that's > > with a Windows driver running under ndiswrapper... > > That is something that I think is well worth fixing. Doesn't Linus own the > trademark 'Linux'? How about some rules for use of that trademark and a > 'Works with Linux' logo that can only be used if the hardware specifications > are provided? Exactly my thoughts... > Let them provide a closed-source driver if they want. Let them provide > user-space applications for which no source is provided if they want. But > don't let them use the logo unless they release sufficient information to > allow people to develop their own drivers and applications to interface with > the hardware. > > That makes it clear that it's not about giving us the fruits of years of > your own work but that it's about enabling us to do our own work. (I would > have no objection to also requiring them to provide a minimal open-source > driver. I'm not trying to work out the exact terms here, just get the idea > out.) Since `works with' may sound a bit too vague, something like `LinuxFriendly(tm)', with a happy penguin logo? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 10:11 ` Geert Uytterhoeven @ 2006-12-17 10:56 ` Rafael J. Wysocki 2006-12-19 12:57 ` Marek Wawrzyczny 2006-12-20 4:27 ` Steven Rostedt 2 siblings, 0 replies; 239+ messages in thread From: Rafael J. Wysocki @ 2006-12-17 10:56 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: David Schwartz, Linux-Kernel@Vger. Kernel. Org On Sunday, 17 December 2006 11:11, Geert Uytterhoeven wrote: > On Thu, 14 Dec 2006, David Schwartz wrote: > > > And there's also the common misconception all costumers had enough > > > information when buying something. If you are a normal Linux user and > > > buy some hardware labelled "runs under Linux", it could turn out that's > > > with a Windows driver running under ndiswrapper... > > > > That is something that I think is well worth fixing. Doesn't Linus own the > > trademark 'Linux'? How about some rules for use of that trademark and a > > 'Works with Linux' logo that can only be used if the hardware specifications > > are provided? > > Exactly my thoughts... > > > Let them provide a closed-source driver if they want. Let them provide > > user-space applications for which no source is provided if they want. But > > don't let them use the logo unless they release sufficient information to > > allow people to develop their own drivers and applications to interface with > > the hardware. > > > > That makes it clear that it's not about giving us the fruits of years of > > your own work but that it's about enabling us to do our own work. (I would > > have no objection to also requiring them to provide a minimal open-source > > driver. I'm not trying to work out the exact terms here, just get the idea > > out.) > > Since `works with' may sound a bit too vague, something like > `LinuxFriendly(tm)', with a happy penguin logo? I like this idea. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 10:11 ` Geert Uytterhoeven 2006-12-17 10:56 ` Rafael J. Wysocki @ 2006-12-19 12:57 ` Marek Wawrzyczny 2006-12-19 13:56 ` Diego Calleja 2006-12-20 5:11 ` Valdis.Kletnieks 2006-12-20 4:27 ` Steven Rostedt 2 siblings, 2 replies; 239+ messages in thread From: Marek Wawrzyczny @ 2006-12-19 12:57 UTC (permalink / raw) To: linux-kernel On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: > Since `works with' may sound a bit too vague, something like > `LinuxFriendly(tm)', with a happy penguin logo? It would be really cool to see penguin logos on hardware :) I had another, probably crazy idea. Would it be possible to utilize the current vendor/device PCI ID database to create Linux friendliness matrix site? And if you let yourself get carried away, you can also imagine a little multi-platform utility. It would run on a test system collecting PCI IDs before submitting them to the site to get the system's overall Linux friendliness rating. In cases where the system contains devices which do not have entries in the database, the system could look up and use the vendor's Linux friendliness rating. Something like that could really help end users to select the right system and would reward those who do the right thing. Cheers, Marek Wawrzyczny ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 12:57 ` Marek Wawrzyczny @ 2006-12-19 13:56 ` Diego Calleja 2006-12-19 16:46 ` Gene Heskett 2006-12-20 5:11 ` Valdis.Kletnieks 1 sibling, 1 reply; 239+ messages in thread From: Diego Calleja @ 2006-12-19 13:56 UTC (permalink / raw) To: Marek Wawrzyczny; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 484 bytes --] El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <marekw1977@yahoo.com.au> escribió: > I had another, probably crazy idea. Would it be possible to utilize the > current vendor/device PCI ID database to create Linux friendliness matrix > site? I've a script (attached) that looks into /lib/modules/`uname -r`/modules.pcimap, looks up the IDs in the pci id database and print the real name. At least it shows it's possible to know what devices are supported ... [-- Attachment #2: list-kernel-hardware.py --] [-- Type: text/x-python, Size: 2278 bytes --] #!/usr/bin/python def pciids_to_names(ids): # Only the last four numbers of the ids have useful info vendorid = ids[1][6:10] deviceid = ids[2][6:10] subvendorid = ids[3][6:10] subdeviceid = ids[4][6:10] result = [ids[0], "", "", "", "", ""] pciids = open('/usr/share/misc/pci.ids', 'r') # Search for vendor for line in pciids: if line[0] == "#" or line[0] == "C" or line[0] == "\t": continue if line[0:4] == vendorid: result[1] = line[6:].strip() # Vendor name break if result[1] == "": # Vendor not found return result # Search for a device for line in pciids: if line[0] != "\t": continue if line[1:5] == deviceid: result[2] = line[7:].strip() # Device name break # Search a subsystem name for line in pciids: if line[2:11] == subvendorid + " " + subdeviceid: # subsystem name result[3] = line[12:].strip() # The subvendor and subdevice ids point to a _single_ subsystem name break # Search a class name if ids[5][4:6] == "00" and ids[5][6:8] == "00" and ids[5][6:8] == "00": pass # void class ids else: pciids.seek(0) # Search a class name for line in pciids: if line[0] == "C": if line[2:4] == ids[5][4:6]: # found class result[4] = line[6:].strip() # appended class name break if result[4] == "": # class not found return result # Search subclass name for line in pciids: if line [1:3] == ids[5][6:8]: result[5] = line[5:].strip() break return result ### Start of the code flow ### import platform pcimap = open('/lib/modules/' + platform.uname()[2] + '/modules.pcimap', 'r') previousmodule = "" for line in pcimap: if line[0] == "#" or line[0] == " ": continue data = line.split(None) ret = pciids_to_names(data) if ret[0] != previousmodule: previousmodule = ret[0] print "Driver: " + previousmodule if ret[2] == "": output = "\tDevice NOT found in the pciid database: " + repr(data) else: output = "\tDevice: " + ret[2] + " (deviceid " + data[2][6:] + "); made by " + ret[1] + " (vendorid " + data[1][6:] + ")" if ret[3] != "": output += "; Subsystem: " + ret[3] + " (subsysid " + data[3][6:] + ":" + data[4][6:] + ")" if ret[4] != "": output += "; Class: " + ret[4] if ret[5] != "": output += "; Subclass: " + ret[5] print output ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 13:56 ` Diego Calleja @ 2006-12-19 16:46 ` Gene Heskett 2006-12-19 17:11 ` Bill Nottingham 2006-12-19 17:13 ` Diego Calleja 0 siblings, 2 replies; 239+ messages in thread From: Gene Heskett @ 2006-12-19 16:46 UTC (permalink / raw) To: linux-kernel; +Cc: Diego Calleja, Marek Wawrzyczny On Tuesday 19 December 2006 08:56, Diego Calleja wrote: >El Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny <marekw1977@yahoo.com.au> escribió: >> I had another, probably crazy idea. Would it be possible to utilize >> the current vendor/device PCI ID database to create Linux friendliness >> matrix site? > >I've a script (attached) that looks into /lib/modules/`uname > -r`/modules.pcimap, looks up the IDs in the pci id database and print > the real name. At least it shows it's possible to know what devices are > supported ... FWIW: [root@coyote src]# python list-kernel-hardware.py Traceback (most recent call last): File "list-kernel-hardware.py", line 70, in ? ret = pciids_to_names(data) File "list-kernel-hardware.py", line 11, in pciids_to_names pciids = open('/usr/share/misc/pci.ids', 'r') IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids' That file apparently doesn't exist on an FC6 i686 system -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 16:46 ` Gene Heskett @ 2006-12-19 17:11 ` Bill Nottingham 2006-12-19 17:24 ` Gene Heskett 2006-12-19 17:13 ` Diego Calleja 1 sibling, 1 reply; 239+ messages in thread From: Bill Nottingham @ 2006-12-19 17:11 UTC (permalink / raw) To: Gene Heskett; +Cc: linux-kernel, Diego Calleja, Marek Wawrzyczny Gene Heskett (gene.heskett@verizon.net) said: > FWIW: > [root@coyote src]# python list-kernel-hardware.py > Traceback (most recent call last): > File "list-kernel-hardware.py", line 70, in ? > ret = pciids_to_names(data) > File "list-kernel-hardware.py", line 11, in pciids_to_names > pciids = open('/usr/share/misc/pci.ids', 'r') > IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids' > > That file apparently doesn't exist on an FC6 i686 system s/misc/hwdata/ for FC and derivatives. Bill ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 17:11 ` Bill Nottingham @ 2006-12-19 17:24 ` Gene Heskett 0 siblings, 0 replies; 239+ messages in thread From: Gene Heskett @ 2006-12-19 17:24 UTC (permalink / raw) To: linux-kernel; +Cc: Bill Nottingham, Diego Calleja, Marek Wawrzyczny On Tuesday 19 December 2006 12:11, Bill Nottingham wrote: >Gene Heskett (gene.heskett@verizon.net) said: >> FWIW: >> [root@coyote src]# python list-kernel-hardware.py >> Traceback (most recent call last): >> File "list-kernel-hardware.py", line 70, in ? >> ret = pciids_to_names(data) >> File "list-kernel-hardware.py", line 11, in pciids_to_names >> pciids = open('/usr/share/misc/pci.ids', 'r') >> IOError: [Errno 2] No such file or directory: >> '/usr/share/misc/pci.ids' >> >> That file apparently doesn't exist on an FC6 i686 system > >s/misc/hwdata/ for FC and derivatives. > >Bill Ah, thanks. Verbose isn't it? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 16:46 ` Gene Heskett 2006-12-19 17:11 ` Bill Nottingham @ 2006-12-19 17:13 ` Diego Calleja 1 sibling, 0 replies; 239+ messages in thread From: Diego Calleja @ 2006-12-19 17:13 UTC (permalink / raw) To: Gene Heskett; +Cc: linux-kernel, Marek Wawrzyczny El Tue, 19 Dec 2006 11:46:30 -0500, Gene Heskett <gene.heskett@verizon.net> escribió: > IOError: [Errno 2] No such file or directory: '/usr/share/misc/pci.ids' > > That file apparently doesn't exist on an FC6 i686 system Indeed, I forgot to document that. Ubuntu has it there (package pciutils), and update-pciids updates the file from http://pciids.sourceforge.net/pci.ids. So you can download that file and change the path in the script. Anyway, you can find the output at http://www.terra.es/personal/diegocg/list.txt ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-19 12:57 ` Marek Wawrzyczny 2006-12-19 13:56 ` Diego Calleja @ 2006-12-20 5:11 ` Valdis.Kletnieks 2006-12-20 19:29 ` David Schwartz 2006-12-21 15:34 ` Marek Wawrzyczny 1 sibling, 2 replies; 239+ messages in thread From: Valdis.Kletnieks @ 2006-12-20 5:11 UTC (permalink / raw) To: Marek Wawrzyczny; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 2828 bytes --] On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said: > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: > > Since `works with' may sound a bit too vague, something like > > `LinuxFriendly(tm)', with a happy penguin logo? > > It would be really cool to see penguin logos on hardware :) The little Microsoft flag sticker that was on my Dell Latitude got replaced with a sticker that has a Tux and 'linux inside' on it. :) > I had another, probably crazy idea. Would it be possible to utilize the > current vendor/device PCI ID database to create Linux friendliness matrix > site? > > And if you let yourself get carried away, you can also imagine a little > multi-platform utility. It would run on a test system collecting PCI IDs > before submitting them to the site to get the system's overall Linux > friendliness rating. This is a can of worms, and then some. For instance, let's consider this Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's not the default graphics card on a Latitude D820. So what number do you put in? Do you use: a) the *default* graphics card b) the one *I* have with the open-source driver c) the same one, but with the NVidia binary driver? (Remember that "users" have different criteria than "developers" - most users would consider this entire thread "intellectual wanking", especially since the patch that spawned it got withdrawn. And 'Frames Per Second' trumps that stupid little 'P' in the oops message. Failure to understand this mindset guarantees that your computation of a "friendliness rating" is yet more intellectual wanking... ;) Similar issues are involved with the wireless card - the Intel 3945 I have isn't the default. Repeat for several different disk options, and at least 4 or 5 different CD/ROM/DVD options. Add in the fact that Dell often changes suppliers for disk and CD/DVD drives, and you have a nightmare coming... And then there's stuff on this machine that are *not* options, but don't matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have no idea how well it works. I don't care what it contributes to the score. On the other hand, somebody who uses external Firewire disk enclosures may be *very* concerned about it, but not care in the slightest about the wireless card. Bonus points for figuring out what to do with systems that have some chip that's a supported XYZ driver, but wired up behind a squirrely bridge with some totally bizarre IRQ allocation, so you end up with something that's visible on lspci but not actually *usable* in any real sense of the term... > Something like that could really help end users to select the right system and > would reward those who do the right thing. "You are trapped in a maze of twisty little configurations, all different..." [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-20 5:11 ` Valdis.Kletnieks @ 2006-12-20 19:29 ` David Schwartz 2006-12-20 20:52 ` Valdis.Kletnieks 2006-12-21 15:34 ` Marek Wawrzyczny 1 sibling, 1 reply; 239+ messages in thread From: David Schwartz @ 2006-12-20 19:29 UTC (permalink / raw) To: Marek Wawrzyczny, valdis.kletnietks; +Cc: linux-kernel > This is a can of worms, and then some. For instance, let's consider this > Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. > However, that's > not the default graphics card on a Latitude D820. So what number do you > put in? Do you use: > a) the *default* graphics card > b) the one *I* have with the open-source driver > c) the same one, but with the NVidia binary driver? > Similar issues are involved with the wireless card - the Intel 3945 I > have isn't the default. Repeat for several different disk options, and > at least 4 or 5 different CD/ROM/DVD options. Add in the fact that Dell > often changes suppliers for disk and CD/DVD drives, and you have > a nightmare > coming... > And then there's stuff on this machine that are *not* options, but don't > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have > no idea how well it works. I don't care what it contributes to the score. > On the other hand, somebody who uses external Firewire disk enclosures may > be *very* concerned about it, but not care in the slightest about > the wireless > card. > > Bonus points for figuring out what to do with systems that have some chip > that's a supported XYZ driver, but wired up behind a squirrely bridge with > some totally bizarre IRQ allocation, so you end up with something that's > visible on lspci but not actually *usable* in any real sense of > the term... Let's not let the perfect be the enemy of the good. Remember, the goal is to allow consumers to know whether or not their system's hardware specifications are available. It's not about driver availability -- if the hardware specifications are available and a driver is not, that's not the hardware manufacturer's fault. Linux is about *allowing* people to do things. DS ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-20 19:29 ` David Schwartz @ 2006-12-20 20:52 ` Valdis.Kletnieks 2006-12-20 21:10 ` alan 0 siblings, 1 reply; 239+ messages in thread From: Valdis.Kletnieks @ 2006-12-20 20:52 UTC (permalink / raw) To: davids; +Cc: Marek Wawrzyczny, valdis.kletnietks, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2080 bytes --] On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said: > Let's not let the perfect be the enemy of the good. Remember, the goal is to > allow consumers to know whether or not their system's hardware > specifications are available. It's not about driver availability -- if the > hardware specifications are available and a driver is not, that's not the > hardware manufacturer's fault. My point was "their system's hardware specifications" is, for some popular vendors, a *very* fuzzy notion. You can't (for instance) say "specs are available for a Dell Latitude D820" - there are configurations that specs are available for, and configs that aren't. My D820 has an NVidia card in it - we know the answer there. Do you give a different answer for a D820 that has the Intel i950 graphics chipset instead? Even more annoying, Dell often *changes* the vendor - the line item for the DVD drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD). Mine showed up with a Philips SDVD8820 - but it's possible that some other D820 will get some other vendor's DVD (I've seen 2 C820's ordered at the same time, they showed up with 2 different vendor's "24X CD-RW/DVD"). It's possible that some poor guy is going to get a D820 that has a DVD that we have a known buggy driver for - what do we tell *them*? It's *easy* to do a "semi-good" that tells you if there's drivers for the hardware config you're running the program on. But there's 2 problems: a) You probably already know the answer b) By the time you can run the program, it's often too late.... So given those 2 points, what actual value-added info does this *give*, over and above 'lspci' and friends? I suppose maybe for a install CD, it gives a quick way to cleanly abort the install with a "Don't bother continuing unless it's OK that your graphics/wireless/whatever won't work". On the other hand, the installer should have a grasp on this *already*.... Perfect may be the enemy of the good, but the good is also the enemy of stuff claiming to be good but misses on an important design goal... [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-20 20:52 ` Valdis.Kletnieks @ 2006-12-20 21:10 ` alan 0 siblings, 0 replies; 239+ messages in thread From: alan @ 2006-12-20 21:10 UTC (permalink / raw) To: Valdis.Kletnieks Cc: davids, Marek Wawrzyczny, valdis.kletnietks, linux-kernel On Wed, 20 Dec 2006, Valdis.Kletnieks@vt.edu wrote: > On Wed, 20 Dec 2006 11:29:00 PST, David Schwartz said: > >> Let's not let the perfect be the enemy of the good. Remember, the goal is to >> allow consumers to know whether or not their system's hardware >> specifications are available. It's not about driver availability -- if the >> hardware specifications are available and a driver is not, that's not the >> hardware manufacturer's fault. > > My point was "their system's hardware specifications" is, for some popular > vendors, a *very* fuzzy notion. You can't (for instance) say "specs are > available for a Dell Latitude D820" - there are configurations that specs are > available for, and configs that aren't. My D820 has an NVidia card in it - we > know the answer there. Do you give a different answer for a D820 that has the > Intel i950 graphics chipset instead? > > Even more annoying, Dell often *changes* the vendor - the line item for the DVD > drive says "8X DVD+/-RW" (other choices include 24X CD-ROM and 24X CD-RW/DVD). > Mine showed up with a Philips SDVD8820 - but it's possible that some other D820 > will get some other vendor's DVD (I've seen 2 C820's ordered at the same time, > they showed up with 2 different vendor's "24X CD-RW/DVD"). It's possible that > some poor guy is going to get a D820 that has a DVD that we have a known > buggy driver for - what do we tell *them*? > > It's *easy* to do a "semi-good" that tells you if there's drivers for the > hardware config you're running the program on. But there's 2 problems: > > a) You probably already know the answer > b) By the time you can run the program, it's often too late.... > > So given those 2 points, what actual value-added info does this *give*, over > and above 'lspci' and friends? I suppose maybe for a install CD, it gives > a quick way to cleanly abort the install with a "Don't bother continuing > unless it's OK that your graphics/wireless/whatever won't work". On the > other hand, the installer should have a grasp on this *already*.... > > Perfect may be the enemy of the good, but the good is also the enemy of > stuff claiming to be good but misses on an important design goal... Valid points, but they are almost more for the distribution than they are for the kernel. I have considered designing a routine for use in Annaconda or some other installer that lists all the known hardware and how much of it will actually work with that particular distro. I know some people will not care, but many will. (Especially the people who ask "Will my machine work with Linux".) Many people do not know what they have in the way of hardware. They bought a machine. What they were sold (or requested) and what they got are usually two different things. They may know a few specifics, but they are probably missing important details. (How many people know the model of PCI chip in their machine? Or who made the IDE chipset? Or the ethernet chipset on the motherboard?) For those of us that deal with hardware every day, this is not as big of an issue as those who bought something from Dell or HP and it arrived in a big box pre-assembled. Is there some way to look at a kernel and determine what drivers are "good" and those that are "less good"? (Other than ordering Alan Cox's brain in a jar...) What needs to be known is the state of the driver for kernel X where X maybe something current or woefully out of date. Maybe instead of an EXPORT_GPL symbol we need a EXPORT_THIS_DRIVER_IS_CRAP symbol. -- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25 ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-20 5:11 ` Valdis.Kletnieks 2006-12-20 19:29 ` David Schwartz @ 2006-12-21 15:34 ` Marek Wawrzyczny 2006-12-21 16:43 ` Horst H. von Brand 2006-12-21 19:28 ` Valdis.Kletnieks 1 sibling, 2 replies; 239+ messages in thread From: Marek Wawrzyczny @ 2006-12-21 15:34 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: linux-kernel On Wednesday 20 December 2006 16:11, Valdis.Kletnieks@vt.edu wrote: > On Tue, 19 Dec 2006 23:57:45 +1100, Marek Wawrzyczny said: > > On Sunday 17 December 2006 21:11, Geert Uytterhoeven wrote: > > And if you let yourself get carried away, you can also imagine a little > > multi-platform utility. It would run on a test system collecting PCI IDs > > before submitting them to the site to get the system's overall Linux > > friendliness rating. > > This is a can of worms, and then some. For instance, let's consider this > Latitude. *THIS* one has an NVidia Quadro NVS 110M in it. However, that's > not the default graphics card on a Latitude D820. So what number do you > put in? Do you use: No, no, no... I was never proposing that. I was thinking of something more along the lines of reporting back on open-source friendliness of manufacturers of devices, and perhaps on the availability of open source drivers for the devices. I am talking only about "detected" devices. The database would never try and guess the vendor, model and variation of the system. > (Remember that "users" have different criteria than "developers" - most > users would consider this entire thread "intellectual wanking", especially > since the patch that spawned it got withdrawn. And 'Frames Per Second' > trumps that stupid little 'P' in the oops message. Failure to understand > this mindset guarantees that your computation of a "friendliness rating" > is yet more intellectual wanking... ;) I actually find that trying to obtain information about what hardware is/isn't supported in Linux is actually quite difficult to obtain. The information that's on the internet is either outdated or has not yet been written. I was hoping to analyze the system's device information together with driver/device information obtained from the kernel source itself to give users a better (but not perhaps not as authoritative as I'd like to) picture of what to expect. > And then there's stuff on this machine that are *not* options, but don't > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have > no idea how well it works. I don't care what it contributes to the score. > On the other hand, somebody who uses external Firewire disk enclosures may > be *very* concerned about it, but not care in the slightest about the > wireless card. Perhaps we just report on the individual devices then... forget the system rating. > Bonus points for figuring out what to do with systems that have some chip > that's a supported XYZ driver, but wired up behind a squirrely bridge with > some totally bizarre IRQ allocation, so you end up with something that's > visible on lspci but not actually *usable* in any real sense of the term... Hmmm... does this happen often? False results are definedly a show stopper. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-21 15:34 ` Marek Wawrzyczny @ 2006-12-21 16:43 ` Horst H. von Brand 2006-12-21 19:28 ` Valdis.Kletnieks 1 sibling, 0 replies; 239+ messages in thread From: Horst H. von Brand @ 2006-12-21 16:43 UTC (permalink / raw) To: Marek Wawrzyczny; +Cc: Valdis.Kletnieks, linux-kernel Marek Wawrzyczny <marekw1977@yahoo.com.au> wrote: [...] > No, no, no... I was never proposing that. I was thinking of something more > along the lines of reporting back on open-source friendliness of > manufacturers of devices, and perhaps on the availability of open source > drivers for the devices. I am talking only about "detected" devices. The > database would never try and guess the vendor, model and variation of the > system. This is a /massive/ ammount of effort, and the data required is hard to come by before buying, so it is rather useless. What chip is in NetworkCard 675? In 675a? (yes, I've seen dLink cards called <foo> and <foo>+ which were /radically/ different!). Yes, here you go to the computer store and ask them to build you a machine from parts you specify. But it is far from the common way to get a PC (those stores mostly cater to heavy-weight gamers, many pieces have to be special ordered), and building a machine that works OK with Linux is a two or three day exercise in hunting down specifications for compatible pieces. Most folks wander into the next department store and buy a PC. Mostly terrible crap, BTW. Where this makes sense (printers!) the data is there, mostly up to date, and accurate. [...] > I actually find that trying to obtain information about what hardware > is/isn't supported in Linux is actually quite difficult to obtain. The > information that's on the internet is either outdated or has not yet been > written. I was hoping to analyze the system's device information > together with driver/device information obtained from the kernel source > itself to give users a better (but not perhaps not as authoritative as > I'd like to) picture of what to expect. There is just way too much hardware out there, and new pieces come out every day. Then there are lots of integrators that buy chips and build PCI cards. Sometimes cards with supported chips just don't work at all. Etc. It is all over the map. Besides, many times you don't find information on some piece of hardware it is because it is dirt cheap stuff that has no chance of working, so nobody even tried. [...] > > Bonus points for figuring out what to do with systems that have some chip > > that's a supported XYZ driver, but wired up behind a squirrely bridge with > > some totally bizarre IRQ allocation, so you end up with something that's > > visible on lspci but not actually *usable* in any real sense of the term... > Hmmm... does this happen often? False results are definedly a show > stopper. Not just for systems, even for individual cards. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-21 15:34 ` Marek Wawrzyczny 2006-12-21 16:43 ` Horst H. von Brand @ 2006-12-21 19:28 ` Valdis.Kletnieks 2006-12-24 3:11 ` Horst H. von Brand 1 sibling, 1 reply; 239+ messages in thread From: Valdis.Kletnieks @ 2006-12-21 19:28 UTC (permalink / raw) To: Marek Wawrzyczny; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1558 bytes --] On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said: > > > And then there's stuff on this machine that are *not* options, but don't > > matter to me. I see an 'O2 Micro' Firewire in the 'lspci' output. I have > > no idea how well it works. I don't care what it contributes to the score. > > On the other hand, somebody who uses external Firewire disk enclosures may > > be *very* concerned about it, but not care in the slightest about the > > wireless card. > > Perhaps we just report on the individual devices then... forget the system > rating. OK, *that* I see as potentially useful - I frequently get handed older boxen with strange gear in them, and need a way to figure out if I want to install software, or cannibalize it for parts. Also helpful if a buddy has a Frankintel box they build, and they want to know if they can install something other than Windows.... Bonus points if it sees a card that has a known out-of-tree driver and tells you where to find it and what its license status is (I just went down that road with an Intel 3945)... > > Bonus points for figuring out what to do with systems that have some chip > > that's a supported XYZ driver, but wired up behind a squirrely bridge with > > some totally bizarre IRQ allocation, so you end up with something that's > > visible on lspci but not actually *usable* in any real sense of the term... > > Hmmm... does this happen often? False results are definedly a show stopper. Oh, we see reports of squirrelly or downright confused hardware all the time on this list. :) [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-21 19:28 ` Valdis.Kletnieks @ 2006-12-24 3:11 ` Horst H. von Brand 0 siblings, 0 replies; 239+ messages in thread From: Horst H. von Brand @ 2006-12-24 3:11 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: Marek Wawrzyczny, linux-kernel Valdis.Kletnieks@vt.edu wrote: > On Fri, 22 Dec 2006 02:34:54 +1100, Marek Wawrzyczny said: [...] > > Perhaps we just report on the individual devices then... forget the system > > rating. > OK, *that* I see as potentially useful - I frequently get handed older > boxen with strange gear == gear for which there is probably no documentation at all > in them, and need a way to figure out if I want to > install software, LiveCD of your choice... > or cannibalize it for parts. Also helpful if a buddy has > a Frankintel box they build, and they want to know if they can install > something other than Windows.... Same as above. > Bonus points if it sees a card that has a known out-of-tree driver and > tells you where to find it and what its license status is (I just went > down that road with an Intel 3945)... If in-tree driver is already a challange, out-of-tree is hopeless. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 10:11 ` Geert Uytterhoeven 2006-12-17 10:56 ` Rafael J. Wysocki 2006-12-19 12:57 ` Marek Wawrzyczny @ 2006-12-20 4:27 ` Steven Rostedt 2 siblings, 0 replies; 239+ messages in thread From: Steven Rostedt @ 2006-12-20 4:27 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: David Schwartz, Linux-Kernel@Vger. Kernel. Org On Sun, 2006-12-17 at 11:11 +0100, Geert Uytterhoeven wrote: > On Thu, 14 Dec 2006, David Schwartz wrote: > > That makes it clear that it's not about giving us the fruits of years of > > your own work but that it's about enabling us to do our own work. (I would > > have no objection to also requiring them to provide a minimal open-source > > driver. I'm not trying to work out the exact terms here, just get the idea > > out.) > > Since `works with' may sound a bit too vague, something like > `LinuxFriendly(tm)', with a happy penguin logo? > I've bought a couple of products lately that had the happy penguin logo on it. Just to find out that they only applied a bare minimum functionality of the device for Linux. If you want more, you need to plug it into a Windows box. Funny, if you own a Mac, it had the same problem. It had a little more functionality than the Linux port, but still far from what they give for Windows. I like the Open Hardware thing that Paolo mentioned. -- Steve ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 5:39 ` Martin J. Bligh 2006-12-14 6:01 ` Hua Zhong 2006-12-14 8:03 ` James Morris @ 2006-12-14 13:07 ` Dave Jones 2006-12-14 15:05 ` Adrian Bunk ` (2 more replies) 2006-12-14 14:12 ` Ben Collins 3 siblings, 3 replies; 239+ messages in thread From: Dave Jones @ 2006-12-14 13:07 UTC (permalink / raw) To: Martin J. Bligh Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote: > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're > going. If we don't stand up at some point, and ban binary drivers, we > will, I fear, end up with an unsustainable ecosystem for Linux when > binary drivers become pervasive. I don't want to see Linux destroyed > like that. Thing is, if kernel.org kernels get patched to disallow binary modules, whats to stop Ubuntu (or anyone else) reverting that change in the kernels they distribute ? The landscape doesn't really change much, given that the majority of Linux end-users are probably running distro kernels. Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 13:07 ` Dave Jones @ 2006-12-14 15:05 ` Adrian Bunk 2006-12-14 16:11 ` Dave Jones 2006-12-14 15:36 ` Martin J. Bligh 2006-12-14 17:20 ` Jan Engelhardt 2 siblings, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 15:05 UTC (permalink / raw) To: Dave Jones, Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote: > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote: > > > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're > > going. If we don't stand up at some point, and ban binary drivers, we > > will, I fear, end up with an unsustainable ecosystem for Linux when > > binary drivers become pervasive. I don't want to see Linux destroyed > > like that. > > Thing is, if kernel.org kernels get patched to disallow binary modules, > whats to stop Ubuntu (or anyone else) reverting that change in the > kernels they distribute ? The landscape doesn't really change much, > given that the majority of Linux end-users are probably running > distro kernels. If a kernel developer or a competitor sends a cease&desist letter to such a distribution, the situation changes from a complicated "derived work" discussion to a relatively clear "They circumvented a technical measure to enforce the copyright.". > Dave cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:05 ` Adrian Bunk @ 2006-12-14 16:11 ` Dave Jones 2006-12-14 16:31 ` Olivier Galibert 0 siblings, 1 reply; 239+ messages in thread From: Dave Jones @ 2006-12-14 16:11 UTC (permalink / raw) To: Adrian Bunk Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote: > On Thu, Dec 14, 2006 at 08:07:04AM -0500, Dave Jones wrote: > > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote: > > > > Thing is, if kernel.org kernels get patched to disallow binary modules, > > whats to stop Ubuntu (or anyone else) reverting that change in the > > kernels they distribute ? The landscape doesn't really change much, > > given that the majority of Linux end-users are probably running > > distro kernels. > > If a kernel developer or a competitor sends a cease&desist letter to > such a distribution, the situation changes from a complicated "derived > work" discussion to a relatively clear "They circumvented a technical > measure to enforce the copyright.". C&D's don't work that way. They can enforce "don't ship my code" but not "ship my code, or else". The modification would be just like any other thats allowable by the GPL. Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:11 ` Dave Jones @ 2006-12-14 16:31 ` Olivier Galibert 0 siblings, 0 replies; 239+ messages in thread From: Olivier Galibert @ 2006-12-14 16:31 UTC (permalink / raw) To: Dave Jones, Adrian Bunk, Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 11:11:33AM -0500, Dave Jones wrote: > On Thu, Dec 14, 2006 at 04:05:14PM +0100, Adrian Bunk wrote: > > If a kernel developer or a competitor sends a cease&desist letter to > > such a distribution, the situation changes from a complicated "derived > > work" discussion to a relatively clear "They circumvented a technical > > measure to enforce the copyright.". > > C&D's don't work that way. They can enforce "don't ship my code" > but not "ship my code, or else". The modification would be just like > any other thats allowable by the GPL. Careful here. The "technical measure" protection is something unrelated to the copyright license itself. Cf the streambox vcr lawsuit for instance (settled though) where not implementing the handling of one bit that said "don't save to disk" in original code seemed to be illegal. OG. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 13:07 ` Dave Jones 2006-12-14 15:05 ` Adrian Bunk @ 2006-12-14 15:36 ` Martin J. Bligh 2006-12-14 17:20 ` Jan Engelhardt 2 siblings, 0 replies; 239+ messages in thread From: Martin J. Bligh @ 2006-12-14 15:36 UTC (permalink / raw) To: Dave Jones, Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Dave Jones wrote: > On Wed, Dec 13, 2006 at 09:39:11PM -0800, Martin J. Bligh wrote: > > > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're > > going. If we don't stand up at some point, and ban binary drivers, we > > will, I fear, end up with an unsustainable ecosystem for Linux when > > binary drivers become pervasive. I don't want to see Linux destroyed > > like that. > > Thing is, if kernel.org kernels get patched to disallow binary modules, > whats to stop Ubuntu (or anyone else) reverting that change in the > kernels they distribute ? The landscape doesn't really change much, > given that the majority of Linux end-users are probably running > distro kernels. I don't think they'd dare spit in our faces quite that directly. They think binary modules are permissible because we don't seem to have consistently stated an intent contradicting that - some individual developers have, but ultimately Linus hasn't. I'm not talking about any legal issues to do with derived works, copyrights or licenses - a clear statement of intent is probably all it'd take to tip the balance. M. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 13:07 ` Dave Jones 2006-12-14 15:05 ` Adrian Bunk 2006-12-14 15:36 ` Martin J. Bligh @ 2006-12-14 17:20 ` Jan Engelhardt 2 siblings, 0 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:20 UTC (permalink / raw) To: Dave Jones Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel > > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're > > going. If we don't stand up at some point, and ban binary drivers, we > > will, I fear, end up with an unsustainable ecosystem for Linux when > > binary drivers become pervasive. I don't want to see Linux destroyed > > like that. > >Thing is, if kernel.org kernels get patched to disallow binary modules, >whats to stop Ubuntu (or anyone else) reverting that change in the >kernels they distribute ? The landscape doesn't really change much, >given that the majority of Linux end-users are probably running >distro kernels. And even if the distros don't change it (all legal issues aside), there's probably some free user who repacks the distro kernel. /me eyeballs myself... -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 5:39 ` Martin J. Bligh ` (2 preceding siblings ...) 2006-12-14 13:07 ` Dave Jones @ 2006-12-14 14:12 ` Ben Collins 2006-12-14 15:10 ` James Courtier-Dutton ` (2 more replies) 3 siblings, 3 replies; 239+ messages in thread From: Ben Collins @ 2006-12-14 14:12 UTC (permalink / raw) To: Martin J. Bligh Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Wed, 2006-12-13 at 21:39 -0800, Martin J. Bligh wrote: > The Ubuntu feisty fawn mess was a dangerous warning bell of where we're > going. If we don't stand up at some point, and ban binary drivers, we > will, I fear, end up with an unsustainable ecosystem for Linux when > binary drivers become pervasive. I don't want to see Linux destroyed > like that. Yes, people have been worried about this for years, and to my knowledge, it seems like things have been getting better with drivers, not worse (look at Intel). And yet, people want to enforce more and more restrictions against binary-only drivers, when it appears that we are already winning. You can't talk about drivers that don't exist for Linux. Things like bcm43xx aren't effected by this new restriction for GPL-only drivers. There's no binary-only driver for it (ndiswrapper doesn't count). If the hardware vendor doesn't want to write a driver for linux, you can't make them. You can buy other hardware, but that's about it. Here's the list of proprietary drivers that are in Ubuntu's restricted modules package: madwifi (closed hal implementation, being replaced in openhal) fritz ati nvidia ltmodem (does that even still work?) ipw3945d (not a kernel module, but just the daemon) In over a year that list has only grown by ipw3945d. None of our users are asking for new proprietary drivers. Believe me, if they needed them, I'd hear about it. We have more cases of new unsupported hardware than we do of new hardware with binary-only drivers. This proposed restriction doesn't fix that. You know what I think hurts us more than anything? You know what probably keeps companies from writing drivers or releasing specs? It's because they know some non-paid kernel hackers out there will eventually reverse engineer it and write the drivers for them. Free development, and they didn't even have to release their precious specs. Don't get me wrong, I'm not bashing reverse engineering, or writing our own drivers. It's how Linux got started. But the problem isn't as narrow as people would like to think. And proprietary code isn't a growing problem. At best, it's just a distraction that will eventually go away on it's own. The whole hardware vendor landscape is showing this, and it's not because we locked down the kernel, it's because we've shown how well we play with others, and how easy it is to get along with the whole community. Do we want to destroy this good will? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:12 ` Ben Collins @ 2006-12-14 15:10 ` James Courtier-Dutton 2006-12-14 16:09 ` Dave Jones 2006-12-14 16:36 ` Ben Collins 2006-12-14 17:34 ` Jan Engelhardt 2006-12-14 19:29 ` Michael Buesch 2 siblings, 2 replies; 239+ messages in thread From: James Courtier-Dutton @ 2006-12-14 15:10 UTC (permalink / raw) To: Ben Collins Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Ben Collins wrote: > > Here's the list of proprietary drivers that are in Ubuntu's restricted > modules package: > > madwifi (closed hal implementation, being replaced in openhal) > fritz > ati > nvidia > ltmodem (does that even still work?) > ipw3945d (not a kernel module, but just the daemon) > More items will be added to that list soon. E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007. http://opensource.creative.com/ > In over a year that list has only grown by ipw3945d. None of our users > are asking for new proprietary drivers. Believe me, if they needed them, > I'd hear about it. We have more cases of new unsupported hardware than > we do of new hardware with binary-only drivers. This proposed > restriction doesn't fix that. Is there a list of "new unsupported hardware" ? Reverse engineering or datasheets is the only way out of that. As Linux becomes more and more popular on the desktop, manufacturers will start feeling the pain of Linux "unsupported hardware" and have to back down and release datasheets. Ubuntu is helping a lot in that direction. > > You know what I think hurts us more than anything? You know what > probably keeps companies from writing drivers or releasing specs? It's > because they know some non-paid kernel hackers out there will eventually > reverse engineer it and write the drivers for them. Free development, > and they didn't even have to release their precious specs. Well, once a device has been reverse engineered and GPLed, the specs are then in public domain and the IP does not exist any more. It actually helps the company release the specs once the information is already out there. The company then sees less reason to hold onto their specs in the first place, and tends to release them earlier next time. > > Don't get me wrong, I'm not bashing reverse engineering, or writing our > own drivers. It's how Linux got started. But the problem isn't as narrow > as people would like to think. And proprietary code isn't a growing > problem. At best, it's just a distraction that will eventually go away > on it's own. > I agree, as time goes by, more and more devices are reverse engineered or the manufacturer finally sees sense and releases the specs/datasheets. James ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:10 ` James Courtier-Dutton @ 2006-12-14 16:09 ` Dave Jones 2006-12-14 16:36 ` Ben Collins 1 sibling, 0 replies; 239+ messages in thread From: Dave Jones @ 2006-12-14 16:09 UTC (permalink / raw) To: James Courtier-Dutton Cc: Ben Collins, Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 03:10:57PM +0000, James Courtier-Dutton wrote: > More items will be added to that list soon. > E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007. > http://opensource.creative.com/ Wow. That wins 'most ironic hostname' award for 2006. Thankfully onboard hardware is "good enough" for most end-users these days, leaving just the high-end audio professionals in the lurch. Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:10 ` James Courtier-Dutton 2006-12-14 16:09 ` Dave Jones @ 2006-12-14 16:36 ` Ben Collins 1 sibling, 0 replies; 239+ messages in thread From: Ben Collins @ 2006-12-14 16:36 UTC (permalink / raw) To: James Courtier-Dutton Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, 2006-12-14 at 15:10 +0000, James Courtier-Dutton wrote: > Ben Collins wrote: > > > > Here's the list of proprietary drivers that are in Ubuntu's restricted > > modules package: > > > > madwifi (closed hal implementation, being replaced in openhal) > > fritz > > ati > > nvidia > > ltmodem (does that even still work?) > > ipw3945d (not a kernel module, but just the daemon) > > > > More items will be added to that list soon. > E.g. Linux Binary only, Creative X-Fi sound card drivers for Q2 2007. > http://opensource.creative.com/ I haven't even caught wind of this not being supported yet. No demand == no reason to include it when it does become available. > > In over a year that list has only grown by ipw3945d. None of our users > > are asking for new proprietary drivers. Believe me, if they needed them, > > I'd hear about it. We have more cases of new unsupported hardware than > > we do of new hardware with binary-only drivers. This proposed > > restriction doesn't fix that. > > Is there a list of "new unsupported hardware" ? > Reverse engineering or datasheets is the only way out of that. > As Linux becomes more and more popular on the desktop, manufacturers > will start feeling the pain of Linux "unsupported hardware" and have to > back down and release datasheets. Ubuntu is helping a lot in that direction. I've not kept a list. Would be non-trivial to go through the bug tracker to find this info. Mostly it's things like webcams, and wacky little hardware that starts cropping up in laptops. > > > > You know what I think hurts us more than anything? You know what > > probably keeps companies from writing drivers or releasing specs? It's > > because they know some non-paid kernel hackers out there will eventually > > reverse engineer it and write the drivers for them. Free development, > > and they didn't even have to release their precious specs. > > Well, once a device has been reverse engineered and GPLed, the specs are > then in public domain and the IP does not exist any more. It actually > helps the company release the specs once the information is already out > there. The company then sees less reason to hold onto their specs in the > first place, and tends to release them earlier next time. Right, I think reverse engineering does help in that aspect. The other aspect is that they now have a driver that sort of works for their hardware. Most of the work is done, and they decide to help things along to make it stable. So laying ground work like this can have advantages. I think hardware vendors are a lot like users. Once they see the advantages to opening up their drivers, they wonder why they didn't do it a long time ago. Sort of like how users need that one push to use Linux, and they start to wonder why they should go back to Windows. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:12 ` Ben Collins 2006-12-14 15:10 ` James Courtier-Dutton @ 2006-12-14 17:34 ` Jan Engelhardt 2006-12-14 19:29 ` Michael Buesch 2 siblings, 0 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:34 UTC (permalink / raw) To: Ben Collins Cc: Martin J. Bligh, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel >You know what I think hurts us more than anything? You know what >probably keeps companies from writing drivers or releasing specs? It's >because they know some non-paid kernel hackers out there will eventually >reverse engineer it and write the drivers for them. Free development, >and they didn't even have to release their precious specs. I don't get them either. If reverse-engineering will release their precious trade secrets they wanted to protect by making the thing closed, they could have just asked someone to write a linux driver for free if they don't have the guts to actually pay qualified/experienced developers. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:12 ` Ben Collins 2006-12-14 15:10 ` James Courtier-Dutton 2006-12-14 17:34 ` Jan Engelhardt @ 2006-12-14 19:29 ` Michael Buesch 2006-12-14 20:19 ` Ben Collins 2 siblings, 1 reply; 239+ messages in thread From: Michael Buesch @ 2006-12-14 19:29 UTC (permalink / raw) To: Ben Collins Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel, Martin J. Bligh On Thursday 14 December 2006 15:12, Ben Collins wrote: > You can't talk about drivers that don't exist for Linux. Things like > bcm43xx aren't effected by this new restriction for GPL-only drivers. > There's no binary-only driver for it (ndiswrapper doesn't count). If the > hardware vendor doesn't want to write a driver for linux, you can't make > them. You can buy other hardware, but that's about it. Not that is matters in this discussion, but there are binary Broadcom 43xx drivers for linux available. > Here's the list of proprietary drivers that are in Ubuntu's restricted > modules package: > > madwifi (closed hal implementation, being replaced in openhal) > fritz Well, that's not just one, right? That's like, 10 or so for the different AVM cards. I'm just estimating. Correct me, if I'm wrong. (And if I didn't mention it yet; AVM binary drivers are complete crap.) > ati > nvidia > ltmodem (does that even still work?) > ipw3945d (not a kernel module, but just the daemon) > Don't get me wrong, I'm not bashing reverse engineering, or writing our > own drivers. It's how Linux got started. But the problem isn't as narrow > as people would like to think. And proprietary code isn't a growing > problem. At best, it's just a distraction that will eventually go away > on it's own. Well, I _hope_ that, too. -- Greetings Michael. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:29 ` Michael Buesch @ 2006-12-14 20:19 ` Ben Collins 0 siblings, 0 replies; 239+ messages in thread From: Ben Collins @ 2006-12-14 20:19 UTC (permalink / raw) To: Michael Buesch Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel, Martin J. Bligh On Thu, 2006-12-14 at 20:29 +0100, Michael Buesch wrote: > On Thursday 14 December 2006 15:12, Ben Collins wrote: > > You can't talk about drivers that don't exist for Linux. Things like > > bcm43xx aren't effected by this new restriction for GPL-only drivers. > > There's no binary-only driver for it (ndiswrapper doesn't count). If the > > hardware vendor doesn't want to write a driver for linux, you can't make > > them. You can buy other hardware, but that's about it. > > Not that is matters in this discussion, but there are binary Broadcom > 43xx drivers for linux available. > > > Here's the list of proprietary drivers that are in Ubuntu's restricted > > modules package: > > > > madwifi (closed hal implementation, being replaced in openhal) > > fritz > > Well, that's not just one, right? > That's like, 10 or so for the different AVM cards. > I'm just estimating. Correct me, if I'm wrong. One driver, many variations of the chipset. That's true of most drivers. > (And if I didn't mention it yet; AVM binary drivers are > complete crap.) Wont disagree with you there. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 5:39 ` Martin J. Bligh @ 2006-12-14 7:24 ` Jeffrey V. Merkey 2006-12-14 8:21 ` David Woodhouse ` (7 subsequent siblings) 9 siblings, 0 replies; 239+ messages in thread From: Jeffrey V. Merkey @ 2006-12-14 7:24 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Well said, and I agree with ALL of your statements contained in this post. About damn time this was addressed. Jeff Linus Torvalds wrote: >On Wed, 13 Dec 2006, Greg KH wrote: > > >>Numerous kernel developers feel that loading non-GPL drivers into the >>kernel violates the license of the kernel and their copyright. Because >>of this, a one year notice for everyone to address any non-GPL >>compatible modules has been set. >> >> > >Btw, I really think this is shortsighted. > >It will only result in _exactly_ the crap we were just trying to avoid, >namely stupid "shell game" drivers that don't actually help anything at >all, and move code into user space instead. > >What was the point again? > >Was the point to alienate people by showing how we're less about the >technology than about licenses? > >Was the point to show that we think we can extend our reach past derived >work boundaries by just saying so? > >The silly thing is, the people who tend to push most for this are the >exact SAME people who say that the RIAA etc should not be able to tell >people what to do with the music copyrights that they own, and that the >DMCA is bad because it puts technical limits over the rights expressly >granted by copyright law. > >Doesn't anybody else see that as being hypocritical? > >So it's ok when we do it, but bad when other people do it? Somehow I'm not >surprised, but I still think it's sad how you guys are showing a marked >two-facedness about this. > >The fact is, the reason I don't think we should force the issue is very >simple: copyright law is simply _better_off_ when you honor the admittedly >gray issue of "derived work". It's gray. It's not black-and-white. But >being gray is _good_. Putting artificial black-and-white technical >counter-measures is actually bad. It's bad when the RIAA does it, it's bad >when anybody else does it. > >If a module arguably isn't a derived work, we simply shouldn't try to say >that its authors have to conform to our worldview. > >We should make decisions on TECHNICAL MERIT. And this one is clearly being >pushed on anything but. > >I happen to believe that there shouldn't be technical measures that keep >me from watching my DVD or listening to my music on whatever device I damn >well please. Fair use, man. But it should go the other way too: we should >not try to assert _our_ copyright rules on other peoples code that wasn't >derived from ours, or assert _our_ technical measures that keep people >from combining things their way. > >If people take our code, they'd better behave according to our rules. But >we shouldn't have to behave according to the RIAA rules just because we >_listen_ to their music. Similarly, nobody should be forced to behave >according to our rules just because they _use_ our system. > >There's a big difference between "copy" and "use". It's exatcly the same >issue whether it's music or code. You can't re-distribute other peoples >music (becuase it's _their_ copyright), but they shouldn't put limits on >how you personally _use_ it (because it's _your_ life). > >Same goes for code. Copyright is about _distribution_, not about use. We >shouldn't limit how people use the code. > >Oh, well. I realize nobody is likely going to listen to me, and everybody >has their opinion set in stone. > >That said, I'm going to suggest that you people talk to your COMPANY >LAWYERS on this, and I'm personally not going to merge that particular >code unless you can convince the people you work for to merge it first. > >In other words, you guys know my stance. I'll not fight the combined >opinion of other kernel developers, but I sure as hell won't be the first >to merge this, and I sure as hell won't have _my_ tree be the one that >causes this to happen. > >So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees >first. This is not something where we use my tree as a way to get it to >other trees. This is something where the push had better come from the >other direction. > >Because I think it's stupid. So use somebody else than me to push your >political agendas, please. > > Linus >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 5:39 ` Martin J. Bligh 2006-12-14 7:24 ` Jeffrey V. Merkey @ 2006-12-14 8:21 ` David Woodhouse 2006-12-14 11:25 ` Alan ` (2 more replies) 2006-12-14 9:34 ` James Courtier-Dutton ` (6 subsequent siblings) 9 siblings, 3 replies; 239+ messages in thread From: David Woodhouse @ 2006-12-14 8:21 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote: > If a module arguably isn't a derived work, we simply shouldn't try to say > that its authors have to conform to our worldview. I wouldn't argue that _anyone_ else should be exposed to my worldview; I think the Geneva Convention has something to say about cruel and unusual punishments. But I would ask that they honour the licence on the code I release, and perhaps more importantly on the code I import from other GPL sources. If they fail to do that under the 'honour system' then I'm not averse to 'enforcing' it by technical measures. (For some value of 'enforcement' which is easy for them to patch out if their lawyers are _really_ sure they'll win when I sue them, that is.) That's the big difference I see between this and the RIAA case you mention -- in the case of Linux refusing to load non-GPL modules, if the user _really_ thinks they'll win in court they can just hack it to load the offending modules again. We are giving a _very_ strong indication of our intent, but we aren't actually _forcing_ it on them in quite the same way. With DRM-crippled players and hardware it's not so easy to get around. I'm very much in favour of Greg's approach. Give 12 months warning and then just prevent loading of non-GPL modules. That way, we get back from the current "binary modules are the status quo even though some people are currently psyching themselves up to sue for it" to "binary modules are possible if you're _very_ sure of your legal position and willing to defend it". I think that's a very good thing to do. > We should make decisions on TECHNICAL MERIT. And this one is clearly being > pushed on anything but. Not on my part. The thing that makes me _particularly_ vehement about binary-only crap this week is a very much a technical issue -- in particular, the fact that we had to do post-production board modifications to shoot our wireless chip in the head when it goes AWOL, because the code for it wasn't available to us. It's come back time and time again -- closed code is undebuggable, unportable, unimprovable, unworkable. It's a detriment to the whole system. That's very much a _technical_ issue, to me. For non-kernel code I'm happy enough to release what I write under a BSD licence. I'll default to GPL but usually respond favourably to requests to do otherwise. It _isn't_ a religious issue. > Same goes for code. Copyright is about _distribution_, not about use. > We shouldn't limit how people use the code. And we don't need to. Aside from the fact that they can patch out the check if they have a genuine need to, they can also mark their module as GPL without consequences as long as they don't _distribute_ it. We still don't limit their _use_ of it. > Oh, well. I realize nobody is likely going to listen to me, and everybody > has their opinion set in stone. My opinion is fairly much set from all the times I've come up against _technical_ issues, I'll admit. But I did listen, and I agree with what you say about the RIAA 'enforcement'. But I do see that as _very_ different to our 'enforcement', because ours is so easy to patch out it's more of a 'hint' than a lockdown. > That said, I'm going to suggest that you people talk to your COMPANY > LAWYERS on this, and I'm personally not going to merge that particular > code unless you can convince the people you work for to merge it first. We've already merged EXPORT_SYMBOL_GPL. Is there a difference other than one of extent? What about just marking kmalloc as EXPORT_SYMBOL_GPL for a start? :) > In other words, you guys know my stance. I'll not fight the combined > opinion of other kernel developers, but I sure as hell won't be the first > to merge this, and I sure as hell won't have _my_ tree be the one that > causes this to happen. > > So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees > first. This is not something where we use my tree as a way to get it to > other trees. This is something where the push had better come from the > other direction. It's better to have a coherent approach, and for all of us to do it on roughly the same timescale. Getting the distributions do so this is going to be like herding cats -- having it upstream and letting it trickle down is a much better approach, I think. -- dwmw2 ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 8:21 ` David Woodhouse @ 2006-12-14 11:25 ` Alan 2007-01-22 23:37 ` dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]) Oleg Verych 2006-12-14 14:53 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Theodore Tso 2006-12-14 16:52 ` Linus Torvalds 2 siblings, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 11:25 UTC (permalink / raw) To: David Woodhouse Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006 08:21:20 +0000 David Woodhouse <dwmw2@infradead.org> wrote: > If they fail to do that under the 'honour system' then I'm not averse to > 'enforcing' it by technical measures. (For some value of 'enforcement' > which is easy for them to patch out if their lawyers are _really_ sure > they'll win when I sue them, that is.) There are specific rules against removal of technical measures *even if the result is legal*. It is an offence in many countries thanks to the RIAA lobbyists and their corrupt pet politicians to remove technical measures applied to a -public domain- work. So your argument doesn't fly. > Not on my part. The thing that makes me _particularly_ vehement about > binary-only crap this week is a very much a technical issue -- in > particular, the fact that we had to do post-production board > modifications to shoot our wireless chip in the head when it goes AWOL, > because the code for it wasn't available to us. Consider it an education process. Hopefully the contracts for the chips/docs were watertight enough you can sue the offending supplier for the total cost of the rework. If not then you are really complaining about getting contract negotiations wrong. > It's better to have a coherent approach, and for all of us to do it on > roughly the same timescale. Getting the distributions do so this is > going to be like herding cats -- having it upstream and letting it > trickle down is a much better approach, I think. I doubt any distribution but the FSF "purified" Debian (the one that has no firmware so doesn't work) would do it. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]) 2006-12-14 11:25 ` Alan @ 2007-01-22 23:37 ` Oleg Verych 0 siblings, 0 replies; 239+ messages in thread From: Oleg Verych @ 2007-01-22 23:37 UTC (permalink / raw) To: linux-kernel On 2006-12-14, Alan wrote: [] > I doubt any distribution but the FSF "purified" Debian (the one that has > no firmware so doesn't work) would do it. DFSG "purified" Debian[1], please. [1] <http://www.debian.org/social_contract> -- -o--=O C info emacs : not found /. .\ ( is there any reason to live? ) #oo'L O info make : not found o ( yes! -- R.I.P. FSF+RMS, viva ) <___=E M man gcc : not found `-- ( Debian Free Operating System ) ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 8:21 ` David Woodhouse 2006-12-14 11:25 ` Alan @ 2006-12-14 14:53 ` Theodore Tso 2006-12-14 16:52 ` Linus Torvalds 2 siblings, 0 replies; 239+ messages in thread From: Theodore Tso @ 2006-12-14 14:53 UTC (permalink / raw) To: David Woodhouse Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel >But I would ask that they honour the licence on the code I release, and >perhaps more importantly on the code I import from other GPL sources. It's not a question of "honoring the license"; it's a matter of what is the reach of the license, as it relates to derivitive works. It's a complicated subject, and very dependent on the local law; certainly in the U.S., when I asked a Law Professor from the MIT Sloan School of Management, who specialized in IP issues about the FSF theory of GPL contamination by dynamic linking, after I explained all the details of how dynamic linking work, she told me that it would be "laughed out of the courtroom". Now, is that a legal opinion? No, because the facts of every single case are different, and it was an opinion from someone over a decade ago, and case law may have changed (although as far as I know, there has been no court ruling directly on this particular point since then). The bottom line though is that it is not _nearly_ so clear as some people would like to believe. There is a lot of gray --- and that's a GOOD thing. If copyright contamination via dynamic linking was the settled law of the land, then all of the Macintosh extensions that people wrote --- WHICH WORK BY PATCHING THE OPERATING SYSTEM --- would be illegal. And given how much Apple hated people implying that the UI as handed down from the mountain by the great prophet Steve Jobs wasn't good enough, would we really have wanted Apple hounding developers with lawsuits just because "they weren't honoring the license" by daring to patch MacOS, and extending the OS by linking in their code? And what about people who link in a debugger into the Microsoft HAL or other Microsoft DLL's in order to reverse engineer USB drivers for Linux or reverse engineer protocols for Samba --- that's dynamic linking of a sort too --- should that be illegal as well? Imagine the power that Microsoft could put into their EULA if copyright contamination could be as easily achieved by dynamic linking. Please, let's try to have a little sanity here, - Ted ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 8:21 ` David Woodhouse 2006-12-14 11:25 ` Alan 2006-12-14 14:53 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Theodore Tso @ 2006-12-14 16:52 ` Linus Torvalds 2006-12-14 17:33 ` Jeff V. Merkey 2 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 16:52 UTC (permalink / raw) To: David Woodhouse Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006, David Woodhouse wrote: > > But I would ask that they honour the licence on the code I release, and > perhaps more importantly on the code I import from other GPL sources. This is a total non-argument, and it doesn't get any betetr by being mindlessly repeated over and over and over again. The license on the code you released talked about "derived works". Not "everything I want to". If a module owner can argue successfully in a court of law that a binary driver isn't a derived work, then the GPL simply DOES NOT COVER IT! In other words, people CAN "honor the license" and still not be required to put their code under the GPL. And no, including one header file in order to compile against something does not automatically make something a "derived work". It may, or it may not. It really isn't up to you to decide whether it does (and notice how I'm not saying that it's up to _me_ either!). For example, all the same people who clamor for free software get absolutely RABID about "fair use". Guess what "fair use" actually MEANS? Think about it for a moment. It expressly _limits_ the right of copyright authors to claim "derived work". So if you argue that anything that ever includes your header file (but none of your code) and compiles against it is a "derived work", then you are basically very close to arguing that "fair use" does not exist. Do you really want to argue that "everything that has touched anything copyrighted AT ALL is a derived work"? Do you feel lucky, punk? THAT is why I think this discussion is so hypocritical. Either you accept that "fair use" and copyrights aren't black-and-white, or you don't. If you think this is a black-and-white "copyright owners have all the rights", then you're standing with the RIAA's and the MPAA's of the world. Me, personally, I think the RIAA and the MPAA is a shithouse. They are immoral. But guess what? They are immoral exactly _because_ they think that they automatically own ALL the rights, just because they own the copyright. That is what it boils down to: copyright doesn't really give you "absolute power". This is why I have been _consistently_ arguing that we're not about "black and white" or "good against evil". It simply isn't that simple. I don't like binary modules. I refuse to support them, and if it turns out that the module was written using Linux code, and just for Linux, I htink that's a _clear_ copyright violation, and that binary module is obviously a license violation. But if the module was written for other systems, and just ported to Linux, and not using our code, then it's very much debatable whether it's actually a "derived work". Interfaces don't make "derived works" per se. Now, is it something you could sue people over? Sure. I actually do believe that it's very possible that a judge _would_ consider such a module a derived work, and you can sue people. It probably depends on circumstances too. But don't you see the problem with a black-and-white technical measure? Don't you see the problem with the DMCA and the DVD encryption? Those kinds of things REMOVE the "reasonable thought" from the equation, and turn a gradual process into a sharp "right or wrong" situation. AND THAT IS WRONG. We simply do not LIVE in a world that is black and white. So if you think somebody violates your copyright, send them a C&D letter, and eventually take them to court. It's been done. Companies that mis-used the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. I'm not arguing against that at all. What I'm arguing against is the "blind belief" that you or I have the right to tell people what to do, just because we own copyrights. It's not a blind belief that I'm willing to subscribe to. Exactly because I have _seen_ what that blind belief results in - crap like the DMCA and the RIAA lawsuits. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:52 ` Linus Torvalds @ 2006-12-14 17:33 ` Jeff V. Merkey 2006-12-14 18:01 ` Martin J. Bligh 0 siblings, 1 reply; 239+ messages in thread From: Jeff V. Merkey @ 2006-12-14 17:33 UTC (permalink / raw) To: Linus Torvalds Cc: David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Again, I agree with EVERY statement Linus made here. We operate exactly as Linus describes, and legally, NO ONE can take us to task on GPL issues. We post patches of affected kernel code (albiet the code resembles what Linus describes as a "skeleton driver") and our proprietary non derived code we sell with our appliances. He is right, everyone else should just accept it and get on with life or cry linus a river. Jeff Linus Torvalds wrote: >On Thu, 14 Dec 2006, David Woodhouse wrote: > > >>But I would ask that they honour the licence on the code I release, and >>perhaps more importantly on the code I import from other GPL sources. >> >> > >This is a total non-argument, and it doesn't get any betetr by being >mindlessly repeated over and over and over again. > >The license on the code you released talked about "derived works". > >Not "everything I want to". > >If a module owner can argue successfully in a court of law that a binary >driver isn't a derived work, then the GPL simply DOES NOT COVER IT! > >In other words, people CAN "honor the license" and still not be required >to put their code under the GPL. > >And no, including one header file in order to compile against something >does not automatically make something a "derived work". It may, or it may >not. It really isn't up to you to decide whether it does (and notice how >I'm not saying that it's up to _me_ either!). > >For example, all the same people who clamor for free software get >absolutely RABID about "fair use". Guess what "fair use" actually MEANS? > >Think about it for a moment. It expressly _limits_ the right of copyright >authors to claim "derived work". So if you argue that anything that ever >includes your header file (but none of your code) and compiles against it >is a "derived work", then you are basically very close to arguing that >"fair use" does not exist. > >Do you really want to argue that "everything that has touched anything >copyrighted AT ALL is a derived work"? Do you feel lucky, punk? > >THAT is why I think this discussion is so hypocritical. Either you accept >that "fair use" and copyrights aren't black-and-white, or you don't. > >If you think this is a black-and-white "copyright owners have all the >rights", then you're standing with the RIAA's and the MPAA's of the world. > >Me, personally, I think the RIAA and the MPAA is a shithouse. They are >immoral. But guess what? They are immoral exactly _because_ they think >that they automatically own ALL the rights, just because they own the >copyright. > >That is what it boils down to: copyright doesn't really give you "absolute >power". This is why I have been _consistently_ arguing that we're not >about "black and white" or "good against evil". It simply isn't that >simple. > >I don't like binary modules. I refuse to support them, and if it turns out >that the module was written using Linux code, and just for Linux, I htink >that's a _clear_ copyright violation, and that binary module is obviously >a license violation. > >But if the module was written for other systems, and just ported to Linux, >and not using our code, then it's very much debatable whether it's >actually a "derived work". Interfaces don't make "derived works" per se. > >Now, is it something you could sue people over? Sure. I actually do >believe that it's very possible that a judge _would_ consider such a >module a derived work, and you can sue people. It probably depends on >circumstances too. > >But don't you see the problem with a black-and-white technical measure? > >Don't you see the problem with the DMCA and the DVD encryption? > >Those kinds of things REMOVE the "reasonable thought" from the equation, >and turn a gradual process into a sharp "right or wrong" situation. AND >THAT IS WRONG. We simply do not LIVE in a world that is black and white. > >So if you think somebody violates your copyright, send them a C&D letter, >and eventually take them to court. It's been done. Companies that mis-used >the GPL have actually been sued, and THEY HAVE LOST. That's a GOOD thing. >I'm not arguing against that at all. What I'm arguing against is the >"blind belief" that you or I have the right to tell people what to do, >just because we own copyrights. > >It's not a blind belief that I'm willing to subscribe to. Exactly because >I have _seen_ what that blind belief results in - crap like the DMCA and >the RIAA lawsuits. > > Linus > >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:33 ` Jeff V. Merkey @ 2006-12-14 18:01 ` Martin J. Bligh 2006-12-14 18:12 ` Jeff V. Merkey 0 siblings, 1 reply; 239+ messages in thread From: Martin J. Bligh @ 2006-12-14 18:01 UTC (permalink / raw) To: Jeff V. Merkey Cc: Linus Torvalds, David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Jeff V. Merkey wrote: > > Again, I agree with EVERY statement Linus made here. We operate exactly > as Linus describes, and > legally, NO ONE can take us to task on GPL issues. We post patches of > affected kernel code > (albiet the code resembles what Linus describes as a "skeleton driver") > and our proprietary > non derived code we sell with our appliances. Yeah, like this one? ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch @@ -1316,8 +1316,8 @@ mod->license_gplok = license_is_gpl_compatible(license); if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) { - printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", - mod->name, license); +// printk(KERN_WARNING "%s: module license '%s' taints kernel.\n", +// mod->name, license); add_taint(TAINT_PROPRIETARY_MODULE); } } @@ -1691,10 +1691,10 @@ /* Set up license info based on the info section */ set_license(mod, get_modinfo(sechdrs, infoindex, "license")); - if (strcmp(mod->name, "ndiswrapper") == 0) - add_taint(TAINT_PROPRIETARY_MODULE); - if (strcmp(mod->name, "driverloader") == 0) - add_taint(TAINT_PROPRIETARY_MODULE); +// if (strcmp(mod->name, "ndiswrapper") == 0) +// add_taint(TAINT_PROPRIETARY_MODULE); +// if (strcmp(mod->name, "driverloader") == 0) +// add_taint(TAINT_PROPRIETARY_MODULE); /* Set up MODINFO_ATTR fields */ setup_modinfo(mod, sechdrs, infoindex); ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:01 ` Martin J. Bligh @ 2006-12-14 18:12 ` Jeff V. Merkey 2006-12-14 18:37 ` Linus Torvalds 0 siblings, 1 reply; 239+ messages in thread From: Jeff V. Merkey @ 2006-12-14 18:12 UTC (permalink / raw) To: Martin J. Bligh Cc: Linus Torvalds, David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Martin J. Bligh wrote: > Jeff V. Merkey wrote: > >> >> Again, I agree with EVERY statement Linus made here. We operate >> exactly as Linus describes, and >> legally, NO ONE can take us to task on GPL issues. We post patches of >> affected kernel code >> (albiet the code resembles what Linus describes as a "skeleton >> driver") and our proprietary >> non derived code we sell with our appliances. > > > > Yeah, like this one? Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED. Jeff > > ftp://ftp.soleranetworks.com/pub/solera/dsfs/FedoraCore6/datascout-only-2.6.18-11-13-06.patch > > > @@ -1316,8 +1316,8 @@ > > mod->license_gplok = license_is_gpl_compatible(license); > if (!mod->license_gplok && !(tainted & > TAINT_PROPRIETARY_MODULE)) { > - printk(KERN_WARNING "%s: module license '%s' taints > kernel.\n", > - mod->name, license); > +// printk(KERN_WARNING "%s: module license '%s' taints > kernel.\n", > +// mod->name, license); > add_taint(TAINT_PROPRIETARY_MODULE); > } > } > @@ -1691,10 +1691,10 @@ > /* Set up license info based on the info section */ > set_license(mod, get_modinfo(sechdrs, infoindex, "license")); > > - if (strcmp(mod->name, "ndiswrapper") == 0) > - add_taint(TAINT_PROPRIETARY_MODULE); > - if (strcmp(mod->name, "driverloader") == 0) > - add_taint(TAINT_PROPRIETARY_MODULE); > +// if (strcmp(mod->name, "ndiswrapper") == 0) > +// add_taint(TAINT_PROPRIETARY_MODULE); > +// if (strcmp(mod->name, "driverloader") == 0) > +// add_taint(TAINT_PROPRIETARY_MODULE); > > /* Set up MODINFO_ATTR fields */ > setup_modinfo(mod, sechdrs, infoindex); > > ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:12 ` Jeff V. Merkey @ 2006-12-14 18:37 ` Linus Torvalds 2006-12-14 18:30 ` Jeff V. Merkey 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 18:37 UTC (permalink / raw) To: Jeff V. Merkey Cc: Martin J. Bligh, David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006, Jeff V. Merkey wrote: > > Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED. No. That's really a purely technical thing. You can still do whatever you want, but people who support the resulting mess know that they shouldn't. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:37 ` Linus Torvalds @ 2006-12-14 18:30 ` Jeff V. Merkey 0 siblings, 0 replies; 239+ messages in thread From: Jeff V. Merkey @ 2006-12-14 18:30 UTC (permalink / raw) To: Linus Torvalds Cc: Martin J. Bligh, David Woodhouse, Greg KH, Jonathan Corbet, Andrew Morton, Michael K. Edwards, linux-kernel Linus Torvalds wrote: >On Thu, 14 Dec 2006, Jeff V. Merkey wrote: > > >>Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED. >> >> > >No. That's really a purely technical thing. > > > > I'm not certain I understand what you mean here. Nasty messages using the word "taint" is purely subjective. (as is your opinion or anyone else's about the use of the word, including my opinion). Based upon the way the GPL is worded, "taint" actually goes the other way in legal circles when corporate attorneys talk about using GPL code with non-GPL code. i.e. "... If we use that linux code it will TAINT our development process and CONTAMINATE and POULLTE our proprietary development efforts with GPL code and we do not know the IP sources of such code...". You should change it to "non-GPL" rather than "tainted" since the use of this word is actionable and inaccruate of reality. Free GPL code is what it is. The GPL is the only thing that "taints" IP. The use of the word is reversed. Also Linus, we do open source and promote certain projects outside of the Linux Kernel -- and we fully support the GPL. You can still do whatever you want, but people who support the resulting mess know that they shouldn't. BULLSHIT. I diagree and you are talking out of both sides of your mouth. :-) Jeff > Linus > > > ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (2 preceding siblings ...) 2006-12-14 8:21 ` David Woodhouse @ 2006-12-14 9:34 ` James Courtier-Dutton 2006-12-24 11:57 ` Mark Hounschell 2006-12-14 10:49 ` Xavier Bestel ` (5 subsequent siblings) 9 siblings, 1 reply; 239+ messages in thread From: James Courtier-Dutton @ 2006-12-14 9:34 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Linus Torvalds wrote: > > On Wed, 13 Dec 2006, Greg KH wrote: >> Numerous kernel developers feel that loading non-GPL drivers into the >> kernel violates the license of the kernel and their copyright. Because >> of this, a one year notice for everyone to address any non-GPL >> compatible modules has been set. > > Btw, I really think this is shortsighted. > > It will only result in _exactly_ the crap we were just trying to avoid, > namely stupid "shell game" drivers that don't actually help anything at > all, and move code into user space instead. > > What was the point again? > > Was the point to alienate people by showing how we're less about the > technology than about licenses? > > Was the point to show that we think we can extend our reach past derived > work boundaries by just saying so? > > The silly thing is, the people who tend to push most for this are the > exact SAME people who say that the RIAA etc should not be able to tell > people what to do with the music copyrights that they own, and that the > DMCA is bad because it puts technical limits over the rights expressly > granted by copyright law. > > Doesn't anybody else see that as being hypocritical? > > So it's ok when we do it, but bad when other people do it? Somehow I'm not > surprised, but I still think it's sad how you guys are showing a marked > two-facedness about this. > > The fact is, the reason I don't think we should force the issue is very > simple: copyright law is simply _better_off_ when you honor the admittedly > gray issue of "derived work". It's gray. It's not black-and-white. But > being gray is _good_. Putting artificial black-and-white technical > counter-measures is actually bad. It's bad when the RIAA does it, it's bad > when anybody else does it. > > If a module arguably isn't a derived work, we simply shouldn't try to say > that its authors have to conform to our worldview. > > We should make decisions on TECHNICAL MERIT. And this one is clearly being > pushed on anything but. > I agree with Linus on these points. The kernel should not be enforcing these issues. Leave the lawyers to do that bit. If companies want to play in the "Grey Area", then it is at their own risk. Binary drivers are already difficult and expensive for the companies because they have to keep updating them as we change the kernel versions. If they do open source drivers, we update them for them as we change the kernel versions, so it works out cheaper for the companies involved. The open source community tends to be able to reverse engineer all drivers eventually anyway in order to ensure compatibility with all kernel versions and also ensure that the code is well reviewed and therefore contains fewer security loopholes, e.g. Atheros Wireless open source HAL. This also tends to make it rather pointless for companies to do binary drivers, because all it does is delay the open source version of the driver and increase the security risk to users. One other example I have, is that I reverse engineered a sound card driver so that we had an open source driver for it. Once I had manually documented the sound card, so we had details of all the registers and how to use them, the manufacturer finally sent the datasheet to me! A bit late really, but it certainly did encourage the manufacturer to pass datasheets to developers. I now have a large array of datasheets from this manufacturer that save me having to reverse engineer other sound cards in their range. Making binary drivers is therefore not a viable way to protect IP. We are slowly removing the excuses that companies can hide behind as reasons for not releasing datasheets to open source driver developers. James ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 9:34 ` James Courtier-Dutton @ 2006-12-24 11:57 ` Mark Hounschell 2006-12-24 13:22 ` Sean 0 siblings, 1 reply; 239+ messages in thread From: Mark Hounschell @ 2006-12-24 11:57 UTC (permalink / raw) To: James Courtier-Dutton Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel James Courtier-Dutton wrote: > > I agree with Linus on these points. The kernel should not be enforcing > these issues. Leave the lawyers to do that bit. If companies want to > play in the "Grey Area", then it is at their own risk. Binary drivers > are already difficult and expensive for the companies because they have > to keep updating them as we change the kernel versions. If they do open > source drivers, we update them for them as we change the kernel > versions, so it works out cheaper for the companies involved. > Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them for us. The only way that happens is if they can get in the official tree. I know just from monitoring this list that our drivers would never be acceptable for inclusion in any "functional form". We open sourced them purely out of respect for the way we know the community feels about it. It would cost more for us to make them acceptable for inclusion than it does for us to just maintain them ourselves. I suspect that is true for most vendor created drivers open source or not. So kernel developers making the required changes as the kernel changes is NO real incentive for any vendor to open source their drivers. Sorry. If it were knowingly less difficult to actually get your drivers included, that would be an incentive and then you original point would hold as an additional incentive. My humble $.02 worth Regards Mark ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-24 11:57 ` Mark Hounschell @ 2006-12-24 13:22 ` Sean 2006-12-24 14:42 ` Mark Hounschell 0 siblings, 1 reply; 239+ messages in thread From: Sean @ 2006-12-24 13:22 UTC (permalink / raw) To: Mark Hounschell Cc: James Courtier-Dutton, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Sun, 24 Dec 2006 06:57:58 -0500 Mark Hounschell <dmarkh@cfl.rr.com> wrote: > Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them > for us. The only way that happens is if they can get in the official > tree. I know just from monitoring this list that our drivers would never > be acceptable for inclusion in any "functional form". We open sourced > them purely out of respect for the way we know the community feels about > it. That shows some class, thanks. > It would cost more for us to make them acceptable for inclusion than it > does for us to just maintain them ourselves. I suspect that is true for > most vendor created drivers open source or not. > > So kernel developers making the required changes as the kernel changes > is NO real incentive for any vendor to open source their drivers. Sorry. > > If it were knowingly less difficult to actually get your drivers > included, that would be an incentive and then you original point would > hold as an additional incentive. Out of curiosity what specific technical issues in your driver code make you think that it would be too expensive to whip them into shape for inclusion? Cheers, Sean ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-24 13:22 ` Sean @ 2006-12-24 14:42 ` Mark Hounschell 0 siblings, 0 replies; 239+ messages in thread From: Mark Hounschell @ 2006-12-24 14:42 UTC (permalink / raw) To: Sean Cc: James Courtier-Dutton, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Sean wrote: > On Sun, 24 Dec 2006 06:57:58 -0500 > Mark Hounschell <dmarkh@cfl.rr.com> wrote: > > >> Hum. We open sourced our drivers 2 years ago. Now one is 'changing' them >> for us. The only way that happens is if they can get in the official >> tree. I know just from monitoring this list that our drivers would never >> be acceptable for inclusion in any "functional form". We open sourced >> them purely out of respect for the way we know the community feels about >> it. > > That shows some class, thanks. > >> It would cost more for us to make them acceptable for inclusion than it >> does for us to just maintain them ourselves. I suspect that is true for >> most vendor created drivers open source or not. >> >> So kernel developers making the required changes as the kernel changes >> is NO real incentive for any vendor to open source their drivers. Sorry. >> >> If it were knowingly less difficult to actually get your drivers >> included, that would be an incentive and then you original point would >> hold as an additional incentive. > > Out of curiosity what specific technical issues in your driver code make > you think that it would be too expensive to whip them into shape for > inclusion? > > Cheers, > Sean > Well just off the top of my head, one of our drivers directly mucks with all the irq affinities (irq_desc) via a provided user land library call. This single call forces all 'other' irqs to be serviced by all the 'other' processors. I know this would never fly in kernel. User land /proc manipulation is not an option for us here. We have another that absolutely requires the Bigphysarea patch. We refuse to use "MEM=xxxx" and use a fixed address. Every installation would require a special configuration and our 'end users' would have to have some understanding of all that. We are also maintaining that patch internally also. So this product (for full functionality with our not so open source application) requires a special kernel to begin with. Other than that this one might have a chance of inclusion. It only requires the bigphysarea when used with this application. It will actually build and work (basically) with or without it. Another is actually somewhat tied to the one mentioned above in that this one has to facilitate the ability of its card being able to to PIO reads and writes to 'special locations' in userspace and to the SRAM memory of the above card. Even when on different pci busses. I've looked at some of the V4L drivers that also do this sort of thing and I'm confused by how they are doing it so I'm almost certain that what we are doing would be considered 'wrong'. Then there is probably the biggest one of all. The coding style issue. Don't get me wrong I understand and agree with what I've read about it. Our drivers were written by hardware people. Or I should say they were written by OUR hardware people. I can offend them because I am among them. No offense intended to any of you invaluable hardware guys. I see 6 months of full time work before I could even sanely ask what I needed to do for inclusion. It seems easier to just try to keep up with the changes. I'm certain our company is not the only one in this situation. I see many GPL external kernel drivers. Why? Mark ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (3 preceding siblings ...) 2006-12-14 9:34 ` James Courtier-Dutton @ 2006-12-14 10:49 ` Xavier Bestel 2006-12-14 13:04 ` Dave Jones ` (4 subsequent siblings) 9 siblings, 0 replies; 239+ messages in thread From: Xavier Bestel @ 2006-12-14 10:49 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote: > That said, I'm going to suggest that you people talk to your COMPANY > LAWYERS on this, and I'm personally not going to merge that particular > code unless you can convince the people you work for to merge it first. That's quoting material :) Who's your master, by Linus. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (4 preceding siblings ...) 2006-12-14 10:49 ` Xavier Bestel @ 2006-12-14 13:04 ` Dave Jones 2006-12-14 13:46 ` Ben Collins ` (3 subsequent siblings) 9 siblings, 0 replies; 239+ messages in thread From: Dave Jones @ 2006-12-14 13:04 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote: > So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees > first. You don't think I already get enough hatemail from binary-module users ? :) Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (5 preceding siblings ...) 2006-12-14 13:04 ` Dave Jones @ 2006-12-14 13:46 ` Ben Collins 2006-12-14 17:21 ` Jan Engelhardt 2006-12-14 15:46 ` Jeff Garzik ` (2 subsequent siblings) 9 siblings, 1 reply; 239+ messages in thread From: Ben Collins @ 2006-12-14 13:46 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel > So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees > first. This is not something where we use my tree as a way to get it to > other trees. This is something where the push had better come from the > other direction. I can probably speak for Ubuntu in saying we wont include any sort of patch like this unless it's forced on us. I have to agree with your your whole statement. The gradual changes to lock down kernel modules to a particular license(s) tends to mirror the slow lock down of content (music/movies) that people complain about so loudly. It's basically becoming DRM for code. I don't think anyone ever expected technical mechanisms to be developed to enforce the GPL. It's sort of counter intuitive to why the GPL exists, which is to free the code. Let the licenses and lawyers fight to protect the code. The code doesn't need to do that itself. It's got better things to do. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 13:46 ` Ben Collins @ 2006-12-14 17:21 ` Jan Engelhardt 2006-12-14 17:49 ` Ben Collins 0 siblings, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 17:21 UTC (permalink / raw) To: Ben Collins Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Dec 14 2006 08:46, Ben Collins wrote: >I have to agree with your your whole statement. The gradual changes to >lock down kernel modules to a particular license(s) tends to mirror the >slow lock down of content (music/movies) that people complain about so >loudly. It's basically becoming DRM for code. > >I don't think anyone ever expected technical mechanisms to be developed >to enforce the GPL. It's sort of counter intuitive to why the GPL >exists, which is to free the code. """To protect your rights, we need to make restrictions that forbid anyone to deny you these rights""" >Let the licenses and lawyers fight to protect the code. The code doesn't >need to do that itself. It's got better things to do. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:21 ` Jan Engelhardt @ 2006-12-14 17:49 ` Ben Collins 0 siblings, 0 replies; 239+ messages in thread From: Ben Collins @ 2006-12-14 17:49 UTC (permalink / raw) To: Jan Engelhardt Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 2006-12-14 at 18:21 +0100, Jan Engelhardt wrote: > On Dec 14 2006 08:46, Ben Collins wrote: > >I have to agree with your your whole statement. The gradual changes to > >lock down kernel modules to a particular license(s) tends to mirror the > >slow lock down of content (music/movies) that people complain about so > >loudly. It's basically becoming DRM for code. > > > >I don't think anyone ever expected technical mechanisms to be developed > >to enforce the GPL. It's sort of counter intuitive to why the GPL > >exists, which is to free the code. > > """To protect your rights, we need to make restrictions that forbid > anyone to deny you these rights""" > > >Let the licenses and lawyers fight to protect the code. The code doesn't > >need to do that itself. It's got better things to do. And these restrictions are in the letter of the GPL, not the function prototypes of my code. Anyone willing to write libgpl-enforcement? I don't care if someone wants to take my code and blatantly make use of it in their own projects. I encourage it. I wrote it so people could do whatever the hell they wanted to with it. It's when that project is made available to others where I expect the GPL to enforce my copyrights and licenses. I don't expect my code to be self checking for it, and then add conditions that this portion of the code cannot be removed, because then it isn't really GPL anymore, because then it isn't really free either. Maybe people will be happy if it ends up like this: Booting Linux... Please insert your original GNU/Linux source CD... ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (6 preceding siblings ...) 2006-12-14 13:46 ` Ben Collins @ 2006-12-14 15:46 ` Jeff Garzik 2006-12-14 17:03 ` Linus Torvalds 2006-12-14 16:17 ` Adrian Bunk 2006-12-19 15:12 ` free module selection Markus Elfring 9 siblings, 1 reply; 239+ messages in thread From: Jeff Garzik @ 2006-12-14 15:46 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Linus Torvalds wrote: > Because I think it's stupid. So use somebody else than me to push your > political agendas, please. ACK, I agree completely. I think its a silly, political, non-technical decision being pushed here. For the record, I also disagree with the sneaky backdoor way people want to add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need. EXPORT_SYMBOL_GPL() is more to emphasize that certain symbols are more 'internal' or frequently changed, and therefore use of them would imply you are using a derived work of the kernel. EXPORT_SYMBOL_GPL() is /not/ a place for political activism either. Jeff ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:46 ` Jeff Garzik @ 2006-12-14 17:03 ` Linus Torvalds 2006-12-14 17:08 ` Chris Wedgwood 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 17:03 UTC (permalink / raw) To: Jeff Garzik Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006, Jeff Garzik wrote: > > For the record, I also disagree with the sneaky backdoor way people want to > add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need. I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done properly (and I think we use it fairly well). I think we _can_ do things where we give clear hints to people that "we think this is such an internal Linux thing that you simply cannot use this without being considered a derived work". It's really just a strong hint about what we consider to be internal. The fact is, "intent" actually does matter, and as such our _intent_ in saying "these are very deep and internal interfaces" is actually meaningful - even in a court of law. So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure", I see it as being "documentation". That said, I think that some people seem to be a bit over-eager to use it. And I actually think that weakens the rest of them too (imagine a lawyer saying in front of a judge: "Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd, but look, it's a standard function available everywhere else too, and you can implement it as one line of code, so a module that uses it clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not something that means anything" So this is why I've actually argued in the past for some EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly because over-using them actually _weakens_ them, and makes them pointless both from a documentation _and_ from a legal standpoint. Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal sense and has actually made people happier, for what its worth. Of course, you can get <n*2> different opinions from <n> lawyers, so that may not be all that meaningful ;) Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:03 ` Linus Torvalds @ 2006-12-14 17:08 ` Chris Wedgwood 2006-12-14 17:38 ` Christoph Hellwig 0 siblings, 1 reply; 239+ messages in thread From: Chris Wedgwood @ 2006-12-14 17:08 UTC (permalink / raw) To: Linus Torvalds Cc: Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > done properly (and I think we use it fairly well). > > I think we _can_ do things where we give clear hints to people that > "we think this is such an internal Linux thing that you simply > cannot use this without being considered a derived work". Then why not change the name to something more along those lines? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:08 ` Chris Wedgwood @ 2006-12-14 17:38 ` Christoph Hellwig 2006-12-14 17:52 ` Chris Wedgwood 2006-12-17 10:57 ` Geert Uytterhoeven 0 siblings, 2 replies; 239+ messages in thread From: Christoph Hellwig @ 2006-12-14 17:38 UTC (permalink / raw) To: Chris Wedgwood Cc: Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote: > On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > > > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > > done properly (and I think we use it fairly well). > > > > I think we _can_ do things where we give clear hints to people that > > "we think this is such an internal Linux thing that you simply > > cannot use this without being considered a derived work". > > Then why not change the name to something more along those lines? Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:38 ` Christoph Hellwig @ 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 2006-12-17 10:57 ` Geert Uytterhoeven 1 sibling, 2 replies; 239+ messages in thread From: Chris Wedgwood @ 2006-12-14 17:52 UTC (permalink / raw) To: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. A quick grep shows that changing this now would require updating nearly 1900 instances, so patches to do this would be pretty large and disruptive (though we could support both during a transition and migrate them over time). ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:52 ` Chris Wedgwood @ 2006-12-14 18:09 ` Jan Engelhardt 2006-12-18 10:28 ` GPL only modules Eric W. Biederman 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 1 sibling, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 18:09 UTC (permalink / raw) To: Chris Wedgwood Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Dec 14 2006 09:52, Chris Wedgwood wrote: >On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > >> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. > >A quick grep shows that changing this now would require updating >nearly 1900 instances, so patches to do this would be pretty large and >disruptive (though we could support both during a transition and >migrate them over time). I'd prefer to do it at once. But that's not my decision so you anyway do what you want. That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL is somehow contrary. Just a wording issue. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules 2006-12-14 18:09 ` Jan Engelhardt @ 2006-12-18 10:28 ` Eric W. Biederman 0 siblings, 0 replies; 239+ messages in thread From: Eric W. Biederman @ 2006-12-18 10:28 UTC (permalink / raw) To: Jan Engelhardt Cc: Chris Wedgwood, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Jan Engelhardt <jengelh@linux01.gwdg.de> writes: > On Dec 14 2006 09:52, Chris Wedgwood wrote: >>On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: >> >>> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. >> >>A quick grep shows that changing this now would require updating >>nearly 1900 instances, so patches to do this would be pretty large and >>disruptive (though we could support both during a transition and >>migrate them over time). > > I'd prefer to do it at once. But that's not my decision so you anyway do what > you want. > > That said, I would like to keep EXPORT_SYMBOL_GPL, because EXPORT and INTERNAL > is somehow contrary. Just a wording issue. I would suggest that we make the prefix MODULE and not EXPORT. It more accurately conveys what we are trying to say, and it doesn't have the conflicting problem with INTERNAL. I don't know if it is actually worth doing a great rename for such a simple clarification in language. But it is worth considering because it would more strongly convey that we don't expect these symbols to be used by everything. Eric ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt @ 2006-12-14 18:15 ` Eric Sandeen 2006-12-14 18:39 ` Chris Wedgwood 1 sibling, 1 reply; 239+ messages in thread From: Eric Sandeen @ 2006-12-14 18:15 UTC (permalink / raw) To: Chris Wedgwood Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Chris Wedgwood wrote: > On Thu, Dec 14, 2006 at 05:38:27PM +0000, Christoph Hellwig wrote: > >> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. > > A quick grep shows that changing this now would require updating > nearly 1900 instances, so patches to do this would be pretty large and > disruptive (though we could support both during a transition and > migrate them over time). Please don't use that name, it strikes me as much more confusing than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite convey what it means, either. EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least something which is not internally inconsistent would be good (how is something which is exported "internal?") And, as long as EXPORT_SYMBOL_GPL continues to check that the module using it has a GPL license, then it really -is- exactly descriptive of what it's doing and probably shouldn't be changed. IIMHO. -Eric ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen @ 2006-12-14 18:39 ` Chris Wedgwood 2006-12-14 18:51 ` Linus Torvalds 2006-12-14 19:42 ` Scott Preece 0 siblings, 2 replies; 239+ messages in thread From: Chris Wedgwood @ 2006-12-14 18:39 UTC (permalink / raw) To: Eric Sandeen Cc: Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > Please don't use that name, it strikes me as much more confusing > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > convey what it means, either. Calling internal symbols _INTERNAL is confusing? > EXPORT_SYMBOL_RESTRICTED? EXPORT_SYMBOL_DERIVED? At least > something which is not internally inconsistent would be good (how is > something which is exported "internal?") But those symbols aren't, they're about internal interfaces that might change. > And, as long as EXPORT_SYMBOL_GPL continues to check that the module > using it has a GPL license, then it really -is- exactly descriptive > of what it's doing and probably shouldn't be changed. IIMHO. Well, if EXPORT_SYMBOL_GPL / EXPORT_SYMBOL_INTERNAL is about documenting things, why restrict who can use them based on the license? Surely the licence is more about tainting the kernel and debugging not politics? Do we even need to check the license at all in that case? Maybe a better idea would be to embed where the source code is located and use the non-existence of that for a tainting? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:39 ` Chris Wedgwood @ 2006-12-14 18:51 ` Linus Torvalds 2006-12-14 19:42 ` Scott Preece 1 sibling, 0 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 18:51 UTC (permalink / raw) To: Chris Wedgwood Cc: Eric Sandeen, Christoph Hellwig, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, 14 Dec 2006, Chris Wedgwood wrote: > > Calling internal symbols _INTERNAL is confusing? Well, I'm not sure the _INTERNAL name is all that much better than the _GPL one. In many ways, the _GPL one describes the _effects_ better, and also points out the reason _why_ something is marked differently. Sure, it's marked becasue it's internal, but why is does that have to be pointed out at all? Why not use the same EXPORT_SYMBOL? The answer to that is the "GPL" part, ie the expectation that internal symbols are so internal that they have license effects. And if you were an external vendor doing binary only modules, would you react to "internal"? It wouldn't have the same "oh, _that_ is what it is all about" thing, would it? So I do agree that we have probably done a bad job of explaining why that _GPL thing makes sense, and what it means on a deeper level (the license thing is a very superficial thing, but its worth naming just because the superficial thing is also the biggest _impact_ - even if it may not be the underlying deeper _reason_ for it). So which makes more sense from a naming standpoint: the superficial impact that is what _matters_ for people, or the more subtle issue that causes it to have that impact? I think that question is what it boils down to, and at least personally, while I see both things as being worthwhile, I think the superficial thing is the one that needs pointing out, because it's the one that may change your behaviour (while the deeper _meaning_ is more of just an explanation). But I don't personally care that deeply. I mostly care about the fact that changing the name now would just be inconvenient and unnecessary churn, and that's probably my biggest reason to not want to do it ;) Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 18:39 ` Chris Wedgwood 2006-12-14 18:51 ` Linus Torvalds @ 2006-12-14 19:42 ` Scott Preece 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-14 19:49 ` Hua Zhong 1 sibling, 2 replies; 239+ messages in thread From: Scott Preece @ 2006-12-14 19:42 UTC (permalink / raw) To: Chris Wedgwood Cc: Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote: > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > > > Please don't use that name, it strikes me as much more confusing > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite > > convey what it means, either. > > Calling internal symbols _INTERNAL is confusing? I think it's the combination of "INTERNAL" and "EXPORT" that seems contradictory - "If it's internal, why are you exporting it?" I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the meaning clearer, but I don't really think the gain is worth the pain. Anybody using kernel interfaces ought to be able to figure it out. > > But those symbols aren't, they're about internal interfaces that might > change. Folks who think this is likely to make a difference in court might want to look at <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a litany of court cases that have rejected infringement claims where a much sterner effort had been made to hide or block use of interfaces. The article claims that courts have increasingly found that interfacing your code to an existing work is not infringement, regardless of what you have to work around to do it. Of course, that's one author's reading of the case law and I'm sure there are others who disagree, but it's something you'd want to keep in mind in calculating the expected value of a suit... scott ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:42 ` Scott Preece @ 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva ` (3 more replies) 2006-12-14 19:49 ` Hua Zhong 1 sibling, 4 replies; 239+ messages in thread From: Jeff V. Merkey @ 2006-12-14 19:34 UTC (permalink / raw) To: Scott Preece Cc: Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel This whole effort is pointless. This is the same kind of crap MICROSOFT DOES to create incompatibilities DELIBERATELY. The code is either FREE or its NOT FREE. If the code is FREE then let it be. You can put whatever you want in the code -- I will remove any such constructs, just like I remove them frm Red Hat's releases when they put in the same kind of deliberate breakage for anti-competitive reasons. You can go and yell at Novell too, since they do the SAME THING with their releases and mix their modules with Linux. All someone has to do or say is. "... I did not ever accept the GPL license with the FREE code I was given. They said the code was FREE, and I took them at their word. .." FREE implies a transfer of ownsership and you also have to contend with the Doctrine of Estoppel. i.e. if someone has been using the code for over two years, and you have not brought a cause of action, you are BARRED from doing so under the Doctrine of Estoppel and statute of limitations. Here's what that means so you can look it up: http://en.wikigadugi.org/wiki/Estoppel What Linus argued is that FREE means just that. Jeff Scott Preece wrote: > On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote: > >> On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: >> >> > Please don't use that name, it strikes me as much more confusing >> > than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite >> > convey what it means, either. >> >> Calling internal symbols _INTERNAL is confusing? > > > I think it's the combination of "INTERNAL" and "EXPORT" that seems > contradictory - "If it's internal, why are you exporting it?" > > I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would make the > meaning clearer, but I don't really think the gain is worth the pain. > Anybody using kernel interfaces ought to be able to figure it out. > >> >> But those symbols aren't, they're about internal interfaces that might >> change. > > > Folks who think this is likely to make a difference in court might > want to look at > <http:www.linuxworld.com/news/2006/120806-closed-modules2.html> for a > litany of court cases that have rejected infringement claims where a > much sterner effort had been made to hide or block use of interfaces. > The article claims that courts have increasingly found that > interfacing your code to an existing work is not infringement, > regardless of what you have to work around to do it. > > Of course, that's one author's reading of the case law and I'm sure > there are others who disagree, but it's something you'd want to keep > in mind in calculating the expected value of a suit... > > scott > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules 2006-12-14 19:34 ` Jeff V. Merkey @ 2006-12-15 5:28 ` Alexandre Oliva 2006-12-15 10:13 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eduard Bloch ` (2 subsequent siblings) 3 siblings, 0 replies; 239+ messages in thread From: Alexandre Oliva @ 2006-12-15 5:28 UTC (permalink / raw) To: Jeff V. Merkey Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Dec 14, 2006, "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com> wrote: > FREE implies a transfer of ownsership It's about freedom, not price. And even then, it's the license that has not cost, not the copyright. > and you also have to contend with the Doctrine of Estoppel. i.e. if > someone has been using the code for over two years, and you have not > brought a cause of action, you are BARRED from doing so under the > Doctrine of Estoppel and statute of limitations. Sure, but we're not necessarily talking about code that is two years old. We're talking about future releases. Then, if someone interfaces with code that was already there before, they might claim they're still entitled to do so. But if it's new code they interface with, or new code they wrote after this clarification is published, would they still be entitled to estoppel? FWIW, IANAL. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva @ 2006-12-15 10:13 ` Eduard Bloch 2006-12-15 17:44 ` Dave Neuer 2006-12-18 10:55 ` Eric W. Biederman 3 siblings, 0 replies; 239+ messages in thread From: Eduard Bloch @ 2006-12-15 10:13 UTC (permalink / raw) To: Jeff V. Merkey Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel #include <hallo.h> * Jeff V. Merkey [Thu, Dec 14 2006, 12:34:52PM]: > > This whole effort is pointless. This is the same kind of crap MICROSOFT > DOES to create incompatibilities Just my 0.02€ - one of the things I wonder about is why eg. class* interfaces has been replaced with something "protected" by GPL enforcing macros. What is the point? Nobody wins. The access to the new fine-grained system has been restricted for users, and distributors (yes, I maintain a such module) have to work around this in-kernel restriction and create cludges. Greg (and others from the "every touch of my bits is a derivation of it and I need to protect it" party) - what are you thinking? Do you seriously think that such restrictions would help anyone? IMO protecting the access to interfaces is an utterly stupid idea in the free software world. Eduard. -- <Ref|ex> Geht 'n Mantafahrer zum Manta-Treffen. Fragt: Fährt hier wer Manta -- #Debian.DE ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva 2006-12-15 10:13 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eduard Bloch @ 2006-12-15 17:44 ` Dave Neuer 2006-12-18 10:55 ` Eric W. Biederman 3 siblings, 0 replies; 239+ messages in thread From: Dave Neuer @ 2006-12-15 17:44 UTC (permalink / raw) To: Jeff V. Merkey Cc: Scott Preece, Chris Wedgwood, Eric Sandeen, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On 12/14/06, Jeff V. Merkey <jmerkey@wolfmountaingroup.com> wrote: > > This whole effort is pointless. This is the same kind of crap MICROSOFT > DOES to create incompatibilities > DELIBERATELY. The code is either FREE or its NOT FREE. > > All someone has to do or say is. > > "... I did not ever accept the GPL license with the FREE code I was > given. They said the code was FREE, and I took them > at their word. .." At which point, hopefully everyone in that courtroom besides the idiot who says this knows the difference between a license and a contract. If anyone doesn't, they can be referred to: "5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License." The code is free, as in "redistributable at no charge as long as you adhere to the terms of the license." Your estoppel argument seems too confused between laches, promissory estoppel and statutes of limitations to even make sense of, sorry. Dave ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:34 ` Jeff V. Merkey ` (2 preceding siblings ...) 2006-12-15 17:44 ` Dave Neuer @ 2006-12-18 10:55 ` Eric W. Biederman 2006-12-18 17:05 ` Jeff V. Merkey 3 siblings, 1 reply; 239+ messages in thread From: Eric W. Biederman @ 2006-12-18 10:55 UTC (permalink / raw) To: Scott Preece, Chris Wedgwood, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel, Jeff V. Merkey Things we can say without being hypocrites and without getting into legal theory: Kernel modules without source, or that don't have a GPL compatible license are inconsiderate and rude. Please don't be rude. Eric ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-18 10:55 ` Eric W. Biederman @ 2006-12-18 17:05 ` Jeff V. Merkey 0 siblings, 0 replies; 239+ messages in thread From: Jeff V. Merkey @ 2006-12-18 17:05 UTC (permalink / raw) To: Eric W. Biederman Cc: Scott Preece, Chris Wedgwood, Christoph Hellwig, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel Eric W. Biederman wrote: >Things we can say without being hypocrites and without getting into >legal theory: > >Kernel modules without source, or that don't have a GPL compatible >license are inconsiderate and rude. > > ?????? >Please don't be rude. > > ??????? J >Eric > > > ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:42 ` Scott Preece 2006-12-14 19:34 ` Jeff V. Merkey @ 2006-12-14 19:49 ` Hua Zhong 1 sibling, 0 replies; 239+ messages in thread From: Hua Zhong @ 2006-12-14 19:49 UTC (permalink / raw) To: 'Scott Preece', 'Chris Wedgwood' Cc: 'Eric Sandeen', 'Christoph Hellwig', 'Linus Torvalds', 'Jeff Garzik', 'Greg KH', 'Jonathan Corbet', 'Andrew Morton', 'Martin Bligh', 'Michael K. Edwards', linux-kernel I'd suggest putting a Documentation/GPL-Symbols to explain this. Then in the "tainted" message, have a pointer to that documentation. > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Scott Preece > Sent: Thursday, December 14, 2006 11:43 AM > To: Chris Wedgwood > Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff > Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin > Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org > Subject: Re: GPL only modules [was Re: [GIT PATCH] more > Driver core patches for 2.6.19] > > On 12/14/06, Chris Wedgwood <cw@f00f.org> wrote: > > On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote: > > > > > Please don't use that name, it strikes me as much more confusing > > > than EXPORT_SYMBOL_GPL, even though I agree that _GPL > doesn't quite > > > convey what it means, either. > > > > Calling internal symbols _INTERNAL is confusing? > > I think it's the combination of "INTERNAL" and "EXPORT" that > seems contradictory - "If it's internal, why are you exporting it?" > > I think "EXPORT_SYMBOL_GPL_ONLY" or "...ONLY UNDER_GPL" would > make the meaning clearer, but I don't really think the gain > is worth the pain. > Anybody using kernel interfaces ought to be able to figure it out. > > > > > But those symbols aren't, they're about internal interfaces > that might > > change. > > Folks who think this is likely to make a difference in court > might want to look at > <http:www.linuxworld.com/news/2006/120806-closed-modules2.html > > for a litany of court cases that have rejected infringement > claims where a much sterner effort had been made to hide or > block use of interfaces. > The article claims that courts have increasingly found that > interfacing your code to an existing work is not > infringement, regardless of what you have to work around to do it. > > Of course, that's one author's reading of the case law and > I'm sure there are others who disagree, but it's something > you'd want to keep in mind in calculating the expected value > of a suit... > > scott > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to > majordomo@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:38 ` Christoph Hellwig 2006-12-14 17:52 ` Chris Wedgwood @ 2006-12-17 10:57 ` Geert Uytterhoeven 1 sibling, 0 replies; 239+ messages in thread From: Geert Uytterhoeven @ 2006-12-17 10:57 UTC (permalink / raw) To: Christoph Hellwig Cc: Chris Wedgwood, Linus Torvalds, Jeff Garzik, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linux Kernel Development On Thu, 14 Dec 2006, Christoph Hellwig wrote: > On Thu, Dec 14, 2006 at 09:08:41AM -0800, Chris Wedgwood wrote: > > On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote: > > > > > I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if > > > done properly (and I think we use it fairly well). > > > > > > I think we _can_ do things where we give clear hints to people that > > > "we think this is such an internal Linux thing that you simply > > > cannot use this without being considered a derived work". > > > > Then why not change the name to something more along those lines? > > Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense. I find all those names confusing. If these special symbols are GPL/INTERNAL/WHATEVER, what are the other exported symbols? GPL -> Non-GPL? INTERNAL -> External? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 4:15 ` Linus Torvalds ` (7 preceding siblings ...) 2006-12-14 15:46 ` Jeff Garzik @ 2006-12-14 16:17 ` Adrian Bunk 2006-12-14 16:33 ` Alan 2006-12-19 15:12 ` free module selection Markus Elfring 9 siblings, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 16:17 UTC (permalink / raw) To: Linus Torvalds Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Wed, Dec 13, 2006 at 08:15:59PM -0800, Linus Torvalds wrote: >... > The fact is, the reason I don't think we should force the issue is very > simple: copyright law is simply _better_off_ when you honor the admittedly > gray issue of "derived work". It's gray. It's not black-and-white. But > being gray is _good_. Putting artificial black-and-white technical > counter-measures is actually bad. It's bad when the RIAA does it, it's bad > when anybody else does it. >... One important question is: Who gets in danger due to this grey area? E.g. if I'd consider it important enough to stop Ubuntu from distributing kernels and binary-only modules, I wouldn't try the difficult task to take legal actions against a company located on the Isle of Man. The trick is to let a lawyer send cease and desist letters to people distributing the infringing software for 1 Euro at Ebay. The nice thing about cease and desist letters is that the one who accepts one has to pay the > 1000 Euro costs for the lawyer for this letter. Another lucrative task for the lawer would be to send cease and desist letters to people running mirrors located in Germany distributing the infringing software. > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:17 ` Adrian Bunk @ 2006-12-14 16:33 ` Alan 2006-12-14 16:54 ` Adrian Bunk 2006-12-14 17:17 ` Theodore Tso 0 siblings, 2 replies; 239+ messages in thread From: Alan @ 2006-12-14 16:33 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel > The trick is to let a lawyer send cease and desist letters to people > distributing the infringing software for 1 Euro at Ebay. Doesn't that sound even more like the music industry ? Pick on Grandma, and people who've no clue about the issue. It's not the way to solve such problems. The world does not need "The war on binary modules". Educate people instead, and talk to vendors. Save the atomic weapons for the people who are straight forward ripping off work in routers, tvs and all sorts of appliances. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:33 ` Alan @ 2006-12-14 16:54 ` Adrian Bunk 2006-12-14 17:17 ` Theodore Tso 1 sibling, 0 replies; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 16:54 UTC (permalink / raw) To: Alan Cc: Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > The trick is to let a lawyer send cease and desist letters to people > > distributing the infringing software for 1 Euro at Ebay. > > Doesn't that sound even more like the music industry ? Pick on Grandma, > and people who've no clue about the issue. It's not the way to solve such > problems. The world does not need "The war on binary modules". Educate > people instead, and talk to vendors. > > Save the atomic weapons for the people who are straight forward ripping > off work in routers, tvs and all sorts of appliances. I'm not saying that I would do it, but it's the way how it would be done if anyone would do it. It's not about whether that would be good or bad, the point is that the ones that will most likely be affected if anyone will ever take legal actions will not be the big distributions but people selling their old distributions on Ebay or people operating mirrors. Cease and desist letters are a lucrative business for lawyers here in Germany, and such grey areas are simply a timebomb waiting for lawyers and/or people wanting to harm Linux to (ab)use them. > Alan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 16:33 ` Alan 2006-12-14 16:54 ` Adrian Bunk @ 2006-12-14 17:17 ` Theodore Tso 2006-12-14 18:18 ` Alan 2006-12-14 19:51 ` Adrian Bunk 1 sibling, 2 replies; 239+ messages in thread From: Theodore Tso @ 2006-12-14 17:17 UTC (permalink / raw) To: Alan Cc: Adrian Bunk, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > The trick is to let a lawyer send cease and desist letters to people > > distributing the infringing software for 1 Euro at Ebay. > > Doesn't that sound even more like the music industry ? Pick on Grandma, > and people who've no clue about the issue. It's not the way to solve such > problems. The world does not need "The war on binary modules". Educate > people instead, and talk to vendors. .... or like Microsoft, who is threatening to make war on end-users instead of settling things with vendors. (One of the reasons why I personally find the Microsoft promise not to sue _Novell_'s end users so nasty. Microsoft shouldn't be threatening anyone's users; if they have a problem, they should be taking it up with the relevant vendor, not sueing innocent and relatively shallow-pocketed end-users and distributors.) One of the things that I find so interesting about how rabid people get about enforcing GPL-only modules is how they start acting more and more like the RIAA, MPAA, and Microsoft every day.... - Ted ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:17 ` Theodore Tso @ 2006-12-14 18:18 ` Alan 2006-12-14 19:51 ` Adrian Bunk 1 sibling, 0 replies; 239+ messages in thread From: Alan @ 2006-12-14 18:18 UTC (permalink / raw) To: Theodore Tso Cc: Adrian Bunk, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel > One of the things that I find so interesting about how rabid people > get about enforcing GPL-only modules is how they start acting more and > more like the RIAA, MPAA, and Microsoft every day.... There is a saying "That which you fight you become" It's a warning that is well worth heeding in a lot of situations ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 17:17 ` Theodore Tso 2006-12-14 18:18 ` Alan @ 2006-12-14 19:51 ` Adrian Bunk 2006-12-21 15:38 ` Pavel Machek 1 sibling, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 19:51 UTC (permalink / raw) To: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > > The trick is to let a lawyer send cease and desist letters to people > > > distributing the infringing software for 1 Euro at Ebay. > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > and people who've no clue about the issue. It's not the way to solve such > > problems. The world does not need "The war on binary modules". Educate > > people instead, and talk to vendors. > > .... or like Microsoft, who is threatening to make war on end-users > instead of settling things with vendors. (One of the reasons why I > personally find the Microsoft promise not to sue _Novell_'s end users > so nasty. Microsoft shouldn't be threatening anyone's users; if they > have a problem, they should be taking it up with the relevant vendor, > not sueing innocent and relatively shallow-pocketed end-users and > distributors.) > > One of the things that I find so interesting about how rabid people > get about enforcing GPL-only modules is how they start acting more and > more like the RIAA, MPAA, and Microsoft every day.... Please don't think or imply I'd plan to do this, I'm only saying that there's a risk for users in such grey areas. It could be that someone who wants to harm Linux starts suing people distributing Linux. If your goal is to harm Linux, suing users can simply be much more effective than suing vendors... It could even be that people distributing Linux could receive cease and desist letters from people without any real interest in the issue itself - "cease and desist letter"s are so frequent in Germany because the people who have to sign them have to pay the lawyers' costs that are usually > 1000 Euro, and that's a good business for the lawyers. > - Ted cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 19:51 ` Adrian Bunk @ 2006-12-21 15:38 ` Pavel Machek 2006-12-23 11:24 ` Adrian Bunk 0 siblings, 1 reply; 239+ messages in thread From: Pavel Machek @ 2006-12-21 15:38 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > > > The trick is to let a lawyer send cease and desist letters to people > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > > and people who've no clue about the issue. It's not the way to solve such > > > problems. The world does not need "The war on binary modules". Educate > > > people instead, and talk to vendors. > > > > .... or like Microsoft, who is threatening to make war on end-users > > instead of settling things with vendors. (One of the reasons why I > > personally find the Microsoft promise not to sue _Novell_'s end users > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > have a problem, they should be taking it up with the relevant vendor, > > not sueing innocent and relatively shallow-pocketed end-users and > > distributors.) > > > > One of the things that I find so interesting about how rabid people > > get about enforcing GPL-only modules is how they start acting more and > > more like the RIAA, MPAA, and Microsoft every day.... > > Please don't think or imply I'd plan to do this, I'm only saying that > there's a risk for users in such grey areas. > > It could be that someone who wants to harm Linux starts suing people > distributing Linux. If your goal is to harm Linux, suing users can > simply be much more effective than suing vendors... > > It could even be that people distributing Linux could receive cease and > desist letters from people without any real interest in the issue > itself - "cease and desist letter"s are so frequent in Germany because > the people who have to sign them have to pay the lawyers' costs that are > usually > 1000 Euro, and that's a good business for the lawyers. Something is very wrong with German legal system, I'm afraid. Pavel -- Thanks for all the (sleeping) penguins. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-21 15:38 ` Pavel Machek @ 2006-12-23 11:24 ` Adrian Bunk 2006-12-23 21:36 ` Pavel Machek 0 siblings, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-23 11:24 UTC (permalink / raw) To: Pavel Machek Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote: > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > > > > The trick is to let a lawyer send cease and desist letters to people > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > > > and people who've no clue about the issue. It's not the way to solve such > > > > problems. The world does not need "The war on binary modules". Educate > > > > people instead, and talk to vendors. > > > > > > .... or like Microsoft, who is threatening to make war on end-users > > > instead of settling things with vendors. (One of the reasons why I > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > have a problem, they should be taking it up with the relevant vendor, > > > not sueing innocent and relatively shallow-pocketed end-users and > > > distributors.) > > > > > > One of the things that I find so interesting about how rabid people > > > get about enforcing GPL-only modules is how they start acting more and > > > more like the RIAA, MPAA, and Microsoft every day.... > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > there's a risk for users in such grey areas. > > > > It could be that someone who wants to harm Linux starts suing people > > distributing Linux. If your goal is to harm Linux, suing users can > > simply be much more effective than suing vendors... > > > > It could even be that people distributing Linux could receive cease and > > desist letters from people without any real interest in the issue > > itself - "cease and desist letter"s are so frequent in Germany because > > the people who have to sign them have to pay the lawyers' costs that are > > usually > 1000 Euro, and that's a good business for the lawyers. > > Something is very wrong with German legal system, I'm afraid. The point that you can take legal actions against anyone distributing something that violates your rights should be present in more or less all legal systems. What might be special in Germany is only that you can demand your costs after successfully taking legal actions. > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-23 11:24 ` Adrian Bunk @ 2006-12-23 21:36 ` Pavel Machek 2006-12-24 1:07 ` Adrian Bunk 0 siblings, 1 reply; 239+ messages in thread From: Pavel Machek @ 2006-12-23 21:36 UTC (permalink / raw) To: Adrian Bunk Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Sat 2006-12-23 12:24:29, Adrian Bunk wrote: > On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote: > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > > > > > The trick is to let a lawyer send cease and desist letters to people > > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > > > > and people who've no clue about the issue. It's not the way to solve such > > > > > problems. The world does not need "The war on binary modules". Educate > > > > > people instead, and talk to vendors. > > > > > > > > .... or like Microsoft, who is threatening to make war on end-users > > > > instead of settling things with vendors. (One of the reasons why I > > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > > have a problem, they should be taking it up with the relevant vendor, > > > > not sueing innocent and relatively shallow-pocketed end-users and > > > > distributors.) > > > > > > > > One of the things that I find so interesting about how rabid people > > > > get about enforcing GPL-only modules is how they start acting more and > > > > more like the RIAA, MPAA, and Microsoft every day.... > > > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > > there's a risk for users in such grey areas. > > > > > > It could be that someone who wants to harm Linux starts suing people > > > distributing Linux. If your goal is to harm Linux, suing users can > > > simply be much more effective than suing vendors... > > > > > > It could even be that people distributing Linux could receive cease and > > > desist letters from people without any real interest in the issue > > > itself - "cease and desist letter"s are so frequent in Germany because > > > the people who have to sign them have to pay the lawyers' costs that are > > > usually > 1000 Euro, and that's a good business for the lawyers. > > > > Something is very wrong with German legal system, I'm afraid. > > The point that you can take legal actions against anyone distributing > something that violates your rights should be present in more or less > all legal systems. > > What might be special in Germany is only that you can demand your costs > after successfully taking legal actions. What is special in Germany is fact that any random lawyer can demand $1000 (not his cost, his profit) if you distribute code that is not his... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-23 21:36 ` Pavel Machek @ 2006-12-24 1:07 ` Adrian Bunk 0 siblings, 0 replies; 239+ messages in thread From: Adrian Bunk @ 2006-12-24 1:07 UTC (permalink / raw) To: Pavel Machek Cc: Theodore Tso, Alan, Linus Torvalds, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, linux-kernel On Sat, Dec 23, 2006 at 10:36:02PM +0100, Pavel Machek wrote: > On Sat 2006-12-23 12:24:29, Adrian Bunk wrote: > > On Thu, Dec 21, 2006 at 03:38:29PM +0000, Pavel Machek wrote: > > > On Thu 14-12-06 20:51:36, Adrian Bunk wrote: > > > > On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote: > > > > > On Thu, Dec 14, 2006 at 04:33:47PM +0000, Alan wrote: > > > > > > > The trick is to let a lawyer send cease and desist letters to people > > > > > > > distributing the infringing software for 1 Euro at Ebay. > > > > > > > > > > > > Doesn't that sound even more like the music industry ? Pick on Grandma, > > > > > > and people who've no clue about the issue. It's not the way to solve such > > > > > > problems. The world does not need "The war on binary modules". Educate > > > > > > people instead, and talk to vendors. > > > > > > > > > > .... or like Microsoft, who is threatening to make war on end-users > > > > > instead of settling things with vendors. (One of the reasons why I > > > > > personally find the Microsoft promise not to sue _Novell_'s end users > > > > > so nasty. Microsoft shouldn't be threatening anyone's users; if they > > > > > have a problem, they should be taking it up with the relevant vendor, > > > > > not sueing innocent and relatively shallow-pocketed end-users and > > > > > distributors.) > > > > > > > > > > One of the things that I find so interesting about how rabid people > > > > > get about enforcing GPL-only modules is how they start acting more and > > > > > more like the RIAA, MPAA, and Microsoft every day.... > > > > > > > > Please don't think or imply I'd plan to do this, I'm only saying that > > > > there's a risk for users in such grey areas. > > > > > > > > It could be that someone who wants to harm Linux starts suing people > > > > distributing Linux. If your goal is to harm Linux, suing users can > > > > simply be much more effective than suing vendors... > > > > > > > > It could even be that people distributing Linux could receive cease and > > > > desist letters from people without any real interest in the issue > > > > itself - "cease and desist letter"s are so frequent in Germany because > > > > the people who have to sign them have to pay the lawyers' costs that are > > > > usually > 1000 Euro, and that's a good business for the lawyers. > > > > > > Something is very wrong with German legal system, I'm afraid. > > > > The point that you can take legal actions against anyone distributing > > something that violates your rights should be present in more or less > > all legal systems. > > > > What might be special in Germany is only that you can demand your costs > > after successfully taking legal actions. > > What is special in Germany is fact that any random lawyer can demand > $1000 (not his cost, his profit) if you distribute code that is not > his... This is a misunderstanding. You can demand the costs for your lawyer. The costs for your lawyer depend on the amount in controversy. The one who tells his lawyer to take legal actions might be a copyright owner, but it's also possible based on competition law. > Pavel cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: free module selection 2006-12-14 4:15 ` Linus Torvalds ` (8 preceding siblings ...) 2006-12-14 16:17 ` Adrian Bunk @ 2006-12-19 15:12 ` Markus Elfring 9 siblings, 0 replies; 239+ messages in thread From: Markus Elfring @ 2006-12-19 15:12 UTC (permalink / raw) To: linux-kernel > Btw, I really think this is shortsighted. > > It will only result in _exactly_ the crap we were just trying to avoid, > namely stupid "shell game" drivers that don't actually help anything at > all, and move code into user space instead. I would like to contribute some more viewpoints to this hot discussion. Greg Kroah-Hartman revoked a bit of his code suggestion to take time for second thoughts on the topic. http://article.gmane.org/gmane.linux.kernel/475890 > So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees > first. This is not something where we use my tree as a way to get it to > other trees. This is something where the push had better come from the > other direction. I hope that people from such distributions will not create too much pressure to "standardise" in licence limitations. I imagine that there is the important matter of free choice and corresponding fair use. Software techniques can help to choose between available alternatives and possibilities. 1. How much can (kernel) modules be filtered for specific needs like it is performed by class loaders for the Java programming languagge? Are any interceptors internally involved that might throw exceptions to forward constraints handling to special signal handlers? http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern 2. Greg's design approach seems to be a nice option for testing purposes. http://www.kroah.com/log/2006/12/13#uio Are there any similarities with microkernels? In which "space" would you like to run your device drivers? 3. All interested parties can develop a Linux distribution for the specific needs of the various users and customers. It may be a fun project as a hobby or it would be something for production applications like IPCop or SELinux. They can also distinguish the acceptable licences on their own. How much do they really want a limited selection that will be enforced by tools for the discussed use case? http://distrowatch.com/ Regards, Markus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH ` (2 preceding siblings ...) 2006-12-14 4:15 ` Linus Torvalds @ 2006-12-14 5:10 ` Bill Nottingham 2006-12-14 8:48 ` Greg KH 2006-12-14 5:58 ` Nigel Cunningham ` (2 subsequent siblings) 6 siblings, 1 reply; 239+ messages in thread From: Bill Nottingham @ 2006-12-14 5:10 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Greg KH (gregkh@suse.de) said: > An updated version is below. If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL for removal at the same time, as this essentially renders that irrelevant. That being said... First, this is adding the measure at module load time. Any copyright infringment happens on distribution; module load isn't (necessarily) that; if I write random code and load it, without ever sending it to anyone, I'm not violating the license, and this would prevent that. So it seems somewhat misplaced. Secondly... > Oh, and for those who have asked me how we would enforce this after this > date if this decision is made, I'd like to go on record that I will be > glad to take whatever legal means necessary to stop people from > violating this. There's nothing stopping you undertaking these means now. Addition of this measure doesn't change the copyright status of any code - what was a violation before would still be a violation. Copyright's not something like trademark, where it's sue-or-lose - there's no requirement for constant action, and there's no requirement for enforcement measures. If I reproduce and start selling copies of the White album, it doesn't matter that there wasn't a mechanism on the CD that prevented me doing that - it's still a copyright violation. Hence, the only purpose of a clause like this legally would seem to be to *intentionally* go after people using the DMCA. Which seems... tacky. Of course, I don't have significant code of note in the kernel, so I can't really prevent you from doing this if you want... Bill ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 5:10 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Bill Nottingham @ 2006-12-14 8:48 ` Greg KH 2006-12-14 14:02 ` Rik van Riel 0 siblings, 1 reply; 239+ messages in thread From: Greg KH @ 2006-12-14 8:48 UTC (permalink / raw) To: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Thu, Dec 14, 2006 at 12:10:15AM -0500, Bill Nottingham wrote: > > Greg KH (gregkh@suse.de) said: > > An updated version is below. > > If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL > for removal at the same time, as this essentially renders that irrelevant. > > That being said... > > First, this is adding the measure at module load time. Any copyright > infringment happens on distribution; module load isn't (necessarily) > that; if I write random code and load it, without ever sending it > to anyone, I'm not violating the license, and this would prevent that. > So it seems somewhat misplaced. Yes, as Linus points out, this is the main point here, my apologies. GPL covers distribution, not usage, no matter how much the people working on v3 want to change that :) Even if we change the kernel this way, it prevents valid and legal usages of the kernel. So I am wrong, sorry. > Secondly... > > > Oh, and for those who have asked me how we would enforce this after this > > date if this decision is made, I'd like to go on record that I will be > > glad to take whatever legal means necessary to stop people from > > violating this. > > There's nothing stopping you undertaking these means now. Addition of > this measure doesn't change the copyright status of any code - what was > a violation before would still be a violation. Agreed, and I have done this in the past. I only stated this because it seems that some people keep just wishing this whole issue would go away if they ignore it. > Hence, the only purpose of a clause like this legally would seem to be > to *intentionally* go after people using the DMCA. Which seems... tacky. Despite my wardrobe consisting mainly of old t-shirts and jeans, I still never want to be called tacky :) It's just that I'm so damn tired of this whole thing. I'm tired of people thinking they have a right to violate my copyright all the time. I'm tired of people and companies somehow treating our license in ways that are blatantly wrong and feeling fine about it. Because we are a loose band of a lot of individuals, and not a company or legal entity, it seems to give companies the chutzpah to feel that they can get away with violating our license. So when someone like Andrew gives me the opportunity to put a stop to all of the crap that I have to put up with each and every day with a tiny 2 line patch, I jumped in and took it. I need to sit back and remember to see the bigger picture some times, so I apologize to everyone here. And yes, it is crap that I deal with every day due to the lovely grey area that is Linux kernel module licensing these days. I have customers that demand we support them despite them mixing three and more different closed source kernel modules at once and getting upset that I have no way to help them out. I have loony video tweakers that hand edit kernel oopses to try to hide the fact that they are using a binary module bigger than the sum of the whole kernel and demand that our group fix their suspend/resume issue for them. I see executives who say one thing to the community and then turn around and overrule them just because someone made a horrible purchasing decision on the brand of laptop wifi card that they purchased. I see lawyers who have their hands tied by attorney-client rules and can not speak out in public for how they really feel about licenses and how to interpret them. And in the midst of all of that are the poor users who have no idea who to listen to. They don't know what is going on, they "just want to use their hardware" and don't give a damm about anyone's license. And then there's the distros out there that listen to those users and give them the working distro as they see a market for it, and again, as a company, justify to themselves that it must be ok to violate those kernel developers rights because no one seems to be stopping them so far. [side diversion, it's not the video drivers that really matter here everyone, those are just so obvious. It's the hundreds of other blatantly infringing binary kernel modules out there that really matter. The ones that control filesystems, cluster interconnects, disk arrays, media codecs, and a whole host of custom hardware. That's the real problem that Linux faces now and will only get worse in the future. It's not two stupid little video drivers, I could honestly care less about them...] But it's all part of the process, and I can live with it, even if at times it drives me crazy. But I know we will succeed, it will just take us a little longer to get there, so I might as well learn to enjoy the view more. Even though I really think I can get that patch by the Novell lawyers and convince management there that it is something we can do, it's not something that I want to take on, as I think my time can be better spent coding to advance Linux technically, not fight legal battles. I'll go delete that module.c patch from my tree now. thanks, greg k-h p.s. I still think the UIO interface is a valid and good one. And yes, it might cause people to move stuff to userspace that they really should not be just to get around the GPL issues. But like loots of tools, it can be used in good and bad ways, we shouldn't prevent the good usages of it. I'll work to get more real examples using it before resubmitting. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 8:48 ` Greg KH @ 2006-12-14 14:02 ` Rik van Riel 2006-12-14 15:42 ` Chris Friesen ` (2 more replies) 0 siblings, 3 replies; 239+ messages in thread From: Rik van Riel @ 2006-12-14 14:02 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Greg KH wrote: > It's just that I'm so damn tired of this whole thing. I'm tired of > people thinking they have a right to violate my copyright all the time. Pretty much every license under the sun is getting violated, and people are getting away with it. The GPL is not special in this regard. > And yes, it is crap that I deal with every day due to the lovely grey > area that is Linux kernel module licensing these days. I have customers > that demand we support them despite them mixing three and more different > closed source kernel modules at once and getting upset that I have no > way to help them out. However, users do not like running unsupportable software when the shit hits the fan - which it will always do with any piece of software, eventually :) Maybe we should just educate users and teach them to avoid crazy unsupportable configurations and simply buy the hardware that has open drivers available? In the laptop space, I already try to avoid everything non-Centrino, because chances are a closed source video or network driver would be needed with something else[1]. Judging from how much vendor drivers tend to get improved when they get merged upstream, I don't see how vendors think they can get away with not merging their code upstream. I'm not talking about this from a legal standpoint (millions of people get away with blatantly illegal stuff every day), but from a technical and market point of view. Why would users buy a piece of hardware that needs a binary only driver that's unsupportable, when they can buy a similar piece of hardware that has a driver that's upstream and is supported by every single Linux distribution out there? Sure, the process of getting drivers merged upstream[2] can take some time and effort, but the resulting improvements in driver performance and stability are often worth it. It's happened more than once that the Linux kernel community's review process turned up some opportunities for a 30% performance improvement in a submitted driver. Hardware companies: can you afford to miss out on the stability and performance improvements that merging a driver upstream tends to get? Can you afford to miss out when your competitors are getting these benefits? [1] other vendors: fix your stuff, so I can recommend your hardware too! [2] http://kernelnewbies.org/UpstreamMerge -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:02 ` Rik van Riel @ 2006-12-14 15:42 ` Chris Friesen 2006-12-14 15:47 ` Alan 2006-12-14 19:32 ` Bill Nottingham 2 siblings, 0 replies; 239+ messages in thread From: Chris Friesen @ 2006-12-14 15:42 UTC (permalink / raw) To: Rik van Riel Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Rik van Riel wrote: > Why would users buy a piece of hardware that needs a binary > only driver that's unsupportable, when they can buy a similar > piece of hardware that has a driver that's upstream and is > supported by every single Linux distribution out there? In my experience it falls into a number of categories: 1) The system that requires the binary driver has other hardware on it that is required for the app. 2) The system that requires the binary driver costs significantly less, enough that they decide to bite the bullet on the software support side. 3) The system that requires the binary driver is the *only* one available in the specified form factor with the specified cpu architecture. 4) The team that decides on the hardware is totally divorced from the OS guys, so they don't know/care what is supported by open source drivers in the first place. Chris ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:02 ` Rik van Riel 2006-12-14 15:42 ` Chris Friesen @ 2006-12-14 15:47 ` Alan 2006-12-14 15:48 ` Jeff Garzik 2006-12-14 19:32 ` Bill Nottingham 2 siblings, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 15:47 UTC (permalink / raw) To: Rik van Riel Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel > Pretty much every license under the sun is getting violated, > and people are getting away with it. The GPL is not special > in this regard. That may begin to change in time. There are a lot of people getting very angry at the political level about the way large companies in particular flout copyright law and claim to "not know" because they just bought something in, often from Taiwan or China, with stolen code in it. There are proposals on the table in the EU to make commercial piracy a criminal not a civil matter in the case of copyright. (The original proposal also suggested for patents which would have been rather dumb but that seems to have been killed off for now). So in a couple years a GPL violating product in the EU may entail a walk down to the local police station rather than a private court case. In the UK also trading standards whose remit right now is trademark abuse will also be getting enforcement powers and funding for copyright stuff. The powers that be are mostly thinking "pirate DVD in the local market stall", but some of us have other ideas. We do need to distinguish between the blatant violators and the borderline people - there's a difference between the folks shipping Linux rip-offs binary only in random unlabelled routers and people like Nvidia and Novell who are on the edge of the license corner cases. Another thing we should do more is aggressively merge prototype open drivers for binary only hardware - lets get Nouveau's DRM bits into the kernel ASAP for example. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:47 ` Alan @ 2006-12-14 15:48 ` Jeff Garzik 2006-12-14 22:21 ` Dave Airlie 0 siblings, 1 reply; 239+ messages in thread From: Jeff Garzik @ 2006-12-14 15:48 UTC (permalink / raw) To: Alan Cc: Rik van Riel, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Alan wrote: > Another thing we should do more is aggressively merge prototype open > drivers for binary only hardware - lets get Nouveau's DRM bits into the > kernel ASAP for example. ACK++ We should definitely push Nouveau[1] as hard as we can. Jeff [1] http://nouveau.freedesktop.org/ ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 15:48 ` Jeff Garzik @ 2006-12-14 22:21 ` Dave Airlie 2006-12-14 22:26 ` Michael Buesch 0 siblings, 1 reply; 239+ messages in thread From: Dave Airlie @ 2006-12-14 22:21 UTC (permalink / raw) To: Jeff Garzik Cc: Alan, Rik van Riel, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On 12/15/06, Jeff Garzik <jeff@garzik.org> wrote: > Alan wrote: > > Another thing we should do more is aggressively merge prototype open > > drivers for binary only hardware - lets get Nouveau's DRM bits into the > > kernel ASAP for example. > > ACK++ We should definitely push Nouveau[1] as hard as we can. > > Jeff > It'll get in when the developers feel it is at a stage where it can be supported, at the moment (I'm not speaking for all the nouveau team only my own opinion) the API isn't stable and putting it into the kernel only means we've declared the API supportable, I know in theory marking it EXPERIMENTAL might work, in practice it will just cause us headaches at this stage, there isn't enough knowledgeable developers working on it both support users and continue development at a decent rate, so mainly ppl are concentrating on development until it can at least play Q3, and for me dualhead on my G5 :-) Dave. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 22:21 ` Dave Airlie @ 2006-12-14 22:26 ` Michael Buesch 2006-12-14 22:39 ` Dave Airlie 0 siblings, 1 reply; 239+ messages in thread From: Michael Buesch @ 2006-12-14 22:26 UTC (permalink / raw) To: Dave Airlie Cc: Alan, Rik van Riel, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel, Jeff Garzik On Thursday 14 December 2006 23:21, Dave Airlie wrote: > On 12/15/06, Jeff Garzik <jeff@garzik.org> wrote: > > Alan wrote: > > > Another thing we should do more is aggressively merge prototype open > > > drivers for binary only hardware - lets get Nouveau's DRM bits into the > > > kernel ASAP for example. > > > > ACK++ We should definitely push Nouveau[1] as hard as we can. > > > > Jeff > > > > It'll get in when the developers feel it is at a stage where it can be > supported, at the moment (I'm not speaking for all the nouveau team > only my own opinion) the API isn't stable and putting it into the > kernel only means we've declared the API supportable, I know in theory > marking it EXPERIMENTAL might work, in practice it will just cause us > headaches at this stage, there isn't enough knowledgeable developers > working on it both support users and continue development at a decent > rate, so mainly ppl are concentrating on development until it can at > least play Q3, and for me dualhead on my G5 :-) To what degree does it work on the G5? Can we already drive a desktop system with it? I'd like to play around with this on my Quad. -- Greetings Michael. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 22:26 ` Michael Buesch @ 2006-12-14 22:39 ` Dave Airlie 2006-12-14 22:45 ` Michael Buesch 0 siblings, 1 reply; 239+ messages in thread From: Dave Airlie @ 2006-12-14 22:39 UTC (permalink / raw) To: Michael Buesch Cc: Alan, Rik van Riel, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel, Jeff Garzik > > > > It'll get in when the developers feel it is at a stage where it can be > > supported, at the moment (I'm not speaking for all the nouveau team > > only my own opinion) the API isn't stable and putting it into the > > kernel only means we've declared the API supportable, I know in theory > > marking it EXPERIMENTAL might work, in practice it will just cause us > > headaches at this stage, there isn't enough knowledgeable developers > > working on it both support users and continue development at a decent > > rate, so mainly ppl are concentrating on development until it can at > > least play Q3, and for me dualhead on my G5 :-) > > To what degree does it work on the G5? > Can we already drive a desktop system with it? > I'd like to play around with this on my Quad. > 2D worked the last time I tested it and fixed up all the problems, it is slightly faster than nv, but may be more unstable, still only single head... 3D even on x86 doesn't work yet without pre-loading nvidia to set the hardware up correctly.. but it's coming along.... there are summary updates posted ~weekly on the nouveau wiki.... Dave. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 22:39 ` Dave Airlie @ 2006-12-14 22:45 ` Michael Buesch 0 siblings, 0 replies; 239+ messages in thread From: Michael Buesch @ 2006-12-14 22:45 UTC (permalink / raw) To: Dave Airlie Cc: Alan, Rik van Riel, Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel, Jeff Garzik On Thursday 14 December 2006 23:39, Dave Airlie wrote: > > > > > > It'll get in when the developers feel it is at a stage where it can be > > > supported, at the moment (I'm not speaking for all the nouveau team > > > only my own opinion) the API isn't stable and putting it into the > > > kernel only means we've declared the API supportable, I know in theory > > > marking it EXPERIMENTAL might work, in practice it will just cause us > > > headaches at this stage, there isn't enough knowledgeable developers > > > working on it both support users and continue development at a decent > > > rate, so mainly ppl are concentrating on development until it can at > > > least play Q3, and for me dualhead on my G5 :-) > > > > To what degree does it work on the G5? > > Can we already drive a desktop system with it? > > I'd like to play around with this on my Quad. > > > > 2D worked the last time I tested it and fixed up all the problems, it > is slightly faster than nv, but may be more unstable, still only > single head... 3D even on x86 doesn't work yet without pre-loading > nvidia to set the hardware up correctly.. but it's coming along.... > there are summary updates posted ~weekly on the nouveau wiki.... Ok, that's nice to hear. :) Can't be much more pain than nv, heh. And as I only have singlehead, anyway, I'll give it a try. -- Greetings Michael. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 14:02 ` Rik van Riel 2006-12-14 15:42 ` Chris Friesen 2006-12-14 15:47 ` Alan @ 2006-12-14 19:32 ` Bill Nottingham 2 siblings, 0 replies; 239+ messages in thread From: Bill Nottingham @ 2006-12-14 19:32 UTC (permalink / raw) To: Rik van Riel Cc: Greg KH, Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Rik van Riel (riel@redhat.com) said: > Maybe we should just educate users and teach them to > avoid crazy unsupportable configurations and simply buy > the hardware that has open drivers available? Educating the users may help, but it's hard to do the education once they've already bought the hardware. Generally, it would be 1) buy hardware 2) run whatever comes with it 3) try Linux. Hard to get the 'if you're ever thinking about running Linux, don't buy XYZ' into that workflow. > Sure, the process of getting drivers merged upstream[2] can > take some time and effort, but the resulting improvements in > driver performance and stability are often worth it. It's > happened more than once that the Linux kernel community's > review process turned up some opportunities for a 30% performance > improvement in a submitted driver. > > Hardware companies: can you afford to miss out on the stability > and performance improvements that merging a driver upstream tends > to get? > > Can you afford to miss out when your competitors are getting these > benefits? This is the big point - we need to show the vendors how getting upstream helps them. Compare costs of all-in-house development versus shared-with-community development. Compare how quickly issues are fixed, and how often drivers actually regress with in-tree vs. out-of-tree drivers. Get case studies of drivers that have been opened (qeth? lpfc? Others?) and get other companies to *go on the record* on how opening their drivers and getting them upstream has helped them to lower their development costs and scale their sales. Bill ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH ` (3 preceding siblings ...) 2006-12-14 5:10 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Bill Nottingham @ 2006-12-14 5:58 ` Nigel Cunningham 2006-12-14 7:54 ` David Schwartz 2006-12-14 8:21 ` David Woodhouse 6 siblings, 0 replies; 239+ messages in thread From: Nigel Cunningham @ 2006-12-14 5:58 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Hi. Good arguments have already been put against it, so I'll just keep it short and sweet (FWIW) Nacked-by: Nigel Cunningham <nigel@suspend2.net> Regards, Nigel ^ permalink raw reply [flat|nested] 239+ messages in thread
* RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH ` (4 preceding siblings ...) 2006-12-14 5:58 ` Nigel Cunningham @ 2006-12-14 7:54 ` David Schwartz 2006-12-14 8:21 ` David Woodhouse 6 siblings, 0 replies; 239+ messages in thread From: David Schwartz @ 2006-12-14 7:54 UTC (permalink / raw) To: Linux-Kernel@Vger. Kernel. Org > Someone also mentioned that we could just put a nice poem into the > kernel module image in order to be able to enforce our copyright license > in any court of law. > > Full bellies of fish > Penguins sleep under the moon > Dream of wings that fly > > thanks, Whoever says that has no understanding of copyright law. Copyright law *only* protects something when there are a large number of equally-good ways to accomplish the same thing. If there is only one way to accomplish a particular function, it cannot be protected by copyright. The Lexmark v. Static Controls case made this pretty clear. Lexmark did pretty much the same thing with their toner cartridges. You cannot copyright a password to get the effect of a patent (ownership of every way to accomplish a particular function). By the way, the GPL seems to prohibit this. Why is this not an "additional restriction"? Where does the GPL say that you cannot create and use a derivative work unless you put a notice in it stating that it is licensed under the GPL? I agree with Linus that this is insane hypocrisy. To be totally blunt, the want to do this -- to control the way other people use the works they own -- is the same evil impulse that drives the RIAA. Shame on you. It's supposed to be about free as in freedom. DS ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:55 ` Greg KH ` (5 preceding siblings ...) 2006-12-14 7:54 ` David Schwartz @ 2006-12-14 8:21 ` David Woodhouse 6 siblings, 0 replies; 239+ messages in thread From: David Woodhouse @ 2006-12-14 8:21 UTC (permalink / raw) To: Greg KH Cc: Jonathan Corbet, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Wed, 2006-12-13 at 16:55 -0800, Greg KH wrote: > Oh, and for those who have asked me how we would enforce this after this > date if this decision is made, I'd like to go on record that I will be > glad to take whatever legal means necessary to stop people from > violating this. I see no _overriding_ reason to wait. This is a technical measure which they'd need to deliberately work around, and which might make the case easier to win -- but I think I'm on record already as planning to sue someone soon for binary-only modules, even without this particular technical measure to prevent them. The only reason it hasn't happened so far is because lawyers make me itch. -- dwmw2 ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:43 ` Jonathan Corbet 2006-12-14 0:55 ` Greg KH @ 2006-12-14 10:36 ` Alan 2006-12-14 14:57 ` Adrian Bunk 1 sibling, 1 reply; 239+ messages in thread From: Alan @ 2006-12-14 10:36 UTC (permalink / raw) To: Jonathan Corbet Cc: Greg KH, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel > 2008? I bet a lot of people would read the above to say that their > system will just drop dead of a New Year's hangover, and they'll freak. > I wouldn't want to be the one getting all the email at that point... I wouldn't worry. Everyone will have patched it back out again by then, or made their driver lie about the license. Both of which make the problem worse not better when it comes to debugging. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 10:36 ` Alan @ 2006-12-14 14:57 ` Adrian Bunk 0 siblings, 0 replies; 239+ messages in thread From: Adrian Bunk @ 2006-12-14 14:57 UTC (permalink / raw) To: Alan Cc: Jonathan Corbet, Greg KH, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Thu, Dec 14, 2006 at 10:36:13AM +0000, Alan wrote: > > 2008? I bet a lot of people would read the above to say that their > > system will just drop dead of a New Year's hangover, and they'll freak. > > I wouldn't want to be the one getting all the email at that point... > > I wouldn't worry. Everyone will have patched it back out again by then, > or made their driver lie about the license. Both of which make the > problem worse not better when it comes to debugging. But make it easier when it comes to court... > Alan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-14 0:32 ` Greg KH 2006-12-14 0:43 ` Jonathan Corbet @ 2006-12-24 14:27 ` Pavel Machek 2006-12-24 19:59 ` Dmitry Torokhov 1 sibling, 1 reply; 239+ messages in thread From: Pavel Machek @ 2006-12-24 14:27 UTC (permalink / raw) To: Greg KH Cc: Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel Hi! > > > > So let's come out and ban binary modules, rather than pussyfooting > > > > around, if that's what we actually want to do. > > > > > > Give people 12 months warning (time to work out what they're going to do, > > > talk with the legal dept, etc) then make the kernel load only GPL-tagged > > > modules. > > > > > > I think I'd favour that. It would aid those people who are trying to > > > obtain device specs, and who are persuading organisations to GPL their drivers. > > > > Ok, I have no objection to that at all. I'll whip up such a patch in a > > bit to spit out kernel log messages whenever such a module is loaded so > > that people have some warning. > > Here you go. The wording for the feature-removal-schedule.txt file > could probably be cleaned up. Any suggestions would be welcome. > > thanks, > > greg k-h > > ----------- > From: Greg Kroah-Hartmna <gregkh@suse.de> > Subject: Notify non-GPL module loading will be going away in January 2008 > > Numerous kernel developers feel that loading non-GPL drivers into the > kernel violates the license of the kernel and their copyright. Because > of this, a one year notice for everyone to address any non-GPL > compatible modules has been set. > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > --- > Documentation/feature-removal-schedule.txt | 9 +++++++++ > kernel/module.c | 6 +++++- > 2 files changed, 14 insertions(+), 1 deletion(-) > > --- gregkh-2.6.orig/Documentation/feature-removal-schedule.txt > +++ gregkh-2.6/Documentation/feature-removal-schedule.txt > @@ -281,3 +281,12 @@ Why: Speedstep-centrino driver with ACPI > Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> > > --------------------------- > + > +What: non GPL licensed modules will able to be loaded successfully. > +When: January 2008 > +Why: Numerous kernel developers feel that loading non-GPL drivers into the > + kernel violates the license of the kernel and their copyright. > + > +Who: Greg Kroah-Hartman <greg@kroah.com> or <gregkh@suse.de> > + > +--------------------------- > --- gregkh-2.6.orig/kernel/module.c > +++ gregkh-2.6/kernel/module.c > @@ -1393,9 +1393,13 @@ static void set_license(struct module *m > license = "unspecified"; > > if (!license_is_gpl_compatible(license)) { > - if (!(tainted & TAINT_PROPRIETARY_MODULE)) > + if (!(tainted & TAINT_PROPRIETARY_MODULE)) { > printk(KERN_WARNING "%s: module license '%s' taints " > "kernel.\n", mod->name, license); > + printk(KERN_WARNING "%s: This module will not be able " > + "to be loaded after January 1, 2008 due to its " > + "license.\n", mod->name); > + } > add_taint_module(mod, TAINT_PROPRIETARY_MODULE); > } > } perhaps printk('Binary only modules are not allowed by kernel license, but copyright law may still allow them in special cases. Be careful, Greg is going tuo sue you at beggining of 2008 if you get it wrong.') would be acceptable way to educate people? Pavel -- Thanks for all the (sleeping) penguins. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-24 14:27 ` Pavel Machek @ 2006-12-24 19:59 ` Dmitry Torokhov 0 siblings, 0 replies; 239+ messages in thread From: Dmitry Torokhov @ 2006-12-24 19:59 UTC (permalink / raw) To: Pavel Machek Cc: Greg KH, Andrew Morton, Martin Bligh, Michael K. Edwards, Linus Torvalds, linux-kernel On Sunday 24 December 2006 09:27, Pavel Machek wrote: > > perhaps printk('Binary only modules are not allowed by kernel license, > but copyright law may still allow them in special cases. Be careful, Come again? > Greg is going tuo sue you at beggining of 2008 if you get it wrong.') > would be acceptable way to educate people? Since this message will be seen by an end-user who is likely does not do any distribution he has nothing to fear from Greg ;) -- Dmitry ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:47 ` Andrew Morton 2006-12-13 22:09 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH @ 2006-12-13 22:20 ` Michael K. Edwards 2006-12-13 22:59 ` Kyle Moffett ` (2 more replies) 1 sibling, 3 replies; 239+ messages in thread From: Michael K. Edwards @ 2006-12-13 22:20 UTC (permalink / raw) To: Andrew Morton; +Cc: Martin Bligh, Greg KH, Linus Torvalds, linux-kernel On 12/13/06, Andrew Morton <akpm@osdl.org> wrote: > On Wed, 13 Dec 2006 13:32:50 -0800 > Martin Bligh <mbligh@mbligh.org> wrote: > > > So let's come out and ban binary modules, rather than pussyfooting > > around, if that's what we actually want to do. > > Give people 12 months warning (time to work out what they're going to do, > talk with the legal dept, etc) then make the kernel load only GPL-tagged > modules. IIRC, Linus has deliberately and explicitly estopped himself from claiming that loading a binary-only driver is a GPL violation. Do you really want to create an arbitrage opportunity for intermediaries who undo technical measures that don't match Linus's declared policy or, in many people's opinion, the law in at least some jurisdictions? (I'm not going to go all amateur-lawyer on you, but the transcript of oral argument at the Supreme Court level in Lotus v. Borland makes really interesting reading no matter where you live or what your stance is on GPL-and-linking.) > I think I'd favour that. It would aid those people who are trying to > obtain device specs, and who are persuading organisations to GPL their drivers. I don't think it would. There is a strong argument that GPL drivers in the mainline kernel are a good idea on technical and business grounds. Making a federal case out of it is a distraction at best. There is a widespread delusion that closed driver code is an asset in an accounting sense. It costs a lot of money to create and even more to maintain in any kind of usable condition. As long as managers of chip development projects get away with shifting some of the real cost of creating yet another buggy undocumented one-off CPU interface onto a "software" team in a different cost center, the pressure to label the code base an intangible asset is overwhelming. It usually takes a reorg or two to diffuse the responsibility enough to call it a sunk cost, at which point someone might be brave enough to argue that opening it up would save money and/or sell more chips. As things stand, there is a slippery slope (in a good way) from a totally-closed, one-off, buggy vendor driver to a GPL'ed driver in the mainline kernel. Customers get impatient for drivers that work, the vendor allows a customer or a mutually acceptable third party to work on the code, the sky doesn't fall. There are some situations where the business strategy of keeping the driver closed is defensible on both engineering and regulatory/barrier-to-entry grounds, but they're fairly rare; and some fraction of vendors come around to that view in time. > (Whereas the patch which is proposed in this thread hinders those people) There we agree. Cheers, - Michael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards @ 2006-12-13 22:59 ` Kyle Moffett 2006-12-13 23:55 ` Alan 2006-12-14 15:13 ` Rik van Riel 2 siblings, 0 replies; 239+ messages in thread From: Kyle Moffett @ 2006-12-13 22:59 UTC (permalink / raw) To: Michael K. Edwards Cc: Andrew Morton, Martin Bligh, Greg KH, Linus Torvalds, linux-kernel On Dec 13, 2006, at 17:20:35, Michael K. Edwards wrote: > On 12/13/06, Andrew Morton <akpm@osdl.org> wrote: >> On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh >> <mbligh@mbligh.org> wrote: >>> So let's come out and ban binary modules, rather than >>> pussyfooting around, if that's what we actually want to do. >> >> Give people 12 months warning (time to work out what they're going >> to do, talk with the legal dept, etc) then make the kernel load >> only GPL-tagged modules. > > IIRC, Linus has deliberately and explicitly estopped himself from > claiming that loading a binary-only driver is a GPL violation. Do > you really want to create an arbitrage opportunity for > intermediaries who undo technical measures that don't match Linus's > declared policy or, in many people's opinion, the law in at least > some jurisdictions? (I'm not going to go all amateur-lawyer on you, > but the transcript of oral argument at the Supreme Court level in > Lotus v. Borland makes really interesting reading no matter where > you live or what your stance is on GPL-and-linking.) Ok, so what Linus said is true for any code that _Linus_ wrote up until this point. It is perfectly fine for the iptables developers to say "I think linking with my GPL IPTables code for makes your code a derivative work of mine", although I don't really have the legal knowledge to argue technical points either way. Corporations change their mind on licensing all the time; though you can never revoke privileges you already granted on existing materials. As soon as you start creating new material (in the Linux case at a rate of multiple megs per month) you can set new licensing requirements on that new code as long as it's compatible with the requirements on the old code which it's linked against. Cheers, Kyle Moffett ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards 2006-12-13 22:59 ` Kyle Moffett @ 2006-12-13 23:55 ` Alan 2006-12-14 2:11 ` Al Viro 2006-12-14 17:22 ` Linus Torvalds 2006-12-14 15:13 ` Rik van Riel 2 siblings, 2 replies; 239+ messages in thread From: Alan @ 2006-12-13 23:55 UTC (permalink / raw) To: Michael K. Edwards Cc: Andrew Morton, Martin Bligh, Greg KH, Linus Torvalds, linux-kernel > IIRC, Linus has deliberately and explicitly estopped himself from > claiming that loading a binary-only driver is a GPL violation. Do you He only owns a small amount of the code. Furthermore he imported third party GPL code using the license as sole permission. So he may have dug a personal hole but many of the rest of us have been repeatedly saying whenever he said that - that we do not agree. The FSF has always said binary modules are wrong and there is FSF code imported into the kernel by Linus on license only grounds. Whether it is a good idea is a different question. Alan. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:55 ` Alan @ 2006-12-14 2:11 ` Al Viro 2006-12-14 17:22 ` Linus Torvalds 1 sibling, 0 replies; 239+ messages in thread From: Al Viro @ 2006-12-14 2:11 UTC (permalink / raw) To: Alan Cc: Michael K. Edwards, Andrew Morton, Martin Bligh, Greg KH, Linus Torvalds, linux-kernel On Wed, Dec 13, 2006 at 11:55:00PM +0000, Alan wrote: > > IIRC, Linus has deliberately and explicitly estopped himself from > > claiming that loading a binary-only driver is a GPL violation. Do you > > He only owns a small amount of the code. Furthermore he imported third > party GPL code using the license as sole permission. So he may have dug a > personal hole but many of the rest of us have been repeatedly saying > whenever he said that - that we do not agree. The FSF has always said > binary modules are wrong and there is FSF code imported into the kernel > by Linus on license only grounds. > > Whether it is a good idea is a different question. Wait a bloody minute - the only FSF code in the kernel I know of is from libgcc, which does allow linking to non-GPL code. Is there anything else? ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:55 ` Alan 2006-12-14 2:11 ` Al Viro @ 2006-12-14 17:22 ` Linus Torvalds 1 sibling, 0 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 17:22 UTC (permalink / raw) To: Alan Cc: Michael K. Edwards, Andrew Morton, Martin Bligh, Greg KH, linux-kernel On Wed, 13 Dec 2006, Alan wrote: > > He only owns a small amount of the code. Furthermore he imported third > party GPL code using the license as sole permission. So he may have dug > a personal hole but many of the rest of us have been repeatedly saying > whenever he said that - that we do not agree. [ The "he" being me in the above ] Btw, I'd like to make it clear in this discussion too (as I have in others), that I agree 100% with Alan here. The thing is, my opinion is really just _my_ opinion. People shouldn't see it as anything else. When I say "I don't think we should totally disallow binary modules", you should always keep in mind that: - the fact that I think that _some_ binary modules may be perfectly legal does not mean that I think _all_ binary modules would be legal. I think there are lots of ways to make such a binary module that is obviously not ok. - I really _am_ just one of hundreds of copyright owners. The fact that _I_ am not necessarily all that eager to take things to court should in no way be seen as estoppel for _others_ who decide that they want to flex their legal rights. So when I "may have dug a personal hole", please realize that this is actually a personal - and conscious - choice. I've never wanted to do copyright assignments, for several reasons: I think they are nasty and wrong personally, and I'd hate all the paperwork, and I think it would actually detract from the development model. But one of the reasons I've never wanted copyright assignments is that I'm personally actually _more_ comfortable with the system being co-owned. I _like_ having my hands bound, and being in that hole. Not because of any strange sexual hangups either, but simply because I think being personally limited is something that makes people trust me more in the end - or rather, it is something that means that people don't _have_ to trust me. So people know that I can't unilaterally change the license. And they _know_ that they can actually take things to court on their own. AND THAT IS A GOOD THING. The last thing anybody _ever_ wants is to have me having absolute powers. Not you guys, and certainly not me. So you guys should always be happy, realizing that Linus may have his quirks, but that my quirks can't ever really screw you guys up. So I repeat: my opinions are _my_ opinions. Nobody else is legally bound by them. And I'm certainly willing to bend my behaviour in the presense of pressure (I think only mindless idiots can't change their mind - I personally change some of my opinions several times a day just to keep them fresh), but in somethign like this, where I _do_ have a fairly strong opinion, I really think that this kind of patch has to be merged in somebody elses tree than mine. If, after a year, it turns out that my tree is the only one that doesn't have that clause, I think I'll either get the hint, or people will realize that I'm pointless and will just ignore me. It will have taken you long enough to realize that ;) Because one of the great things about the GPL is that _nobody_ has the power to deny other peoples will. Not even me, not even for the kernel. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards 2006-12-13 22:59 ` Kyle Moffett 2006-12-13 23:55 ` Alan @ 2006-12-14 15:13 ` Rik van Riel 2 siblings, 0 replies; 239+ messages in thread From: Rik van Riel @ 2006-12-14 15:13 UTC (permalink / raw) To: Michael K. Edwards Cc: Andrew Morton, Martin Bligh, Greg KH, Linus Torvalds, linux-kernel Michael K. Edwards wrote: > I don't think it would. There is a strong argument that GPL drivers > in the mainline kernel are a good idea on technical and business > grounds. Any volunteers to expand on that in the Kernelnewbies section on this subject? So far the "business ground" is only half a page or so :) http://kernelnewbies.org/UpstreamMerge -- All Rights Reversed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:02 ` Greg KH 2006-12-13 21:32 ` Martin Bligh @ 2006-12-13 21:48 ` Michael K. Edwards 1 sibling, 0 replies; 239+ messages in thread From: Michael K. Edwards @ 2006-12-13 21:48 UTC (permalink / raw) To: Greg KH; +Cc: Linus Torvalds, Andrew Morton, linux-kernel On 12/13/06, Greg KH <gregkh@suse.de> wrote: > On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: > > Seriously, though, please please pretty please do not allow a facility > > for "going through a simple interface to get accesses to irqs and > > memory regions" into the mainline kernel, with or without toy ISA > > examples. > > Why? X does it today :) Er, I rest my case? Anyway, the history around X11 is completely different from the present situation, and there were good arguments at the time for structuring the problem so that the X server was relatively kernel-neutral even if it was banging directly on a framebuffer, and later on 2-D acceleration hardware. As graphics chips have become more sophisticated, pure-userspace X11 has become less tenable. > > Embedded systems integrators have enough trouble with chip vendors who > > think that exposing the device registers to userspace constitutes a > > "driver". > > Yes, and because of this, they create binary only drivers today. Lots > of them. All over the place. Doing crazy stupid crap in kernelspace. It does not get less crazy and stupid because we open a big hole from kernelspace to userspace and let them pretend that they have a GPL "driver" when all of the chip init logic is peeked and poked from the same closed code in userspace. Most low-level drivers (the kind that involve IRQs and registers local to the CPU; USB is different) cannot be done right from userspace and we shouldn't encourage people to try. > Then there are people who do irq stuff in userspace but get it wrong. > I've seen that happen many times in lots of different research papers > and presentations. Their problems need not become our problems. > This interface does it correctly, and it allows those people who for > some reason feel they do want to keep their logic in non-gpl code, to do > it. People who want to keep their logic in non-GPL code do so by providing binary-only drivers. That's a sane compromise in certain sectors, and occasionally results in the eventual opening of the driver (when the illusion of competitive advantage in closed-ness wears off) in integrable shape. A customer with some leverage and technical skill can negotiate for access to the source code so that he can fix the bugs that are biting him, rebuild with a toolchain that isn't from the Dark Ages, and so forth: a real-life demonstration to the vendor that letting outsiders work on the code will sell more chips. But if you actively encourage a brain-damaged userspace driver strategy, that opportunity is lost. > It also allows code that needs floating point to not be in the kernel > and in one instance using this interface actually sped up the device > because of the lack of the need to go between kernel and userspace a > bunch of times. What instance is that? Are you sure it wasn't a case of things being done in the driver that should have been done in a library all along? > > The correct description is more like "porting shim for MMU-less RTOS > > tasks"; and if the BSP vendors of the world can make a nickel > > supplying them, more power to them. Just not in mainline, please. > > Again, X does this today, and does does lots of other applications. > This is a way to do it in a sane manner, to keep people who want to do > floating point out of the kernel, and to make some embedded people much > happier to use Linux, gets them from being so mad at Linux because we > keep changing the internal apis, and makes me happier as they stop > violating my copyright by creating closed drivers in the kernel. Today's problem is that too many chip suppliers' in-house software people have neither the skills nor the schedule room nor the influence to insist that drivers be written competently and maintainably, whether or not they are maintained in the public view. So chipmakers turn to the BSP vendors, whose business model is built around being the only people who can do incremental development on the code they write. I'm not at all hostile to BSP vendors or to chipmakers who wind up in this position; that's the way most of the industry works nowadays. But I do want to know when I'm dealing with that situation, because the appropriate strategies for getting a product to market are different when it costs the chip vendor real cash money each time they commission a recompile to meet some customer's expectations. Pretending that driver code doesn't need reviewing every few months as the kernel's locking strategies, timer handling, internal APIs, etc. evolve makes things worse. Just like the only thing worse that a salesperson who's on commission is a salesperson who isn't on commission, the only thing worse than a closed device driver in kernelspace is a closed device driver in userspace. Cheers, - Michael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:38 ` Michael K. Edwards 2006-12-13 21:02 ` Greg KH @ 2006-12-13 21:03 ` Linus Torvalds 2006-12-16 9:05 ` Pavel Machek 1 sibling, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 21:03 UTC (permalink / raw) To: Michael K. Edwards; +Cc: Greg KH, Andrew Morton, linux-kernel On Wed, 13 Dec 2006, Michael K. Edwards wrote: > > On 12/13/06, Linus Torvalds <torvalds@osdl.org> wrote: > > Ok, what kind of ass-hat idiotic thing is this? > > C'mon, Linus, tell us how you _really_ feel. I'll try to be less subtle next time ;) > Seriously, though, please please pretty please do not allow a facility > for "going through a simple interface to get accesses to irqs and > memory regions" into the mainline kernel, with or without toy ISA > examples. I do agree. I'm not violently opposed to something like this in practice (we've already allowed it for USB devices), but there definitely needs to be a real reason that helps _us_, not just some ass-hat vendor that looks for a way to avoid open-sourcing their driver. If there are real and valid uses (and as mentioned, I actually think that the whole graphics-3D-engine-thing is such a use) where a kernel driver simply doesn't work out well, or where there are serious tecnical reasons why it wants to be in user space (and "stability" is not one such thing: if you access hardware directly in user space, and your driver is buggy, the machine is equally deal, and a hell of a lot harder to control to boot). Microkernel people have their heads up their arses, none of their arguments have actually ever made any real logical sense. So look elsewhere for real reasons to do it in user space. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:03 ` Linus Torvalds @ 2006-12-16 9:05 ` Pavel Machek 2006-12-16 11:04 ` Jörn Engel 0 siblings, 1 reply; 239+ messages in thread From: Pavel Machek @ 2006-12-16 9:05 UTC (permalink / raw) To: Linus Torvalds; +Cc: Michael K. Edwards, Greg KH, Andrew Morton, linux-kernel Hi! > > Seriously, though, please please pretty please do not allow a facility > > for "going through a simple interface to get accesses to irqs and > > memory regions" into the mainline kernel, with or without toy ISA > > examples. > > I do agree. > > I'm not violently opposed to something like this in practice (we've > already allowed it for USB devices), but there definitely needs to be a > real reason that helps _us_, not just some ass-hat vendor that looks for a > way to avoid open-sourcing their driver. > > If there are real and valid uses (and as mentioned, I actually think that > the whole graphics-3D-engine-thing is such a use) where a kernel driver > simply doesn't work out well, or where there are serious tecnical reasons > why it wants to be in user space (and "stability" is not one such thing: > if you access hardware directly in user space, and your driver is buggy, > the machine is equally deal, and a hell of a lot harder to control to > boot). Well.. it is easier to debug in userspace. While bad hw access can still kill the box, bad free() will not, and most bugs in early developent are actually of 2nd kind. Pavel -- Thanks for all the (sleeping) penguins. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-16 9:05 ` Pavel Machek @ 2006-12-16 11:04 ` Jörn Engel 2006-12-17 10:49 ` Pavel Machek 0 siblings, 1 reply; 239+ messages in thread From: Jörn Engel @ 2006-12-16 11:04 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Michael K. Edwards, Greg KH, Andrew Morton, linux-kernel On Sat, 16 December 2006 09:05:32 +0000, Pavel Machek wrote: > > Well.. it is easier to debug in userspace. While bad hw access can > still kill the box, bad free() will not, and most bugs in early > developent are actually of 2nd kind. Isn't that what qemu is for? Jörn -- Happiness isn't having what you want, it's wanting what you have. -- unknown ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-16 11:04 ` Jörn Engel @ 2006-12-17 10:49 ` Pavel Machek 0 siblings, 0 replies; 239+ messages in thread From: Pavel Machek @ 2006-12-17 10:49 UTC (permalink / raw) To: Jörn Engel Cc: Linus Torvalds, Michael K. Edwards, Greg KH, Andrew Morton, linux-kernel Hi! > > Well.. it is easier to debug in userspace. While bad hw access can > > still kill the box, bad free() will not, and most bugs in early > > developent are actually of 2nd kind. > > Isn't that what qemu is for? I do not think you can reasonably debug driver for new hardware under qemu. Anyway, doing it in userspace is just convenient. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 20:12 ` [GIT PATCH] more Driver core patches for 2.6.19 Linus Torvalds 2006-12-13 20:31 ` Greg KH 2006-12-13 20:38 ` Michael K. Edwards @ 2006-12-13 21:14 ` Benjamin Herrenschmidt 2006-12-13 21:22 ` Jan Engelhardt 2006-12-13 21:26 ` Linus Torvalds 2 siblings, 2 replies; 239+ messages in thread From: Benjamin Herrenschmidt @ 2006-12-13 21:14 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel > Ok, what kind of ass-hat idiotic thing is this? > > irqreturn_t uio_irq_handler(int irq, void *dev_id) > { > return IRQ_HANDLED; > } > > exactly what is the point here? No way will I pull this kind of crap. You > just seem to have guaranteed a dead machine if the irq is level-triggered, > since it will keep on happening forever. > > Please remove. > > YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT! Actually, you can... but wether you want is a different story :-) You can simply mask it, have it handled by userspace and re-enable it when that's done. Though say hello to horrible interrupt latencies and hope you aren't sharing it with anything critical... I don't mean I -like- the approach... I just say it can be made to sort-of work. But I don't see the point. Ben. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:14 ` Benjamin Herrenschmidt @ 2006-12-13 21:22 ` Jan Engelhardt 2006-12-13 23:28 ` Linus Torvalds 2006-12-13 21:26 ` Linus Torvalds 1 sibling, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-13 21:22 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel >You can simply mask it, have it handled by userspace and re-enable it >when that's done. Though say hello to horrible interrupt latencies and >hope you aren't sharing it with anything critical... For the sharing case, some sort of softirq should be created. That is, when a hard interrupt is generated and the irq handler is executed, set a flag that at some other point in time, the irq is delivered to userspace. Like you do with signals in userspace: void sighandler(int s) { exit_main_loop_soon = 1; } something similar could be done in kernelspace without interrupting important devices/irq_handlers sharing the same IRQ. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:22 ` Jan Engelhardt @ 2006-12-13 23:28 ` Linus Torvalds 2006-12-14 11:18 ` Jan Engelhardt 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 23:28 UTC (permalink / raw) To: Jan Engelhardt Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Wed, 13 Dec 2006, Jan Engelhardt wrote: > > For the sharing case, some sort of softirq should be created. That is, when a > hard interrupt is generated and the irq handler is executed, set a flag that at > some other point in time, the irq is delivered to userspace. Like you do with > signals in userspace: NO. The whole point is, YOU CANNOT DO THIS. You need to shut the device up. Otherwise it keeps screaming. Please, people, don't confuse the issue any further. A hardware driver ABSOLUTELY POSITIVELY HAS TO have an in-kernel irq handler that knows how to turn the irq off. End of story. No ifs, buts, maybes about it. You cannot have a generic kernel driver that doesn't know about the low-level hardware (not with current hardware - you could make the "shut the f*ck up" a generic thing if you designed hardware properly, but that simply does not exist in general right now). In short: a user-space device driver has exactly TWO choices: - don't use interrupts at all, just polling - have an in-kernel irq handler that at a minimum knows how to test whether the irq came from that device and knows how to shut it up. This means NOT A GENERIC DRIVER. That simply isn't an option on the table, no matter how much people would like it to be. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:28 ` Linus Torvalds @ 2006-12-14 11:18 ` Jan Engelhardt 2006-12-14 11:26 ` Jan Engelhardt 2006-12-14 17:26 ` Linus Torvalds 0 siblings, 2 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 11:18 UTC (permalink / raw) To: Linus Torvalds Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel >> For the sharing case, some sort of softirq should be created. That is, when a >> hard interrupt is generated and the irq handler is executed, set a flag that at >> some other point in time, the irq is delivered to userspace. Like you do with >> signals in userspace: > >NO. > >The whole point is, YOU CANNOT DO THIS. > >You need to shut the device up. Otherwise it keeps screaming. > >Please, people, don't confuse the issue any further. A hardware driver > > ABSOLUTELY POSITIVELY HAS TO > >have an in-kernel irq handler that knows how to turn the irq off. > >End of story. No ifs, buts, maybes about it. I don't get you. The rtc module does something similar (RTC generates interrupts and notifies userspace about it) irqreturn_t uio_handler(...) { disable interrupts for this dev; set a flag that notifies userspace the next best time; seomstruct->flag |= IRQ_ARRIVED; return IRQ_HANDLED; } /* Userspace->kernel notification, e.g. by means of a device node /dev/uio or some ioctl. */ int uio_write(...) { somestruct->flag &= ~IRQ_ARRIVED; enable interrupts for the device; } > - have an in-kernel irq handler that at a minimum knows how to test > whether the irq came from that device and knows how to shut it up. > >This means NOT A GENERIC DRIVER. That simply isn't an option on the >table, no matter how much people would like it to be. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 11:18 ` Jan Engelhardt @ 2006-12-14 11:26 ` Jan Engelhardt 2006-12-14 17:32 ` Linus Torvalds 2006-12-14 17:26 ` Linus Torvalds 1 sibling, 1 reply; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 11:26 UTC (permalink / raw) To: Linus Torvalds Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel > irqreturn_t uio_handler(...) { > disable interrupts for this dev; > set a flag that notifies userspace the next best time; > seomstruct->flag |= IRQ_ARRIVED; > return IRQ_HANDLED; > } Rather than IRQ_HANDLED, it should have been: remove this irq handler from the irq handlers for irq number N, so that it does not get called again until userspace has acked it. See, maybe I don't have enough clue yet to exactly figure out why you say it does not work. However, this is how simple people see it 8) -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 11:26 ` Jan Engelhardt @ 2006-12-14 17:32 ` Linus Torvalds 2006-12-14 18:04 ` Jan Engelhardt 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 17:32 UTC (permalink / raw) To: Jan Engelhardt Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Thu, 14 Dec 2006, Jan Engelhardt wrote: > > Rather than IRQ_HANDLED, it should have been: remove this irq handler > from the irq handlers for irq number N, so that it does not get called > again until userspace has acked it. Wrongo. That just means that the _handler_ won't be called. But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS FOR THAT INTERRUPT will be called. Over and over again. Forever. Because the machine won't be making any progress, and the user-level code (which might know how to shut it up) won't ever be called, because the machine is busy just doing interrupt delivery all the time. > See, maybe I don't have enough clue yet to exactly figure out why you > say it does not work. However, this is how simple people see it 8) You may be a bit simple. But I think it's more polite to call you "special". Or maybe just not very used to how hardware works. Btw, this is not something theoretical. We used to have this particular problem _all_ the time with PCMCIA back when we weren't as good at interrupt routing. You'd insert a PCMCIA card, and the machine just hung. Hard. And the reason was that it would send an irq, but we were expecting it on another interrupt. But if it showed up on something that was shared, you'd have a hung machine, because you'd just have the (say) ethernet driver saying "not for me", and returning. And obviously not able to actually shut it up, so when we returned from the interrupt handler, the interrupt happened immediately again. So this really isn't theoretical. It's a very common failure schenario for mishandled interrupts. In fact, exactly because it's so common, these days we have all this special logic in the generic interrupt layer that notices, and shuts them up entirely (but does so by disabling _all_ the devices on that interrupt, so when this happens, you might well lose your disk driver or somethign else). Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:32 ` Linus Torvalds @ 2006-12-14 18:04 ` Jan Engelhardt 0 siblings, 0 replies; 239+ messages in thread From: Jan Engelhardt @ 2006-12-14 18:04 UTC (permalink / raw) To: Linus Torvalds Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Dec 14 2006 09:32, Linus Torvalds wrote: >On Thu, 14 Dec 2006, Jan Engelhardt wrote: >> >> Rather than IRQ_HANDLED, it should have been: remove this irq >> handler from the irq handlers for irq number N, so that it does >> not get called again until userspace has acked it. > >That just means that the _handler_ won't be called. But the irq >still stays active, and if it's shared, ALL THE OTHER HANDLERS FOR >THAT INTERRUPT will be called. >[...] >And the reason was that it would send an irq, but we were expecting >it on another interrupt. But if it showed up on something that was >shared, you'd have a hung machine, because you'd just have the (say) >ethernet driver saying "not for me", and returning. And obviously >not able to actually shut it up, so when we returned from the >interrupt handler, the interrupt happened immediately again. Thanks for this explanation, I see the point. Removing the uio irq handler will leave the irq chain only with "not for me" devices. In that case, would it make sense to install a replacement uio handler that says "yes, that's mine" [but ignoring it since userspace has not yet finished with it]? (I think I've gotten into a loop since that would be the IRQ_HANDLED case.) Mh, delicate problem. -`J' -- ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 11:18 ` Jan Engelhardt 2006-12-14 11:26 ` Jan Engelhardt @ 2006-12-14 17:26 ` Linus Torvalds 2006-12-14 20:47 ` Thomas Gleixner 1 sibling, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 17:26 UTC (permalink / raw) To: Jan Engelhardt Cc: Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Thu, 14 Dec 2006, Jan Engelhardt wrote: > > I don't get you. The rtc module does something similar (RTC generates > interrupts and notifies userspace about it) The RTC module knows how to shut the interrupt up. (And in many cases, timers are special. Timers, by design, are often "edge triggered" even in systems that have no other interrupts that work that way. Exactly because a timer is special. So the RTC module often knows that it doesn't need to do anything at all to shut it up, but even that is special per-device knowledge, that is NOT TRUE for any normal devices). Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 17:26 ` Linus Torvalds @ 2006-12-14 20:47 ` Thomas Gleixner 2006-12-14 22:59 ` Linus Torvalds 0 siblings, 1 reply; 239+ messages in thread From: Thomas Gleixner @ 2006-12-14 20:47 UTC (permalink / raw) To: Linus Torvalds Cc: Jan Engelhardt, Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Thu, 2006-12-14 at 09:26 -0800, Linus Torvalds wrote: > > On Thu, 14 Dec 2006, Jan Engelhardt wrote: > > > > I don't get you. The rtc module does something similar (RTC generates > > interrupts and notifies userspace about it) > > The RTC module knows how to shut the interrupt up. The kernel part of the UIO driver also knows how to shut the interrupt up, so where is the difference ? tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 20:47 ` Thomas Gleixner @ 2006-12-14 22:59 ` Linus Torvalds 2006-12-14 23:37 ` Thomas Gleixner 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-14 22:59 UTC (permalink / raw) To: Thomas Gleixner Cc: Jan Engelhardt, Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel On Thu, 14 Dec 2006, Thomas Gleixner wrote: > > The kernel part of the UIO driver also knows how to shut the interrupt > up, so where is the difference ? Thomas, you've been discussing some totally different and private Thomas-only thread than everybody else in this thread has been. The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the post that STARTED this whole thread. Go and read the "example driver". The example driver was complete crap and drivel. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 22:59 ` Linus Torvalds @ 2006-12-14 23:37 ` Thomas Gleixner 0 siblings, 0 replies; 239+ messages in thread From: Thomas Gleixner @ 2006-12-14 23:37 UTC (permalink / raw) To: Linus Torvalds Cc: Jan Engelhardt, Benjamin Herrenschmidt, Greg KH, Andrew Morton, linux-kernel Linus, On Thu, 2006-12-14 at 14:59 -0800, Linus Torvalds wrote: > > The kernel part of the UIO driver also knows how to shut the interrupt > > up, so where is the difference ? > > Thomas, you've been discussing some totally different and private > Thomas-only thread than everybody else in this thread has been. Yeah, I even looked at different code than others, until they noticed that email before coffee is bad. :) > The point is NO, THE UIO DRIVER DID NOT KNOW THAT AT ALL. Go and read the > post that STARTED this whole thread. Go and read the "example driver". > > The example driver was complete crap and drivel. Sigh, I accept and also Greg has done this before, that the example driver based on the LPT port was not a fortunate choice. It was done to provide some example which is reproducible on COTS hardware. Real world drivers like the sercos example I provided - and I do it again - are aware of that problem: /* * The chip specific portion of the interrupt handler. The framework code * takes care of userspace notification when we return IRQ_HANDLED */ static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg) { /* Check, if this interrupt is originated from the SERCOS chip */ if (!(sercos_read(IRQ_STATUS) & SERCOS_INTERRUPT_MASK)) return IRQ_NONE; ---------^ Makes it safe for IRQ sharing /* Acknowledge the chip interrupts */ sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1); sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2); ----------^ Actually prevents the box is dead scenario, as it disables the interrupt from that device until it is reenabled from the user space driver code. This covers also the case where the user space driver dies, as the kernel still has the portion of code to shut this thing up for ever. return IRQ_HANDLED; } The concept requires, that - the interrupt handling is in the kernel _AND_ open source - the mapping of the device is done via the kernel controlled mapping function rather than by poking in the PCI regs I really regret that I ever came up with this LPT example, but cutting the whole discussion down to that ugly example driver does not get us anywhere. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:14 ` Benjamin Herrenschmidt 2006-12-13 21:22 ` Jan Engelhardt @ 2006-12-13 21:26 ` Linus Torvalds 2006-12-13 22:14 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-13 21:26 UTC (permalink / raw) To: Benjamin Herrenschmidt; +Cc: Greg KH, Andrew Morton, linux-kernel On Thu, 14 Dec 2006, Benjamin Herrenschmidt wrote: > > Actually, you can... but wether you want is a different story :-) > > You can simply mask it, have it handled by userspace and re-enable it > when that's done. Nope. Again, this whole mentality is WRONG. It DOES NOT WORK. No architecture does per-device interrupts portably, which means that you'll always see sharing. And once you see sharing, you have small "details" like the harddisk interrupt or network interrupt that the user-land driver will depend on. Oops. Instant deadlock. > I don't mean I -like- the approach... I just say it can be made to > sort-of work. But I don't see the point. No. The point really is that it fundamentally _cannot_ work. Not in the real world. It can only work in some alternate reality where you can always disable interrupts per-device, and even in that alternate reality it would be wrong to use that quoted interrupt handler: not only do you need to disable the irq, you need to have an "acknowledge" phase too So you'd actually have to fix things _architecturally_, not just add some code to the irq handler. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 21:26 ` Linus Torvalds @ 2006-12-13 22:14 ` Benjamin Herrenschmidt 2006-12-13 22:30 ` Thomas Gleixner 2006-12-13 22:40 ` Thomas Gleixner 0 siblings, 2 replies; 239+ messages in thread From: Benjamin Herrenschmidt @ 2006-12-13 22:14 UTC (permalink / raw) To: Linus Torvalds; +Cc: Greg KH, Andrew Morton, linux-kernel > No. The point really is that it fundamentally _cannot_ work. Not in the > real world. > > It can only work in some alternate reality where you can always disable > interrupts per-device, and even in that alternate reality it would be > wrong to use that quoted interrupt handler: not only do you need to > disable the irq, you need to have an "acknowledge" phase too > > So you'd actually have to fix things _architecturally_, not just add some > code to the irq handler. Oh, it works well enough for non shared iqs if you are really anal about it, but I agree that it sucks and I don't see the point of having it in linux. The flow has to be different for level vs. edge and it's really ugly but it works. I've seen people doing it in embedded space. But again, I do agree it sucks big time :-) the edge flow is easy. the level one is: - IRQ happens - kernel handler masks it and queue a msg for userland - later on, userland gets the message, talks to the device, (MMAP'ed mmio, acks the interrupt on the device itself) and does an ioctl/syscall/write/whatever to tell kernel it's done - kernel unmasks it. But yeah, I hate it too, so let's not waste time talking about how to make it work :-) Ben. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:14 ` Benjamin Herrenschmidt @ 2006-12-13 22:30 ` Thomas Gleixner 2006-12-13 22:39 ` Benjamin Herrenschmidt 2006-12-13 23:56 ` Alan 2006-12-13 22:40 ` Thomas Gleixner 1 sibling, 2 replies; 239+ messages in thread From: Thomas Gleixner @ 2006-12-13 22:30 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: > the edge flow is easy. the level one is: > > - IRQ happens > - kernel handler masks it and queue a msg for userland > - later on, userland gets the message, talks to the device, > (MMAP'ed mmio, acks the interrupt on the device itself) and > does an ioctl/syscall/write/whatever to tell kernel it's done > - kernel unmasks it. That's simply not true. - IRQ happens - kernel handler runs and masks the chip irq, which removes the IRQ request - user space message get queued or waiting reader woken - kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC - user space handles the device - user space reenables the device irq No need for an ioctl. Neither for edge nor for level irqs. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:30 ` Thomas Gleixner @ 2006-12-13 22:39 ` Benjamin Herrenschmidt 2006-12-13 23:11 ` Thomas Gleixner 2006-12-13 23:56 ` Alan 1 sibling, 1 reply; 239+ messages in thread From: Benjamin Herrenschmidt @ 2006-12-13 22:39 UTC (permalink / raw) To: tglx; +Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Wed, 2006-12-13 at 23:30 +0100, Thomas Gleixner wrote: > On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: > > the edge flow is easy. the level one is: > > > > - IRQ happens > > - kernel handler masks it and queue a msg for userland > > - later on, userland gets the message, talks to the device, > > (MMAP'ed mmio, acks the interrupt on the device itself) and > > does an ioctl/syscall/write/whatever to tell kernel it's done > > - kernel unmasks it. > > That's simply not true. > > - IRQ happens > - kernel handler runs and masks the chip irq, which removes the IRQ > request > - user space message get queued or waiting reader woken > - kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC > - user space handles the device > - user space reenables the device irq > > No need for an ioctl. Neither for edge nor for level irqs. Wait wait wait... your scenario implies that the kernel has knowledge of the chip to mask the irq in the chip in the first place. If that is the case, then you have a chip specific kernel driver, yadada, the whole story is moot :-) We were talking about the idea of having some "generic" reflector of irqs to userspace without device specific knowledge. Ben. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:39 ` Benjamin Herrenschmidt @ 2006-12-13 23:11 ` Thomas Gleixner 2006-12-13 23:39 ` Michael K. Edwards 2006-12-14 0:00 ` Alan 0 siblings, 2 replies; 239+ messages in thread From: Thomas Gleixner @ 2006-12-13 23:11 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Thu, 2006-12-14 at 09:39 +1100, Benjamin Herrenschmidt wrote: > > No need for an ioctl. Neither for edge nor for level irqs. > > Wait wait wait... your scenario implies that the kernel has knowledge of > the chip to mask the irq in the chip in the first place. > > If that is the case, then you have a chip specific kernel driver, > yadada, the whole story is moot :-) > > We were talking about the idea of having some "generic" reflector of > irqs to userspace without device specific knowledge. Which simply is not possible, especially for shared irqs. Can you please elaborate why this effort is moot, instead of throwing the usual flamewar arguments around ? The concept of UIO divides the problem in two spaces: - kernel interface, which controls interrupts and mapping - user space restricted interface I don't see why the necessarity of a kernel stub driver is a killer argument. The chip internals, which companies might want to protect are certainly not in the interrupt registers. Aside of that there are huge performance gains for certain application / driver scenarios and I really don't see an advantage that people are doing excactly the same thing in out of tree hackeries with a lot of inconsistent user land interfaces. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:11 ` Thomas Gleixner @ 2006-12-13 23:39 ` Michael K. Edwards 2006-12-14 0:00 ` Alan 1 sibling, 0 replies; 239+ messages in thread From: Michael K. Edwards @ 2006-12-13 23:39 UTC (permalink / raw) To: tglx Cc: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On 12/13/06, Thomas Gleixner <tglx@linutronix.de> wrote: > Aside of that there are huge performance gains for certain application / > driver scenarios and I really don't see an advantage that people are > doing excactly the same thing in out of tree hackeries with a lot of > inconsistent user land interfaces. Greg's effort is noble but I think it is targeted at the wrong problem and would actually make things worse. Inconsistent interfaces from one "driver" to another are the surface design flaw that obscures the fundamental design flaw of exposing hardware to userland: abdication of the driver writer's responsibility to choose and justify which things belong in the driver and which belong in a hardware-agnostic driver framework or a userspace library instead. When you are talking about unique, one-off hardware, it doesn't really matter whether the shim for a closed, out-of-tree, userspace driver fits into a framework or not. Who cares whether they use the preferred MMIO reservation paths or just throw ioctl(POKE_ME_HARDER) or mmap(/dev/mem) at the problem? But I don't want to see ALSA or iwconfig or i2c-core or any of the other competently designed and implemented driver frameworks mangled into unusability by attempts to facilitate this "design pattern". Truth in advertising is an advantage even if it doesn't change the underlying reality. I can (and do) tell chip vendors, "that's not a driver, that's a shim for some other customer's pre-existing eCos task", and justify the cost of writing an actual driver to the client. I may or may not succeed in arguing that the new driver should be designed to an existing API when that means rethinking the userspace app, or that it should be implemented against a current kernel and offered promptly up to the appropriate Linus lieutenant. But at least the project isn't crippled by confusion about whether or not the existing blob constitutes a driver. Cheers, - Michael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:11 ` Thomas Gleixner 2006-12-13 23:39 ` Michael K. Edwards @ 2006-12-14 0:00 ` Alan 1 sibling, 0 replies; 239+ messages in thread From: Alan @ 2006-12-14 0:00 UTC (permalink / raw) To: tglx Cc: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton, linux-kernel > I don't see why the necessarity of a kernel stub driver is a killer > argument. The chip internals, which companies might want to protect are > certainly not in the interrupt registers. So they can go off and write themselves a driver. Without putting junk in the kernel "just in case", and if the driver and the user space code using it are closely interdependant I'd suggest they look up the *legal* definition of derivative work. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:30 ` Thomas Gleixner 2006-12-13 22:39 ` Benjamin Herrenschmidt @ 2006-12-13 23:56 ` Alan 2006-12-14 0:08 ` Greg KH 2006-12-14 9:15 ` Thomas Gleixner 1 sibling, 2 replies; 239+ messages in thread From: Alan @ 2006-12-13 23:56 UTC (permalink / raw) To: tglx Cc: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Wed, 13 Dec 2006 23:30:55 +0100 Thomas Gleixner <tglx@linutronix.de> wrote: > - IRQ happens > - kernel handler runs and masks the chip irq, which removes the IRQ > request IRQ is shared with the disk driver, box dead. Plus if this is like the uio crap in -mm its full of security holes. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:56 ` Alan @ 2006-12-14 0:08 ` Greg KH 2006-12-14 9:15 ` Thomas Gleixner 1 sibling, 0 replies; 239+ messages in thread From: Greg KH @ 2006-12-14 0:08 UTC (permalink / raw) To: Alan Cc: tglx, Benjamin Herrenschmidt, Linus Torvalds, Andrew Morton, linux-kernel On Wed, Dec 13, 2006 at 11:56:01PM +0000, Alan wrote: > On Wed, 13 Dec 2006 23:30:55 +0100 > Thomas Gleixner <tglx@linutronix.de> wrote: > > > - IRQ happens > > - kernel handler runs and masks the chip irq, which removes the IRQ > > request > > IRQ is shared with the disk driver, box dead. Plus if this is like the > uio crap in -mm its full of security holes. All of those security holes should now be taken care of, as all of the nasty memory stuff has been either cleaned up or ripped out. Please take a look at the most recent stuff (thomas just mentioned to me on irc that he has a few more minor fixes for it) and let me know if you still see any problems. thanks, greg k-h ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 23:56 ` Alan 2006-12-14 0:08 ` Greg KH @ 2006-12-14 9:15 ` Thomas Gleixner 2006-12-14 11:33 ` Alan 1 sibling, 1 reply; 239+ messages in thread From: Thomas Gleixner @ 2006-12-14 9:15 UTC (permalink / raw) To: Alan Cc: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Wed, 2006-12-13 at 23:56 +0000, Alan wrote: > On Wed, 13 Dec 2006 23:30:55 +0100 > Thomas Gleixner <tglx@linutronix.de> wrote: > > > - IRQ happens > > - kernel handler runs and masks the chip irq, which removes the IRQ > > request > > IRQ is shared with the disk driver, box dead. Err ? IRQ happens IRQ is disabled by the generic handling code Handler is invoked and checks, whether the irq is from the device or not. - If not, it returns IRQ_NONE, so the next driver (e.g. disk) is invoked. - If yes, it masks the chip on the device, which disables the chip interrupt line and returns IRQ_HANDLED. In both cases the IRQ gets reenabled from the generic irq handling code on return, so why is the box dead ? tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-14 9:15 ` Thomas Gleixner @ 2006-12-14 11:33 ` Alan 0 siblings, 0 replies; 239+ messages in thread From: Alan @ 2006-12-14 11:33 UTC (permalink / raw) To: tglx Cc: Benjamin Herrenschmidt, Linus Torvalds, Greg KH, Andrew Morton, linux-kernel > > IRQ is shared with the disk driver, box dead. > > Err ? > > IRQ happens > > IRQ is disabled by the generic handling code > > Handler is invoked and checks, whether the irq is from the device or > not. > - If not, it returns IRQ_NONE, so the next driver (e.g. disk) is > invoked. > - If yes, it masks the chip on the device, which disables the chip > interrupt line and returns IRQ_HANDLED. > > In both cases the IRQ gets reenabled from the generic irq handling code > on return, so why is the box dead ? I wrote this before your "generic" layer was in fact explained further to not be generic at all and involve a new driver for each device. Your original explanation was not clear. Alan ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:14 ` Benjamin Herrenschmidt 2006-12-13 22:30 ` Thomas Gleixner @ 2006-12-13 22:40 ` Thomas Gleixner 2006-12-13 22:45 ` Benjamin Herrenschmidt 1 sibling, 1 reply; 239+ messages in thread From: Thomas Gleixner @ 2006-12-13 22:40 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: > Oh, it works well enough for non shared iqs if you are really anal about It works well for shared irqs. Thats the whole reason why you need an in kernel part. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:40 ` Thomas Gleixner @ 2006-12-13 22:45 ` Benjamin Herrenschmidt 2006-12-13 23:15 ` Thomas Gleixner 0 siblings, 1 reply; 239+ messages in thread From: Benjamin Herrenschmidt @ 2006-12-13 22:45 UTC (permalink / raw) To: tglx; +Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote: > On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: > > Oh, it works well enough for non shared iqs if you are really anal about > > It works well for shared irqs. Thats the whole reason why you need an in > kernel part. As soon as you have an in-kernel part that is chip specific, yes, of course it works, because essentially, what you have done is a kernel driver for your chip and the whole discussion is moot :-) And I agree, that's the right thing to do btw. Ben. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: [GIT PATCH] more Driver core patches for 2.6.19 2006-12-13 22:45 ` Benjamin Herrenschmidt @ 2006-12-13 23:15 ` Thomas Gleixner 0 siblings, 0 replies; 239+ messages in thread From: Thomas Gleixner @ 2006-12-13 23:15 UTC (permalink / raw) To: Benjamin Herrenschmidt Cc: Linus Torvalds, Greg KH, Andrew Morton, linux-kernel On Thu, 2006-12-14 at 09:45 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote: > > On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: > > > Oh, it works well enough for non shared iqs if you are really anal about > > > > It works well for shared irqs. Thats the whole reason why you need an in > > kernel part. > > As soon as you have an in-kernel part that is chip specific, yes, of > course it works, because essentially, what you have done is a kernel > driver for your chip and the whole discussion is moot :-) And I agree, > that's the right thing to do btw. Still the framework has a benefit, as it removes the bunch of incompatible out of tree attempts to achieve the same result. tglx ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
@ 2006-12-15 23:56 karderio
2006-12-16 0:24 ` Linus Torvalds
0 siblings, 1 reply; 239+ messages in thread
From: karderio @ 2006-12-15 23:56 UTC (permalink / raw)
To: torvalds, linux-kernel
Hi :o)
Linus Torvalds wrote :
> The silly thing is, the people who tend to push most for this are the
> exact SAME people who say that the RIAA etc should not be able to tell
> people what to do with the music copyrights that they own, and that the
> DMCA is bad because it puts technical limits over the rights expressly
> granted by copyright law.
>
> Doesn't anybody else see that as being hypocritical?
>
> So it's ok when we do it, but bad when other people do it? Somehow I'm not
> surprised, but I still think it's sad how you guys are showing a marked
> two-facedness about this.
The comparison of what is being suggested for kernel modules to the
actions of the RIAA doesn't seem very fitting. If anything is being
pushed, and anybody is being told what to do, it seems to be pushing for
"openness" and telling corporations to provide important information
about their products. The RIAA seems to be doing the opposite, enforcing
total control over what they release.
Apparently, the GPL itself is a compromise, in order to assure freedom
of information in a non-ideal world. The GPL combats copyright law with
copyright law, it's paradoxical but not hypocritical, and what is being
suggested here for kernel modules seems analog. To call people who are
struggling for freedom with comparatively few resources "two faced" or
"hypocritical" when they must compromise on their principles doesn't
seem all that fair.
If the "free software community" has the clout to twist vendor's arms to
get them release driver source, then I'm all for it. I'm generally not
at all combative, and would generally argue for leaving people free to
do as they wish. In this case I think the issue, the freedom of
information, is rather an important one, and within reason measures
should be taken to defend it.
Love, Karderio.
"He who receives an idea from me, receives instruction himself without
lessening mine; as he who lights his taper at mine, receives light
without darkening me."
^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-15 23:56 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] karderio @ 2006-12-16 0:24 ` Linus Torvalds 2006-12-16 1:27 ` Alan 2006-12-16 2:32 ` karderio 0 siblings, 2 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 0:24 UTC (permalink / raw) To: karderio; +Cc: linux-kernel On Sat, 16 Dec 2006, karderio wrote: > > If the "free software community" has the clout to twist vendor's arms to > get them release driver source, then I'm all for it. I don't care what you're for, or what your imaginary "free software community" is for. We're "open source", and we're not a religion. We don't "twist peoples arms". We show people what we think is a better way, and we let them participate. We don't force it, we don't twist it, and it's ok not to believe in the GPL or our ideals. In fact, "our ideals" aren't even one unified thing to begin with. We also don't try to pervert copyright into a "you have to _use_ things in a certain way". We don't think "fair use" is a bad thing. We encourage it, and that means that we have to abide by it ourselves. It means, most particularly, that even people we disagree with have that right of "fair use". That, btw, is what "freedom" and "rights" are all about. It's obly meaningful when you grant those rights to people you don't agree with. Also, since you haven't apparently gotten the memo yet, let me point it out to you: the end results don't justify the means, and never did. So arm-twisting doesn't become good just because you think the end result might be worth it. It's still bad. And btw, that "information freedom" thing you talked about is just so much blather and idiotic hogwash. "Information" doesn't want to be free, nor is it somethign you should fight for or necessarily even encourage. It doesn't hold a candle to _peoples_ freedom, the foremost of which is to just disagree with you. Once you allow people to talk and do what they want, that "information freedom" will follow. It's not a religion, and it's not about suppressing other people and other viewpoints. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 0:24 ` Linus Torvalds @ 2006-12-16 1:27 ` Alan 2006-12-16 1:53 ` Linus Torvalds ` (2 more replies) 2006-12-16 2:32 ` karderio 1 sibling, 3 replies; 239+ messages in thread From: Alan @ 2006-12-16 1:27 UTC (permalink / raw) To: Linus Torvalds; +Cc: karderio, linux-kernel > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > it somethign you should fight for or necessarily even encourage. As a pedant that is the one item I have to pick you up on Linus. Information wants to be free, the natural efficient economic state of information is generally free in both senses. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 1:27 ` Alan @ 2006-12-16 1:53 ` Linus Torvalds 2006-12-16 3:59 ` jdow 2006-12-16 17:08 ` David Nicol 2 siblings, 0 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 1:53 UTC (permalink / raw) To: Alan; +Cc: karderio, linux-kernel On Sat, 16 Dec 2006, Alan wrote: > > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > > it somethign you should fight for or necessarily even encourage. > > As a pedant that is the one item I have to pick you up on Linus. > Information wants to be free, the natural efficient economic state of > information is generally free in both senses. I would say that that is a different thing. It "takes effort" to actually hide information, so in that sense, it's actually more expensive to try to keep it "non-free". But that has nothing to do with the FSF kind of "freedom", the same way "no price" has nothing to do with that freedom. So "information wants to be free" is more about "free as in beer", I'd argue. Trying to suppress information (or spread mis-information) takes real effort. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 1:27 ` Alan 2006-12-16 1:53 ` Linus Torvalds @ 2006-12-16 3:59 ` jdow 2006-12-16 17:08 ` David Nicol 2 siblings, 0 replies; 239+ messages in thread From: jdow @ 2006-12-16 3:59 UTC (permalink / raw) To: Alan, Linus Torvalds; +Cc: karderio, linux-kernel From: "Alan" <alan@lxorguk.ukuu.org.uk> >> blather and idiotic hogwash. "Information" doesn't want to be free, nor >> is >> it somethign you should fight for or necessarily even encourage. > > As a pedant that is the one item I have to pick you up on Linus. > Information wants to be free, the natural efficient economic state of > information is generally free in both senses. Alan, you might as well declare a rock wants to be free. Information does not have a brain that could in any way want to be free. It is all people who want something for nothing who want information to be free. {^_^} JOanne ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 1:27 ` Alan 2006-12-16 1:53 ` Linus Torvalds 2006-12-16 3:59 ` jdow @ 2006-12-16 17:08 ` David Nicol 2 siblings, 0 replies; 239+ messages in thread From: David Nicol @ 2006-12-16 17:08 UTC (permalink / raw) To: linux-kernel On 12/15/06, Alan <alan@lxorguk.ukuu.org.uk> wrote: > > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > > it somethign you should fight for or necessarily even encourage. > > As a pedant that is the one item I have to pick you up on Linus. > Information wants to be free, the natural efficient economic state of > information is generally free in both senses. I have often thought that "information wants to be free" is a meaningless phrase that tends to stop arguments because it is difficult to understand the words in it. Raw data does not act without agent. The universe does tend towards increasing entropy however. Here's a fun thought experiment: If you burn a book do you free the words? -- He thought he could organize freedom how naive and controlling of him (Bjork, then some) ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 0:24 ` Linus Torvalds 2006-12-16 1:27 ` Alan @ 2006-12-16 2:32 ` karderio 2006-12-16 2:55 ` Linus Torvalds 1 sibling, 1 reply; 239+ messages in thread From: karderio @ 2006-12-16 2:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel Re :o) On Fri, 2006-12-15 at 16:24 -0800, Linus Torvalds wrote: > > On Sat, 16 Dec 2006, karderio wrote: > > > > If the "free software community" has the clout to twist vendor's arms to > > get them release driver source, then I'm all for it. > > I don't care what you're for, or what your imaginary "free software > community" is for. > > We're "open source" and we're not a religion. In the spirit of mutual understanding, I will not say that I do not care "what you are for", despite your at least very unfriendly reply. You are a person, I care about you, no matter how hard that can be. To be as blatantly frank with you as you are with me, I will say I personally do not care much for open source. I do not see the point of having source code if it's owner imposes the same arbitrary restrictions on my use of it as they can on binary, I want more guarantees than that. > We don't "twist peoples arms". I didn't suggest that you twist peoples arms, I was talking about my imaginary "free software community" ;) > We show people what we think is a better way, and we let them > participate. We don't force it, we don't twist it, and it's ok not to > believe in the GPL or our ideals. That seems great, this is also one of the things I aspire to. I was simply suggesting that perhaps a minor compromise to this principle may be in order, which is of course debatable. > In fact, "our ideals" aren't even one unified thing to begin with. I'm sure they're not, I don't really see how that would work to be honest. > We also don't try to pervert copyright into a "you have to _use_ things > in a certain way". We don't think "fair use" is a bad thing. We encourage > it, and that means that we have to abide by it ourselves. It means, most > particularly, that even people we disagree with have that right of "fair > use". As it stands, I believe the licence of the Linux kernel does impose certain restrictions and come with certain obligations. In what is the suggestion for kernel modules fundamentally different from what you already require of your users ? > That, btw, is what "freedom" and "rights" are all about. It's obly > meaningful when you grant those rights to people you don't agree with. Precisely. A community grants users the right to an open source kernel, why should certain vendors take away from this freedom by providing binary only drivers because they don't agree with that community ? > Also, since you haven't apparently gotten the memo yet, let me point it > out to you: the end results don't justify the means, and never did. So > arm-twisting doesn't become good just because you think the end result > might be worth it. It's still bad. That of course was neither suggested nor implied by what I said, at least not intentionally. > And btw, that "information freedom" thing you talked about is just so much > blather and idiotic hogwash. "Information" doesn't want to be free, nor is > it somethign you should fight for or necessarily even encourage. > > It doesn't hold a candle to _peoples_ freedom, the foremost of which is to > just disagree with you. Once you allow people to talk and do what they > want, that "information freedom" will follow. I have no problem with people disagreeing with me, I would even go to as far as encouraging it in a discussion. If I may however, I think it is no more effort to disagree respectfully, rather than being sarcastic, insulting and using words that could be interpreted as downright aggressive. Of course "freedom of information" could never hold a candle to peoples freedom, and it would be ridiculous to suggest so. There is a big difference between "reasonable measures" and "fighting", I don't see where you got that from. I think that the basic problem for which we are seeking a solution is that binary drivers do not permit people to "do what they want", which by your own definition, shows that they take away from "_peoples_ freedom". > It's not a religion, and it's not about suppressing other people and other > viewpoints. I certainly hope I didn't seem to suggest anything like that, you appear to be ranting at me because of your disagreements with some third party. Is "software as a religion" some sort of "joke religion" like Invisible Pink Unicorn or Flying Spaghetti Monsterism ? Love, Karderio. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 2:32 ` karderio @ 2006-12-16 2:55 ` Linus Torvalds 2006-12-16 6:43 ` Willy Tarreau 2006-12-18 21:04 ` karderio 0 siblings, 2 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 2:55 UTC (permalink / raw) To: karderio; +Cc: linux-kernel On Sat, 16 Dec 2006, karderio wrote: > > As it stands, I believe the licence of the Linux kernel does impose > certain restrictions and come with certain obligations Absolutely. And they boil down to something very simple: "Derived works have to be under the same license" where the rest is just really fluff. But the point is, "derived work" is not what _you_ or _I_ define. It's what copyright law defines. And trying to push that definition too far is a total disaster. If you push the definition of derived work to "anything that touches our work", you're going to end up in a very dark and unhappy place. One where the RIAA is your best buddy. And the proposed "we make some technical measure whereby we draw our _own_ lines" is exactly that total disaster. We don't draw our own lines. We accept that the lines are drawn for us by copyright law, and we actually _hope_ that the lines aren't too sharp and too clearcut. Because sharp edges on copyright is the worst possible situation we could ever be in. The reason fair use is so important is exactly that it blunts/dulls the sharp knife that overly strong copyright protection could be. It would be a total disaster if you couldn't quote other peoples work, and if you couldn't make parodies on them, and if you couldn't legally use the knowledge you gained for them. In other words, copyright MUST NOT be seen as some "we own this, and you have no rights AT ALL unless you play along with our rules". Copyright absolutely _has_ to allow others to have some rights to play according to their rules even without our permission, and even if we don't always agree with what they do. And that is why it would be WRONG to think that we have the absolute right to say "that is illegal". It's simply not our place to make that judgement. When you start thinking that you have absolute control over the content or programs you produce, and that the rest of the worlds opinions doesn't matter, you're just _wrong_. And no, "BECAUSE I'M GOOD" is _not_ an excuse. It's never an excuse to do something like that just because you believe you are "in the right". It doesn't matter _how_ much you believe in freedom, or anything else - everybody _always_ thinks that they are in the right. The RIAA I'm sure is in a moral lather because they are protecting their own stronghold of morality against the infidels and barbarians at the gate. So don't go talking about how we should twist peoples arms and force them to be open source of free software. Instead, BE HAPPY that people can take advantage of "loopholes" in copyright protections and can legally do things that you as the copyright owner might not like. Because those "loopholes" are in the end what protects YOU. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 2:55 ` Linus Torvalds @ 2006-12-16 6:43 ` Willy Tarreau 2006-12-16 10:28 ` Rafael J. Wysocki ` (2 more replies) 2006-12-18 21:04 ` karderio 1 sibling, 3 replies; 239+ messages in thread From: Willy Tarreau @ 2006-12-16 6:43 UTC (permalink / raw) To: Linus Torvalds; +Cc: karderio, linux-kernel On Fri, Dec 15, 2006 at 06:55:17PM -0800, Linus Torvalds wrote: > > > On Sat, 16 Dec 2006, karderio wrote: > > > > As it stands, I believe the licence of the Linux kernel does impose > > certain restrictions and come with certain obligations > > Absolutely. And they boil down to something very simple: > > "Derived works have to be under the same license" > > where the rest is just really fluff. > > But the point is, "derived work" is not what _you_ or _I_ define. It's > what copyright law defines. > > And trying to push that definition too far is a total disaster. If you > push the definition of derived work to "anything that touches our work", > you're going to end up in a very dark and unhappy place. One where the > RIAA is your best buddy. > > And the proposed "we make some technical measure whereby we draw our _own_ > lines" is exactly that total disaster. > > We don't draw our own lines. We accept that the lines are drawn for us by > copyright law, and we actually _hope_ that the lines aren't too sharp and > too clearcut. Because sharp edges on copyright is the worst possible > situation we could ever be in. > > The reason fair use is so important is exactly that it blunts/dulls the > sharp knife that overly strong copyright protection could be. All this is about "fair use", and "fair use" comes from compatibility between the author's intent and the user's intent. For this exact reason, I have added a "LICENSE" file [1] in my software (haproxy) stating that I explicitly permit linking with binary code if the user has no other choice (eg: protocols specs obtained under NDA), provided that "derived work" does not steal any GPL code (include files are under LGPL). On the other hand, all "common protocols" are developped under GPL so that normal users are the winners, and everyone is strongly encouraged to use the GPL for their new code to benefit from everyone else's eyes on the code. This clarifies my intent and let developers decide whether *they* are doing legal things or not. Don't you think it would be a good idea to add such a precision in the sources ? It could put an end to all those repeated lessons you have to teach to a lot of people about fair use. Or perhaps you like to put your teacher hat once a month ? :-) Regards, Willy [1] http://haproxy.1wt.eu/download/1.3/src/LICENSE ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 6:43 ` Willy Tarreau @ 2006-12-16 10:28 ` Rafael J. Wysocki 2006-12-16 10:50 ` Willy Tarreau ` (2 more replies) 2006-12-16 14:42 ` Theodore Tso 2006-12-16 16:28 ` Linus Torvalds 2 siblings, 3 replies; 239+ messages in thread From: Rafael J. Wysocki @ 2006-12-16 10:28 UTC (permalink / raw) To: Willy Tarreau; +Cc: Linus Torvalds, karderio, linux-kernel On Saturday, 16 December 2006 07:43, Willy Tarreau wrote: > On Fri, Dec 15, 2006 at 06:55:17PM -0800, Linus Torvalds wrote: > > > > > > On Sat, 16 Dec 2006, karderio wrote: > > > > > > As it stands, I believe the licence of the Linux kernel does impose > > > certain restrictions and come with certain obligations > > > > Absolutely. And they boil down to something very simple: > > > > "Derived works have to be under the same license" > > > > where the rest is just really fluff. > > > > But the point is, "derived work" is not what _you_ or _I_ define. It's > > what copyright law defines. > > > > And trying to push that definition too far is a total disaster. If you > > push the definition of derived work to "anything that touches our work", > > you're going to end up in a very dark and unhappy place. One where the > > RIAA is your best buddy. > > > > And the proposed "we make some technical measure whereby we draw our _own_ > > lines" is exactly that total disaster. > > > > We don't draw our own lines. We accept that the lines are drawn for us by > > copyright law, and we actually _hope_ that the lines aren't too sharp and > > too clearcut. Because sharp edges on copyright is the worst possible > > situation we could ever be in. > > > > The reason fair use is so important is exactly that it blunts/dulls the > > sharp knife that overly strong copyright protection could be. > > All this is about "fair use", and "fair use" comes from compatibility > between the author's intent and the user's intent. For this exact reason, > I have added a "LICENSE" file [1] in my software (haproxy) stating that I > explicitly permit linking with binary code if the user has no other choice > (eg: protocols specs obtained under NDA), provided that "derived work" > does not steal any GPL code (include files are under LGPL). On the other > hand, all "common protocols" are developped under GPL so that normal users > are the winners, and everyone is strongly encouraged to use the GPL for > their new code to benefit from everyone else's eyes on the code. > > This clarifies my intent and let developers decide whether *they* are > doing legal things or not. > > Don't you think it would be a good idea to add such a precision in the > sources ? It could put an end to all those repeated lessons you have to > teach to a lot of people about fair use. Or perhaps you like to put > your teacher hat once a month ? :-) I think the most important problem with the binary-only drivers is that we can't support their users _at_ _all_, but some of them expect us to support them somehow. So, why don't we make an official statement, like something that will appear on the front page of www.kernel.org, that the users of binary-only drivers will never get any support from us? That would make things crystal clear. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 10:28 ` Rafael J. Wysocki @ 2006-12-16 10:50 ` Willy Tarreau 2006-12-16 11:09 ` Rafael J. Wysocki 2006-12-16 15:15 ` Gene Heskett 2006-12-16 16:33 ` Linus Torvalds 2 siblings, 1 reply; 239+ messages in thread From: Willy Tarreau @ 2006-12-16 10:50 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Linus Torvalds, karderio, linux-kernel On Sat, Dec 16, 2006 at 11:28:27AM +0100, Rafael J. Wysocki wrote: > On Saturday, 16 December 2006 07:43, Willy Tarreau wrote: > > On Fri, Dec 15, 2006 at 06:55:17PM -0800, Linus Torvalds wrote: > > > > > > > > > On Sat, 16 Dec 2006, karderio wrote: > > > > > > > > As it stands, I believe the licence of the Linux kernel does impose > > > > certain restrictions and come with certain obligations > > > > > > Absolutely. And they boil down to something very simple: > > > > > > "Derived works have to be under the same license" > > > > > > where the rest is just really fluff. > > > > > > But the point is, "derived work" is not what _you_ or _I_ define. It's > > > what copyright law defines. > > > > > > And trying to push that definition too far is a total disaster. If you > > > push the definition of derived work to "anything that touches our work", > > > you're going to end up in a very dark and unhappy place. One where the > > > RIAA is your best buddy. > > > > > > And the proposed "we make some technical measure whereby we draw our _own_ > > > lines" is exactly that total disaster. > > > > > > We don't draw our own lines. We accept that the lines are drawn for us by > > > copyright law, and we actually _hope_ that the lines aren't too sharp and > > > too clearcut. Because sharp edges on copyright is the worst possible > > > situation we could ever be in. > > > > > > The reason fair use is so important is exactly that it blunts/dulls the > > > sharp knife that overly strong copyright protection could be. > > > > All this is about "fair use", and "fair use" comes from compatibility > > between the author's intent and the user's intent. For this exact reason, > > I have added a "LICENSE" file [1] in my software (haproxy) stating that I > > explicitly permit linking with binary code if the user has no other choice > > (eg: protocols specs obtained under NDA), provided that "derived work" > > does not steal any GPL code (include files are under LGPL). On the other > > hand, all "common protocols" are developped under GPL so that normal users > > are the winners, and everyone is strongly encouraged to use the GPL for > > their new code to benefit from everyone else's eyes on the code. > > > > This clarifies my intent and let developers decide whether *they* are > > doing legal things or not. > > > > Don't you think it would be a good idea to add such a precision in the > > sources ? It could put an end to all those repeated lessons you have to > > teach to a lot of people about fair use. Or perhaps you like to put > > your teacher hat once a month ? :-) > > I think the most important problem with the binary-only drivers is that we > can't support their users _at_ _all_, but some of them expect us to support > them somehow. Agreed this is the most important problem. > So, why don't we make an official statement, like something that will appear > on the front page of www.kernel.org, that the users of binary-only drivers > will never get any support from us? That would make things crystal clear. This would constitute a good starting point. But what I was trying to address is the other side of the problem : all the politicial discussions on LKML which make the developers waste their time always trying to explain the same things to extremist people (you see, "we must forbid binary drivers to protect users freedom" and "I'm free to run whatever I want"). I don't care at all about what those people think and I don't like the way they want to impose their vision to others. But above all, but I'm fed up with those recurrent subjects on development and bug reporting mailing list, they waste everyone's time. > Greetings, > Rafael Regards, Willy ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 10:50 ` Willy Tarreau @ 2006-12-16 11:09 ` Rafael J. Wysocki 0 siblings, 0 replies; 239+ messages in thread From: Rafael J. Wysocki @ 2006-12-16 11:09 UTC (permalink / raw) To: Willy Tarreau; +Cc: Linus Torvalds, karderio, linux-kernel On Saturday, 16 December 2006 11:50, Willy Tarreau wrote: > On Sat, Dec 16, 2006 at 11:28:27AM +0100, Rafael J. Wysocki wrote: > > On Saturday, 16 December 2006 07:43, Willy Tarreau wrote: > > > On Fri, Dec 15, 2006 at 06:55:17PM -0800, Linus Torvalds wrote: > > > > > > > > > > > > On Sat, 16 Dec 2006, karderio wrote: > > > > > > > > > > As it stands, I believe the licence of the Linux kernel does impose > > > > > certain restrictions and come with certain obligations > > > > > > > > Absolutely. And they boil down to something very simple: > > > > > > > > "Derived works have to be under the same license" > > > > > > > > where the rest is just really fluff. > > > > > > > > But the point is, "derived work" is not what _you_ or _I_ define. It's > > > > what copyright law defines. > > > > > > > > And trying to push that definition too far is a total disaster. If you > > > > push the definition of derived work to "anything that touches our work", > > > > you're going to end up in a very dark and unhappy place. One where the > > > > RIAA is your best buddy. > > > > > > > > And the proposed "we make some technical measure whereby we draw our _own_ > > > > lines" is exactly that total disaster. > > > > > > > > We don't draw our own lines. We accept that the lines are drawn for us by > > > > copyright law, and we actually _hope_ that the lines aren't too sharp and > > > > too clearcut. Because sharp edges on copyright is the worst possible > > > > situation we could ever be in. > > > > > > > > The reason fair use is so important is exactly that it blunts/dulls the > > > > sharp knife that overly strong copyright protection could be. > > > > > > All this is about "fair use", and "fair use" comes from compatibility > > > between the author's intent and the user's intent. For this exact reason, > > > I have added a "LICENSE" file [1] in my software (haproxy) stating that I > > > explicitly permit linking with binary code if the user has no other choice > > > (eg: protocols specs obtained under NDA), provided that "derived work" > > > does not steal any GPL code (include files are under LGPL). On the other > > > hand, all "common protocols" are developped under GPL so that normal users > > > are the winners, and everyone is strongly encouraged to use the GPL for > > > their new code to benefit from everyone else's eyes on the code. > > > > > > This clarifies my intent and let developers decide whether *they* are > > > doing legal things or not. > > > > > > Don't you think it would be a good idea to add such a precision in the > > > sources ? It could put an end to all those repeated lessons you have to > > > teach to a lot of people about fair use. Or perhaps you like to put > > > your teacher hat once a month ? :-) > > > > I think the most important problem with the binary-only drivers is that we > > can't support their users _at_ _all_, but some of them expect us to support > > them somehow. > > Agreed this is the most important problem. > > > So, why don't we make an official statement, like something that will appear > > on the front page of www.kernel.org, that the users of binary-only drivers > > will never get any support from us? That would make things crystal clear. > > This would constitute a good starting point. But what I was trying > to address is the other side of the problem : all the politicial > discussions on LKML which make the developers waste their time > always trying to explain the same things to extremist people (you > see, "we must forbid binary drivers to protect users freedom" and > "I'm free to run whatever I want"). I don't care at all about what > those people think and I don't like the way they want to impose > their vision to others. But above all, but I'm fed up with those > recurrent subjects on development and bug reporting mailing list, > they waste everyone's time. Agreed. Greetings, Rafael ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 10:28 ` Rafael J. Wysocki 2006-12-16 10:50 ` Willy Tarreau @ 2006-12-16 15:15 ` Gene Heskett 2006-12-17 11:04 ` Geert Uytterhoeven 2006-12-16 16:33 ` Linus Torvalds 2 siblings, 1 reply; 239+ messages in thread From: Gene Heskett @ 2006-12-16 15:15 UTC (permalink / raw) To: linux-kernel; +Cc: Rafael J. Wysocki, Willy Tarreau, Linus Torvalds, karderio On Saturday 16 December 2006 05:28, Rafael J. Wysocki wrote: >On Saturday, 16 December 2006 07:43, Willy Tarreau wrote: [...] >I think the most important problem with the binary-only drivers is that > we can't support their users _at_ _all_, but some of them expect us to > support them somehow. > >So, why don't we make an official statement, like something that will > appear on the front page of www.kernel.org, that the users of > binary-only drivers will never get any support from us? That would > make things crystal clear. > >Greetings, >Rafael I disagree with this, to the extent that I perceive this business of no support for a 'tainted' kernel to be almost in the same category as saying that if we configure and build our own kernels, then we are alone and you don't want to hear about it. Yes, there is a rather large difference in actual fact, but if I come to the list with a firewire or usb problem, we should be capable of divorcing the fact that I may also be using an ati or nvidia supplied driver from the firewire or usb problem at hand. I am not in fact using the ati driver with my 9200SE, as the in-kernel as its plenty good enough for that I do, but that's the point. To automaticly deny supplying what might be helpfull suggestions just because the user has a 'tainted' kernel strikes me as being pretty darned hypocritical, particularly when the user states he has reverted but this instant problem persists. Yes, there have been bad drivers, but they are generally rather quickly known about, and replaced with newer versions in short order if problems of a fixed pattern are known to occur with version xyz of the nvidia stuff. small rant: Ati's track record is not so stellar in terms of timely fixes, but from comments I see, their support may be getting better, but IMO the main support we see is from their PR people announcing yet another linux driver project we rarely see the output of while the card itself is still in production. I've been burnt there, twice now, once I even bought linux drivers from a 3rd party & took a bath on that too, wanting to use such and such a card, waiting till we had a driver for that card, then going after the card only to find it doesn't work, they've replaced the card with a new, completely incompatible version without changing anything on the box, and only the windows cd and the actual card in the box. That's just plain criminal, that box should be carrying at least a new part number so the buyer can make an intelligent choice. /rant But those are *my* problems and I'm a big boy now. I just want to point out that this 'tainted' business, while 90% politically driven, is a huge turnoff for the Joe Sixpacks looking to get the M$ shaft out of an orifice normally used for other things. I also have witnessed more of this argument, which seems to occur at monthly intervals, than I care to. This is not productive use of anyones time. And I've now contributed to the noise so I'll SU... -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 15:15 ` Gene Heskett @ 2006-12-17 11:04 ` Geert Uytterhoeven 0 siblings, 0 replies; 239+ messages in thread From: Geert Uytterhoeven @ 2006-12-17 11:04 UTC (permalink / raw) To: Gene Heskett; +Cc: Linux Kernel Development On Sat, 16 Dec 2006, Gene Heskett wrote: > On Saturday 16 December 2006 05:28, Rafael J. Wysocki wrote: > >On Saturday, 16 December 2006 07:43, Willy Tarreau wrote: > [...] > >I think the most important problem with the binary-only drivers is that > > we can't support their users _at_ _all_, but some of them expect us to > > support them somehow. > > > >So, why don't we make an official statement, like something that will > > appear on the front page of www.kernel.org, that the users of > > binary-only drivers will never get any support from us? That would > > make things crystal clear. > > I disagree with this, to the extent that I perceive this business of no > support for a 'tainted' kernel to be almost in the same category as > saying that if we configure and build our own kernels, then we are alone > and you don't want to hear about it. > > Yes, there is a rather large difference in actual fact, but if I come to There's indeed a big difference. That's why people ask for your .config and for the changes you made to your kernel (especially in cases like `Hi, the kernel crashes with my newly written driver'). > the list with a firewire or usb problem, we should be capable of > divorcing the fact that I may also be using an ati or nvidia supplied > driver from the firewire or usb problem at hand. You can divorce it by not loading the binary-only driver(s) and reproducing the problem. > I am not in fact using the ati driver with my 9200SE, as the in-kernel as > its plenty good enough for that I do, but that's the point. To > automaticly deny supplying what might be helpfull suggestions just > because the user has a 'tainted' kernel strikes me as being pretty darned > hypocritical, particularly when the user states he has reverted but this > instant problem persists. Then the kernel is no longer tainted, right? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 10:28 ` Rafael J. Wysocki 2006-12-16 10:50 ` Willy Tarreau 2006-12-16 15:15 ` Gene Heskett @ 2006-12-16 16:33 ` Linus Torvalds 2 siblings, 0 replies; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 16:33 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Willy Tarreau, karderio, linux-kernel On Sat, 16 Dec 2006, Rafael J. Wysocki wrote: > > I think the most important problem with the binary-only drivers is that we > can't support their users _at_ _all_, but some of them expect us to support > them somehow. Actually, I do think that we've made our position on that side pretty clear. I think people do by-and-large know that if they load a binary module, they simply can't get supported by the kernel developers. We make that fairly clear at module loadign time, and I think it's also something that people who have read linux-kernel or seen other peoples bug-reports are reasonably aware of. I realize that a lot of people never read the kernel mailing list, but they probably don't look at www.kernel.org either - they got their kernel from their distribution. The only way they realize is probably by looking at where they got whatever binary modules they use. That said - it should be noted that a lot of the time when you use a binary module and have an oops, the oops doesn't necessarily have anything to do with your binary module. If I recognize the oops from other reports, I certainly won't say "I'm not going to help you, because you used a binary module". If I can tell where the problem is, the binary module is a non-issue. It's only when we try to debug things that we say "You've got a binary module, you need to reproduce this problem _without_ it, because otherwise we can't bother to waste our time on trying to debug something that may be due to somebody else". Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 6:43 ` Willy Tarreau 2006-12-16 10:28 ` Rafael J. Wysocki @ 2006-12-16 14:42 ` Theodore Tso 2006-12-16 16:30 ` Willy Tarreau 2006-12-16 16:54 ` Jeremy Fitzhardinge 2006-12-16 16:28 ` Linus Torvalds 2 siblings, 2 replies; 239+ messages in thread From: Theodore Tso @ 2006-12-16 14:42 UTC (permalink / raw) To: Willy Tarreau; +Cc: Linus Torvalds, karderio, linux-kernel On Sat, Dec 16, 2006 at 07:43:44AM +0100, Willy Tarreau wrote: > All this is about "fair use", and "fair use" comes from compatibility > between the author's intent and the user's intent. That is NOT TRUE. If the author's intent is that anyone who is using a TV with a screen larger than 29" and with two chairs is a theatrical performance, and so anyone with a large screen TV must ask permission from the MPAA first and pay $$$ before they crack open a DVD, would you think that they should be allowed to claim that watching a DVD isn't fair use unless you obey their rules? I thought not. - Ted P.S. For people who live in the US; write your congresscritters; the MPAA wants to propose new legislation stating exactly this. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 14:42 ` Theodore Tso @ 2006-12-16 16:30 ` Willy Tarreau 2006-12-16 20:23 ` Theodore Tso 2006-12-16 16:54 ` Jeremy Fitzhardinge 1 sibling, 1 reply; 239+ messages in thread From: Willy Tarreau @ 2006-12-16 16:30 UTC (permalink / raw) To: Theodore Tso, Linus Torvalds, karderio, linux-kernel On Sat, Dec 16, 2006 at 09:42:36AM -0500, Theodore Tso wrote: > On Sat, Dec 16, 2006 at 07:43:44AM +0100, Willy Tarreau wrote: > > All this is about "fair use", and "fair use" comes from compatibility > > between the author's intent and the user's intent. > > That is NOT TRUE. If the author's intent is that anyone who is using > a TV with a screen larger than 29" and with two chairs is a theatrical > performance, and so anyone with a large screen TV must ask permission > from the MPAA first and pay $$$ before they crack open a DVD, would > you think that they should be allowed to claim that watching a DVD > isn't fair use unless you obey their rules? > > I thought not. I don't think this is the same case. The film _author_'s primary goal is to have a lot of families buy his DVD to watch it. Whatever the MPAA says, I can consider it "fair use" if a family of 4..8 persons watch the DVD at the same time. However, I may consider it an abuse when a sports club projects the film for 30 persons. [OT] > > - Ted > > P.S. For people who live in the US; write your congresscritters; the > MPAA wants to propose new legislation stating exactly this. I feel sorry for you, really. Sadly, stupid american laws generally contaminate Europe 10 years later, so we will eventually feel sad too. [/OT] Regards, Willy ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 16:30 ` Willy Tarreau @ 2006-12-16 20:23 ` Theodore Tso 2006-12-16 21:04 ` Willy Tarreau 0 siblings, 1 reply; 239+ messages in thread From: Theodore Tso @ 2006-12-16 20:23 UTC (permalink / raw) To: Willy Tarreau; +Cc: Linus Torvalds, karderio, linux-kernel On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote: > I don't think this is the same case. The film _author_'s primary goal is > to have a lot of families buy his DVD to watch it. Whatever the MPAA says, > I can consider it "fair use" if a family of 4..8 persons watch the DVD at > the same time. "You can consider it"? But you're not the author. This is the hypocrisy that Linus was talking about. At the same time that you're trying to dictate to other other people can use their copy of the Linux kernel, when it comes to others people's copyrighted work, you feel to dictate what is and isn't "fair use". That's the big thing about dynamic linking. The GPL has always said it is about distribution, not about use. The dynamic linking of a kernel module happens in the privacy of someone's home. When we try to dictate what people are doing in the privacy in their home, we're no better than the MPAA or the RIAA. As far as whether or not someone is allowed to distribute a binary module that can be linked into the Linux kernel, that's a question of whether the binary module is a derived work or not. And that's not up to us, that's up to the local laws. But before you decide that you want the most extreme form of anything that wanders close to one person's code or header files is a derived work, and to start going to work lobbying your local legislature, recall that there have been those who have claimed that Linux is a derived work of Unix because we used things like #define's for errno codes and structure definitions of ELF binaries. You really sure you want to go there? - Ted ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 20:23 ` Theodore Tso @ 2006-12-16 21:04 ` Willy Tarreau 0 siblings, 0 replies; 239+ messages in thread From: Willy Tarreau @ 2006-12-16 21:04 UTC (permalink / raw) To: Theodore Tso, Linus Torvalds, karderio, linux-kernel On Sat, Dec 16, 2006 at 03:23:12PM -0500, Theodore Tso wrote: > On Sat, Dec 16, 2006 at 05:30:31PM +0100, Willy Tarreau wrote: > > I don't think this is the same case. The film _author_'s primary goal is > > to have a lot of families buy his DVD to watch it. Whatever the MPAA says, > > I can consider it "fair use" if a family of 4..8 persons watch the DVD at > > the same time. > > "You can consider it"? But you're not the author. This is the > hypocrisy that Linus was talking about. At the same time that you're > trying to dictate to other other people can use their copy of the > Linux kernel, when it comes to others people's copyrighted work, you > feel to dictate what is and isn't "fair use". No, I don't want to dictate, it's the opposite, I say what _I_ consider fair use. Other people will consider it other ways. It's exactly the gray area Linus was talking about. As long as all parties agree on one given fair use, there's no problem. Discussion and sometimes litigation is needed when some parties disagree. > That's the big thing about dynamic linking. The GPL has always said > it is about distribution, not about use. The dynamic linking of a > kernel module happens in the privacy of someone's home. When we try > to dictate what people are doing in the privacy in their home, we're > no better than the MPAA or the RIAA. 100% agreed with you on this ! > As far as whether or not someone is allowed to distribute a binary > module that can be linked into the Linux kernel, that's a question of > whether the binary module is a derived work or not. And that's not up > to us, that's up to the local laws. But before you decide that you > want the most extreme form of anything that wanders close to one > person's code or header files is a derived work, and to start going to > work lobbying your local legislature, recall that there have been > those who have claimed that Linux is a derived work of Unix because we > used things like #define's for errno codes and structure definitions > of ELF binaries. You really sure you want to go there? Ted, I think you get me wrong. I don't want to dictate anyone what's derived work and what is not. Instead, it's the opposite. I just want to indicate them what's explicitly permitted by the author and copyright owner (at least by me as the author/copyright owner when I can) so that people can decide by themselves what level of risk they take by doing whatever they want. What I consider the most important is to encourage fair use even in areas I never anticipated, and when possible, try to protect fair users from the GPL zealots who want to bite whenever one gives them an opportunity to abuse the gray area to feel stronger. I have opened even more my software and tried to clarify the reasons why I chose the dual license exactly for this reason. What I was suggesting is to add a clarification with the kernel to avoid those overly long threads on LKML such as this one. It would basically be structured like this : "Use in the following order" : 1) fully respect the license and you're OK. 2) play in the gray area if you need and if you consider it fair use, but seek legal advice from a lawyer (and not LKML) before ! 3) explicitly violate the license, and prepare to get sued sooner or later. For GPL zealots : please do not report what _you_ consider abuse to LKML, contact the abuser, then a lawyer or specialized sites for this. But Linus is right, he's not the only copyright owner, and that makes it harder to touch anything related to license and use. > - Ted Willy ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 14:42 ` Theodore Tso 2006-12-16 16:30 ` Willy Tarreau @ 2006-12-16 16:54 ` Jeremy Fitzhardinge 1 sibling, 0 replies; 239+ messages in thread From: Jeremy Fitzhardinge @ 2006-12-16 16:54 UTC (permalink / raw) To: Theodore Tso, Willy Tarreau, Linus Torvalds, karderio, linux-kernel Theodore Tso wrote: > P.S. For people who live in the US; write your congresscritters; the > MPAA wants to propose new legislation stating exactly this. > (Erm, that was a joke on a parody site; it got widely reported as "news". http://www.bbspot.com/News/2006/11/home-theater-regulations.html Other headlines: MPAA to Thwart Pirates by Making All Movies Suck Sony Unveils New Self-Destructive DVD Player J) ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 6:43 ` Willy Tarreau 2006-12-16 10:28 ` Rafael J. Wysocki 2006-12-16 14:42 ` Theodore Tso @ 2006-12-16 16:28 ` Linus Torvalds 2006-12-16 16:49 ` Willy Tarreau 2 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 16:28 UTC (permalink / raw) To: Willy Tarreau; +Cc: karderio, linux-kernel On Sat, 16 Dec 2006, Willy Tarreau wrote: > > All this is about "fair use", and "fair use" comes from compatibility > between the author's intent and the user's intent. No. "fair use" comes from an INcompatibility between the author's intent and the users intent. In other words, "fair use" kicks in EXACTLY when an author says "you can't copy this except when you [payme, stand on your head for two hours, give your modifications back]", and the user _disagrees_. Users still have rights under copyright law even when the author tries to deny them those rights. Of course, all reasonable true authors tend to agree with fair use. People who actually do "original work" tend to all realize that everybody really feeds off of each others works, and that we're all inspired by authors etc that went before us. So I doubt a lot of real authors, musicians or computer programmers will actually disagree with the notion of fair use, but it's important to realize that fair use is exactly for when the users and the authors rights clash, and the user DOES have rights. Even rights that weren't explicitly given to them by the author. > For this exact reason, I have added a "LICENSE" file [1] in my software > (haproxy) stating that I explicitly permit linking with binary code if > the user has no other choice (eg: protocols specs obtained under NDA), > provided that "derived work" does not steal any GPL code (include files > are under LGPL). On the other hand, all "common protocols" are > developped under GPL so that normal users are the winners, and everyone > is strongly encouraged to use the GPL for their new code to benefit from > everyone else's eyes on the code. > > This clarifies my intent and let developers decide whether *they* are > doing legal things or not. I think that's fine, and I think it may make some of your users happier, and breathe more easily. I don't disagree with that kind of clarification. But: > Don't you think it would be a good idea to add such a precision in the > sources ? I think it would be a hell of a lot better idea if people just realized that they have "fair use" rights whether the authors give them or not, and that the authors copyrights NEVER extend to anything but a "derived work". I find the RIAA's position and the DMCA distasteful, and in that I probably have a lot of things in common with a lot of people on this list. But by _exactly_ the same token, I also find the FSF's position and a lot of GPL zealots' position on this matter very distasteful. Because "fair use" is NOT somethng that should be specified in the license. It's very much something that people have DESPITE any license claiming otherwise. And I'd rather teach people that fundamental fact, than try to confuse the issue EVEN MORE by saying that my copyright only extends to derived works in the license text. That will just make people think that if the license does NOT say that, they don't have fair use. AND THAT IS WRONG. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 16:28 ` Linus Torvalds @ 2006-12-16 16:49 ` Willy Tarreau 2006-12-16 17:20 ` Linus Torvalds 0 siblings, 1 reply; 239+ messages in thread From: Willy Tarreau @ 2006-12-16 16:49 UTC (permalink / raw) To: Linus Torvalds; +Cc: karderio, linux-kernel On Sat, Dec 16, 2006 at 08:28:20AM -0800, Linus Torvalds wrote: > On Sat, 16 Dec 2006, Willy Tarreau wrote: > > > > All this is about "fair use", and "fair use" comes from compatibility > > between the author's intent and the user's intent. > > No. "fair use" comes from an INcompatibility between the author's intent > and the users intent. > > In other words, "fair use" kicks in EXACTLY when an author says "you can't > copy this except when you [payme, stand on your head for two hours, give > your modifications back]", and the user _disagrees_. > > Users still have rights under copyright law even when the author tries to > deny them those rights. I understand your point, but not completely agree with the comparison, because I think that you (as the "author") are in the type of authors you describe below : > Of course, all reasonable true authors tend to agree with fair use. People > who actually do "original work" tend to all realize that everybody really > feeds off of each others works, and that we're all inspired by authors etc > that went before us. So I doubt a lot of real authors, musicians or > computer programmers will actually disagree with the notion of fair use, > but it's important to realize that fair use is exactly for when the users > and the authors rights clash, and the user DOES have rights. Even rights > that weren't explicitly given to them by the author. And it is in this situation that I see the compatibility between the user's and the author's intent : if the user doubts about his fair use and asks the author, generally the author agrees to extend his fair use perimeter. (...) > I think it would be a hell of a lot better idea if people just realized ^^^^^^^^^^^^^^^^^^^^^^^ > that they have "fair use" rights whether the authors give them or not, and > that the authors copyrights NEVER extend to anything but a "derived work". > > I find the RIAA's position and the DMCA distasteful, and in that I > probably have a lot of things in common with a lot of people on this list. > But by _exactly_ the same token, I also find the FSF's position and a lot > of GPL zealots' position on this matter very distasteful. ^^^^^^^^^^^ You see my point ? The users generally understand "fair use" easier than the GPL zealots which pollute the list or strip down kernel drivers to save users' freedom. And it is to protect fair users from those people that I explicited my intent along with the license. > Because "fair use" is NOT somethng that should be specified in the > license. It's very much something that people have DESPITE any license > claiming otherwise. > > And I'd rather teach people that fundamental fact, than try to confuse the > issue EVEN MORE by saying that my copyright only extends to derived works > in the license text. That will just make people think that if the license > does NOT say that, they don't have fair use. AND THAT IS WRONG. That's a valid point. What is really needed is to tell them that if they doubt, they just have to ask the author and not be advised by any GPL zealot. > Linus Regards, Willy ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 16:49 ` Willy Tarreau @ 2006-12-16 17:20 ` Linus Torvalds 2006-12-16 18:33 ` Dave Jones 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 17:20 UTC (permalink / raw) To: Willy Tarreau; +Cc: karderio, linux-kernel On Sat, 16 Dec 2006, Willy Tarreau wrote: > > I understand your point, but not completely agree with the comparison, > because I think that you (as the "author") are in the type of authors > you describe below : > > > Of course, all reasonable true authors tend to agree with fair use. Sure. Sadly, in this day and age, "copyright owner" and "author" only bear a very passing resemblance to each other. In a lot of areas, the AUTHOR may be a very reasonable person, and realize that fair use is a good thing, and perhaps even realize that in some places even unfair use can be a good thing (do you really think you should pay $20 for a DVD if you make $3 a month in a sweatshop in china? Maybe piracy sometimes is simply better..) But the author may also have his own reasons for wanting to _deny_ fair use. Maybe he's just a royal a-hole, and wants to milk his work for whatever it's worth. But maybe he's a person with an agenda, and wants to ignore fair use because he wants to "improve the world for everybody", never mind that he tries to deny people a fundamental right in the process. I call those people a-holes too (in all fairness, they return the favor, so we're all even ;) But even more commonly, the author simply doesn't control the copyright at all any more. In many areas (and software is one - including even large swaths of free software), the copyrights of a work is not really controlled by the author of the work, but by companies or foundations that have no reason to really try to educate people about "fair use". So I actually think that the authors that actually UNDERSTAND fair use, and realize that people can use portions of their work without permission, AND that actually control their work is a very very very small subset of authors in general. This has nothing to do with software per se, btw. Pick up one of the Calvin & Hobbes books by Bill Watterson - I think it may have been the "10 year anniversary" one - where he talks about the disagreements he had with the people who actually controlled the copyrights (and I think also some of the people who used his artwork without any permission - the line between "fair use" and "illegal" really is a murky one, and while we should celebrate that murkiness, it's also why people disagree). > > And I'd rather teach people that fundamental fact, than try to confuse the > > issue EVEN MORE by saying that my copyright only extends to derived works > > in the license text. That will just make people think that if the license > > does NOT say that, they don't have fair use. AND THAT IS WRONG. > > That's a valid point. What is really needed is to tell them that if they > doubt, they just have to ask the author and not be advised by any GPL zealot. Well, in open source, there often isn't any one "the author". So you can't do that. And when there is, as mentioned, he may not actually even have the legal right any more to give you any license advice. And even when he does hold the copyrights, he may change his mind later. So in the end, the thing you can and should depend on is: the license text itself (and happily, the GPLv2 very clearly talks about the real line being "derived work" - it may be a murky line, and they seem to want to change that to something harder in the GPLv3, but it's a good line), a separate signed contract, or simply a legal opinion, preferably by a judge in a court of law. Of course, it very seldom gets to that kind of issue. People tend to just walk very gently around it all. If you want to be safe, you NEVER do any binary modules. The only _obviously_ safe thing is to always do only what the license very explicitly allows you to, and in the case of the GPLv2, that's to release all modifications under the same GPLv2. Anything else, you have to make some really scary decisions. Can a judge decide that a binary module is a derived work even though you didn't actually use any code? The real answer is: HELL YES. It's _entirely_ possible that a judge would find NVidia and ATI in violation of the GPLv2 with their modules. Judges have done stranger things. And it's not my place to say what the limit of "derived work" actually is. It all probably depends on a lot of circumstances, and there simply isn't an easy answer. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 17:20 ` Linus Torvalds @ 2006-12-16 18:33 ` Dave Jones 2006-12-17 1:56 ` Adrian Bunk ` (2 more replies) 0 siblings, 3 replies; 239+ messages in thread From: Dave Jones @ 2006-12-16 18:33 UTC (permalink / raw) To: Linus Torvalds; +Cc: Willy Tarreau, karderio, linux-kernel On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote: > Anything else, you have to make some really scary decisions. Can a judge > decide that a binary module is a derived work even though you didn't > actually use any code? The real answer is: HELL YES. It's _entirely_ > possible that a judge would find NVidia and ATI in violation of the GPLv2 > with their modules. ATI in particular, I'm amazed their lawyers OK'd stuff like.. +ifdef STANDALONE MODULE_LICENSE(GPL); +endif This a paraphrased diff, it's been a while since I've seen it. It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, but the usual use case is that it's built-in to fglrx.ko, which sounds incredibly dubious. Now, AGPGART has a murky past wrt licenses. It initally was imported into the tree with the license "GPL plus additional rights". Nowhere was it actually documented what those rights were, but I'm fairly certain it wasn't to enable nonsense like the above. As it came from the XFree86 folks, it's more likely they really meant "Dual GPL/MIT" or similar. When I took over, any new code I wrote I explicitly set out to mark as GPL code, as my modifications weren't being contributed back to X, they were going back to the Linux kernel. ATI took those AGPv3 modifications from a 2.5 kernel, backported them to their 2.4 driver, and when time came to do a 2.6 driver, instead of doing the sensible thing and dropping them in favour of using the kernel AGP driver, they chose to forward port their unholy abomination to 2.6. It misses so many fixes (and introduces a number of other problems) that its just unfunny. The thing that really ticks me off though is the free support ATI seem to think they're entitled to. I've had end-users emailing me "I asked ATI about this crash I've been seeing with fglrx, and they asked me to mail you". I invest my time into improving free drivers. When companies start expecting me to debug their part binary garbage mixed with license violations, frankly, I think they're taking the piss. A year and a half ago, I met an ATI engineer at OLS, who told me they were going to 'resolve this'. I'm still waiting. I live in hope that the AMD buyout will breathe some sanity into ATI. Then again, I've only a limited supply of optimism. Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 18:33 ` Dave Jones @ 2006-12-17 1:56 ` Adrian Bunk 2006-12-17 3:06 ` Adrian Bunk 2006-12-17 20:23 ` Gerhard Mack 2006-12-21 19:39 ` Pavel Machek 2 siblings, 1 reply; 239+ messages in thread From: Adrian Bunk @ 2006-12-17 1:56 UTC (permalink / raw) To: Dave Jones, Linus Torvalds, Willy Tarreau, karderio, linux-kernel On Sat, Dec 16, 2006 at 01:33:01PM -0500, Dave Jones wrote: > On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote: > > > Anything else, you have to make some really scary decisions. Can a judge > > decide that a binary module is a derived work even though you didn't > > actually use any code? The real answer is: HELL YES. It's _entirely_ > > possible that a judge would find NVidia and ATI in violation of the GPLv2 > > with their modules. > > ATI in particular, I'm amazed their lawyers OK'd stuff like.. > > +ifdef STANDALONE > MODULE_LICENSE(GPL); > +endif > > This a paraphrased diff, it's been a while since I've seen it. > It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, > but the usual use case is that it's built-in to fglrx.ko, which sounds > incredibly dubious. >... Current versions contain MODULE_LICENSE("GPL and additional rights"); ... > The thing that really ticks me off though is the free support ATI seem > to think they're entitled to. I've had end-users emailing me > "I asked ATI about this crash I've been seeing with fglrx, and they > asked me to mail you". > > I invest my time into improving free drivers. When companies start > expecting me to debug their part binary garbage mixed with license > violations, frankly, I think they're taking the piss. > > A year and a half ago, I met an ATI engineer at OLS, who told me they > were going to 'resolve this'. I'm still waiting. > I live in hope that the AMD buyout will breathe some sanity into ATI. > Then again, I've only a limited supply of optimism. But who's actually taking legal actions? Perhaps pending legal changes that will turn copyright violations into crimes might help to take legal actions without the legal risks of civil trials. Otherwise, it seems to be highly unlikely that anyone will want to sue a company that is often located in a different country, and the only possible legal action will be cease and desist letters against people who are infriding the copyright by e.g. selling Linux distributions containing fglrx at Ebay or operating Debian ftp mirrors. That sounds highly unfair, but unfortunately it also seems to be the only effective way for someone without a big wallet to effectively act against such licence violations... > Dave cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 1:56 ` Adrian Bunk @ 2006-12-17 3:06 ` Adrian Bunk 0 siblings, 0 replies; 239+ messages in thread From: Adrian Bunk @ 2006-12-17 3:06 UTC (permalink / raw) To: Dave Jones, Linus Torvalds, Willy Tarreau, karderio, linux-kernel On Sun, Dec 17, 2006 at 02:56:09AM +0100, Adrian Bunk wrote: >... > Otherwise, it seems to be highly unlikely that anyone will want to sue a > company that is often located in a different country, and the only > possible legal action will be cease and desist letters against people > who are infriding the copyright by e.g. selling Linux distributions > containing fglrx at Ebay or operating Debian ftp mirrors. That sounds > highly unfair, but unfortunately it also seems to be the only effective > way for someone without a big wallet to effectively act against such > licence violations... To avoid any misunderstandings: I do not want to threaten anyone, and I do not plan to do such legal actions myself. My point is simply that whoever considers this grey area a good thing and wants to leave clarifications to the lawyers should be aware that e.g. in the fglrx and nvidia cases it's quite possible that the target of legal actions might not be AMD but e.g. the Technical University of Dresden that is distributing the offending code in Germany [1]. cu Adrian [1] by operating ftp.de.debian.org -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 18:33 ` Dave Jones 2006-12-17 1:56 ` Adrian Bunk @ 2006-12-17 20:23 ` Gerhard Mack 2006-12-21 19:39 ` Pavel Machek 2 siblings, 0 replies; 239+ messages in thread From: Gerhard Mack @ 2006-12-17 20:23 UTC (permalink / raw) To: Dave Jones; +Cc: Linus Torvalds, Willy Tarreau, karderio, linux-kernel, support On Sat, 16 Dec 2006, Dave Jones wrote: > On Sat, Dec 16, 2006 at 09:20:15AM -0800, Linus Torvalds wrote: > > > Anything else, you have to make some really scary decisions. Can a judge > > decide that a binary module is a derived work even though you didn't > > actually use any code? The real answer is: HELL YES. It's _entirely_ > > possible that a judge would find NVidia and ATI in violation of the GPLv2 > > with their modules. > > ATI in particular, I'm amazed their lawyers OK'd stuff like.. > > +ifdef STANDALONE > MODULE_LICENSE(GPL); > +endif > > This a paraphrased diff, it's been a while since I've seen it. > It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, > but the usual use case is that it's built-in to fglrx.ko, which sounds > incredibly dubious. > > Now, AGPGART has a murky past wrt licenses. It initally was imported > into the tree with the license "GPL plus additional rights". > Nowhere was it actually documented what those rights were, but I'm > fairly certain it wasn't to enable nonsense like the above. > As it came from the XFree86 folks, it's more likely they really meant > "Dual GPL/MIT" or similar. > > When I took over, any new code I wrote I explicitly set out to mark as GPL > code, as my modifications weren't being contributed back to X, they were > going back to the Linux kernel. ATI took those AGPv3 modifications from > a 2.5 kernel, backported them to their 2.4 driver, and when time came > to do a 2.6 driver, instead of doing the sensible thing and dropping > them in favour of using the kernel AGP driver, they chose to forward > port their unholy abomination to 2.6. > It misses so many fixes (and introduces a number of other problems) > that its just unfunny. > > The thing that really ticks me off though is the free support ATI seem > to think they're entitled to. I've had end-users emailing me > "I asked ATI about this crash I've been seeing with fglrx, and they > asked me to mail you". > > I invest my time into improving free drivers. When companies start > expecting me to debug their part binary garbage mixed with license > violations, frankly, I think they're taking the piss. > > A year and a half ago, I met an ATI engineer at OLS, who told me they > were going to 'resolve this'. I'm still waiting. > I live in hope that the AMD buyout will breathe some sanity into ATI. > Then again, I've only a limited supply of optimism. You would think ATI's steaming pile of crap would be a good reason for them to give up on the whole binary module thing and just release specs so someone else can write a decent driver. I made the mistake of purchasing an ATI X1600. No open kernel driver.. no open X driver. The ATI drivers don't even complile on amd64 on any recent kernel and their X drivers are prone to random screen corruption that requires nothing less than a full reboot to clear. IMO let those morons keep writing themselves into a corner with this crud and then perhapse they will see for themselves that binary modules are a horribly bad idea instead of having someone else to blame when this whole thing finally fails. Gerhard -- Gerhard Mack gmack@innerfire.net <>< As a computer I find your faith in technology amusing. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 18:33 ` Dave Jones 2006-12-17 1:56 ` Adrian Bunk 2006-12-17 20:23 ` Gerhard Mack @ 2006-12-21 19:39 ` Pavel Machek 2 siblings, 0 replies; 239+ messages in thread From: Pavel Machek @ 2006-12-21 19:39 UTC (permalink / raw) To: Dave Jones, Linus Torvalds, Willy Tarreau, karderio, linux-kernel Hi! > > Anything else, you have to make some really scary decisions. Can a judge > > decide that a binary module is a derived work even though you didn't > > actually use any code? The real answer is: HELL YES. It's _entirely_ > > possible that a judge would find NVidia and ATI in violation of the GPLv2 > > with their modules. > > ATI in particular, I'm amazed their lawyers OK'd stuff like.. > > +ifdef STANDALONE > MODULE_LICENSE(GPL); > +endif > > This a paraphrased diff, it's been a while since I've seen it. > It's GPL if you build their bundled copy of the AGPGART code as agpgart.ko, > but the usual use case is that it's built-in to fglrx.ko, which sounds > incredibly dubious. > > Now, AGPGART has a murky past wrt licenses. It initally was imported > into the tree with the license "GPL plus additional rights". > Nowhere was it actually documented what those rights were, but I'm > fairly certain it wasn't to enable nonsense like the above. > As it came from the XFree86 folks, it's more likely they really meant > "Dual GPL/MIT" or similar. > > When I took over, any new code I wrote I explicitly set out to mark as GPL > code, as my modifications weren't being contributed back to X, they were > going back to the Linux kernel. ATI took those AGPv3 modifications from > a 2.5 kernel, backported them to their 2.4 driver, and when time came Do they actually distribute that AGPv3 + binary blob? In such case, you should simply ask them for the binary blob sources, and take them to the court if they refuse. RedHat should be big enough, and ATI certainly makes enough money... They'll probably resolve the problem fast if they feel legal actions are pending. Pavel -- Thanks for all the (sleeping) penguins. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 2:55 ` Linus Torvalds 2006-12-16 6:43 ` Willy Tarreau @ 2006-12-18 21:04 ` karderio 2006-12-18 22:05 ` Theodore Tso 2006-12-18 22:11 ` Linus Torvalds 1 sibling, 2 replies; 239+ messages in thread From: karderio @ 2006-12-18 21:04 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel Hi :o) On Fri, 2006-12-15 at 18:55 -0800, Linus Torvalds wrote: > But the point is, "derived work" is not what _you_ or _I_ define. It's > what copyright law defines. Of course not. I never suggested trying to define a derived work. > And trying to push that definition too far is a total disaster. If you > push the definition of derived work to "anything that touches our work", > you're going to end up in a very dark and unhappy place. One where the > RIAA is your best buddy. I don't see how what is proposed for blocking non GPL modules at all touches the definition of derived work. Even if according to law and the GPL, binary modules are legal, the proposed changes could still be made. I have realised that the proposed changes do not *impose* any more restriction on the use of the kernel than currently exists. Currently the Kernel is licenced to impose the same licence on derived works, enforce distribution of source code etc. and this by law. The proposed changes do not impose anything, they just make things technically a little more complicated for some, and they can be trivially circumvented if one desires. Maybe not a good idea, but still no excuse for the sort of atrocious bigotry some people are exhibiting here. I do not mean to say this is a good thing, some of the arguments advanced here make me much less enthusiastic as at the beginning. As I said in my first post, and seemed to be promptly ignored, this can only by any use at all if it persuades vendors to provide the essential information about their products without hurting users too much, or further alienating vendors. All this is of course highly debatable, and needs discussing properly, if people are able to communicate in a civil manner that is. Before any fanatic ranting saying that people inducing slight complications are freedom hating Nazis who should be burned at the stake, please contrast this trivial complication with the extremely difficult work that must be done by someone wanting to write a driver when a vendor doesn't provide adequate documentation. It might be noted that in some countries it is quite illegal not to provide documentation for a product, just as it is illegal to limit a product to only work with a specific vendors merchandise when said product is in essence generic. This is the case in France, where these laws are simply ignored by corporations. A large French NFP sued HP last week about them not allowing their PCs to be sold without Windows, so we may finally start to get these laws applied. I have written the NFP to suggest that if the case does not extend to missing hardware documentation, maybe another case would be in order. In the past the people at this NFP have been very civil and cooperative with me. > And that is why it would be WRONG to think that we have the absolute right > to say "that is illegal". It's simply not our place to make that > judgement. When you start thinking that you have absolute control over the > content or programs you produce, and that the rest of the worlds opinions > doesn't matter, you're just _wrong_. I have seen nobody with the ponce to judge people or try to have control over them when arguing for these mods. I think all that has been said has been people trying to interpret the law, it's quite possible they got it wrong. Not that I can blame them, law is a not simple, and I can see people on both "sides" of the argument not getting things quite right here. I would note however that I personally find it distasteful to call people "wrong" rather than respectfully disagreeing with them. > So don't go talking about how we should twist peoples arms and force them > to be open source of free software. Instead, BE HAPPY that people can take > advantage of "loopholes" in copyright protections and can legally do > things that you as the copyright owner might not like. Because those > "loopholes" are in the end what protects YOU. I admit I should not have used the phrase "twist arm", I meant it in an entirely jocular sense, it is a phrase I never employ usually. Of course it is a mistake I regret. The word "persuade" would have been a much better choice. As I hope I clearly explained above, it wasn't suggested to "force" anybody to do anything. Although I don't appreciate insult or aggressively, I choose to ignore it in order to try and advance a reasonable discussion. I will not stand here and let you tell me what to and not to do however. It also makes you seem a bit hypocritical in a discussion where you are claiming to be arguing for "freedom". Love, Karderio. ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-18 21:04 ` karderio @ 2006-12-18 22:05 ` Theodore Tso 2006-12-18 22:11 ` Linus Torvalds 1 sibling, 0 replies; 239+ messages in thread From: Theodore Tso @ 2006-12-18 22:05 UTC (permalink / raw) To: karderio; +Cc: Linus Torvalds, linux-kernel On Mon, Dec 18, 2006 at 10:04:07PM +0100, karderio wrote: > I have realised that the proposed changes do not *impose* any more > restriction on the use of the kernel than currently exists. Currently > the Kernel is licenced to impose the same licence on derived works, > enforce distribution of source code etc. and this by law. The proposed > changes do not impose anything, they just make things technically a > little more complicated for some, and they can be trivially circumvented > if one desires. .... except that the people who proposed these changes have already suggested that these circumventions would be violations of the United States' Digital Milllenium Copyright Act, which has rather draconoian penalties for these "trivial circumventions". Which is precisely why Linus has said that if we go down this path, we are basically using the same tactics as the RIAA and MPAA. And why this kind of arm twisting as "pursuasion" would be a very, VERY bad idea. - Ted ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-18 21:04 ` karderio 2006-12-18 22:05 ` Theodore Tso @ 2006-12-18 22:11 ` Linus Torvalds 2006-12-18 22:42 ` Scott Preece 1 sibling, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-18 22:11 UTC (permalink / raw) To: karderio; +Cc: linux-kernel On Mon, 18 Dec 2006, karderio wrote: > > I don't see how what is proposed for blocking non GPL modules at all > touches the definition of derived work. Even if according to law and the > GPL, binary modules are legal, the proposed changes could still be > made. .. and then what does that mean? It means that we try to say that people cannot do what they LEGALLY can do? In other words, it means that we are pushing a agenda that is no longer neither a technical issue (it's clearly technically _worse_ to not be able to do something) _nor_ a legal issue. So tell me, what does the proposed blocking actually do? It's "big prother, FSF style". And I say NO THANK YOU. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-18 22:11 ` Linus Torvalds @ 2006-12-18 22:42 ` Scott Preece 0 siblings, 0 replies; 239+ messages in thread From: Scott Preece @ 2006-12-18 22:42 UTC (permalink / raw) To: Linus Torvalds; +Cc: karderio, linux-kernel On 12/18/06, Linus Torvalds <torvalds@osdl.org> wrote: > > In other words, it means that we are pushing a agenda that is no longer > neither a technical issue (it's clearly technically _worse_ to not be able > to do something) _nor_ a legal issue. > > So tell me, what does the proposed blocking actually do? > > It's "big prother, FSF style". And I say NO THANK YOU. > > Linus --- Well, you can't really say it's "FSF-style", since the GPLv3 language explicitly gives permission to circumvent any protection measures implemented by a GPLv3 program. Even the FSF doesn't support using the DMCA to support GPL restrictions. scott ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] @ 2006-12-16 18:27 Ricardo Galli 2006-12-16 21:01 ` Linus Torvalds 0 siblings, 1 reply; 239+ messages in thread From: Ricardo Galli @ 2006-12-16 18:27 UTC (permalink / raw) To: linux-kernel > I think it would be a hell of a lot better idea if people just realized > that they have "fair use" rights whether the authors give them or not, and ^^^^^^^^^ > that the authors copyrights NEVER extend to anything but a "derived work" ... > I find the RIAA's position and the DMCA distasteful, and in that I > probably have a lot of things in common with a lot of people on this list. > But by _exactly_ the same token, I also find the FSF's position and a lot > of GPL zealots' position on this matter very distasteful. ... > Because "fair use" is NOT somethng that should be specified in the ^^^^^^^^^ > license. As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried to change or restrict "fair use". GPL[23] covers only to "distibution" of the covered program. The freedom #0 says explicitly: "right to use the program for any purpose". So, I don't see any clash here between GPL/FSF/RMS with "fair use" And you probably know that any GPLed code can be linked and executed with any other program, whatever is its license if it's for personal use (is that worse than "fair use"?). And even if there is a function in linux that disables loading of non GPL modules, it's still allowed under the GPL to distribute a kernel with those functions removed. Any user can load any other module in this kernel without worrying about "fair use" or "derived work", GPL allows her to do it. So, where's the freaking relationship between GPL (or its "zealots") and "fair use"? Who is trying to re-define it? FUD, FUD, FUD. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 18:27 Ricardo Galli @ 2006-12-16 21:01 ` Linus Torvalds 2006-12-17 0:22 ` Ricardo Galli 0 siblings, 1 reply; 239+ messages in thread From: Linus Torvalds @ 2006-12-16 21:01 UTC (permalink / raw) To: Ricardo Galli; +Cc: linux-kernel On Sat, 16 Dec 2006, Ricardo Galli wrote: > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried > to change or restrict "fair use". GPL[23] covers only to "distibution" of the > covered program. The freedom #0 says explicitly: "right to use the program > for any purpose". I'm sorry, but you're just rewriting history. The FSF very much _has_ tried to make "fair use" a very restricted issue. The whole reason the LGPL exists is that people realized that if they don't do something like that, the GPL would have been tried in court, and the FSF's position that anything that touches GPL'd code would probably have been shown to be bogus. In reality, if the FSF actually believed in "fair use", they would just have admitted that GNU libc could have continued to be under the GPL, and that any programs that link against it are obviously not "derived" from it. But no. The FSF has very much tried to confuse and muddle the issue, and instead have claimed that projects like glibc should be done under the "Lesser" GPL. That's just idiocy, but it works as a way to defuse the problem that the FSF has always had with admitting that not only _they_ have "fair use" rights, but others have them too. Do you REALLY believe that a binary becomes a "derived work" of any random library that it gets linked against? If that's not "fair use" of a library that implements a standard library definition, I don't know what is. And yes, the FSF really has tried to push that totally insane argument. So don't tell me that the FSF honors "fair use". They say they do, but they only seem to honor it when it helps _their_ argument, not when it helps "those evil people who try to take advantage of our hard work". The fact is, if you accept fair use, you have to accept it for other people to take advantage of too. Fair use really isn't just a one-way street. Linus ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-16 21:01 ` Linus Torvalds @ 2006-12-17 0:22 ` Ricardo Galli 2006-12-17 4:10 ` Theodore Tso 0 siblings, 1 reply; 239+ messages in thread From: Ricardo Galli @ 2006-12-17 0:22 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel On Saturday 16 December 2006 22:01, Linus Torvalds wrote: > On Sat, 16 Dec 2006, Ricardo Galli wrote: > > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never > > tried to change or restrict "fair use". GPL[23] covers only to > > "distibution" of the covered program. The freedom #0 says explicitly: > > "right to use the program for any purpose". > > I'm sorry, but you're just rewriting history. > > The FSF very much _has_ tried to make "fair use" a very restricted issue. > The whole reason the LGPL exists is that people realized that if they > don't do something like that, the GPL would have been tried in court, and > the FSF's position that anything that touches GPL'd code would probably > have been shown to be bogus. > > In reality, if the FSF actually believed in "fair use", they would just > have admitted that GNU libc could have continued to be under the GPL, and > that any programs that link against it are obviously not "derived" from > it. > > But no. The FSF has very much tried to confuse and muddle the issue, and > instead have claimed that projects like glibc should be done under the > "Lesser" GPL. OK, let assume your perspective of the history is the valid and real one, then, ¿where are all lawsits against other big GPL only projects? For example libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold in court. > The fact is, if you accept fair use, you have to accept it for other > people to take advantage of too. Fair use really isn't just a one-way > street. "Fair use: The right set forth in Section 107 of the United States Copyright Act, to use copyrighted materials for certain purposes, such as criticism, comment, news reporting, teaching, scholarship, and research. The Copyright Act does not define fair use. Instead, whether a use is fair use is determined by balancing these factors: ..." According to the law, I don't see how FSF tries to avoid or to reject the fair use rights. It seems to me you provides us with a copyright law interpretation supported only by the very [narrow] exceptions of the copyright law, a logical fallacy. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] 2006-12-17 0:22 ` Ricardo Galli @ 2006-12-17 4:10 ` Theodore Tso 0 siblings, 0 replies; 239+ messages in thread From: Theodore Tso @ 2006-12-17 4:10 UTC (permalink / raw) To: Ricardo Galli; +Cc: Linus Torvalds, linux-kernel On Sun, Dec 17, 2006 at 01:22:12AM +0100, Ricardo Galli wrote: > OK, let assume your perspective of the history is the valid and real one, > then, ¿where are all lawsits against other big GPL only projects? For example > libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold > in court. There's no need for lawsuits against things like libqt. The question is whether someone who writes a commercial program that happens to dynamically link against libqt is in fact in violation of copyright claims. In such a case, the owners of libqt would have to sue the commercial application writer, not the other way around. There haven't been any such cases, mostly because (a) the FUD generated by the FSF about GPL vs. LGPL has generally been enough to cause application authors to avoid using GPL'ed code even if it would be legally defensible in court, and (b) I personally suspect that the FSF has deliberately not tried to make a test case out of a commercial application dynamically linking against a GPL'ed library. In point of fact, if you compile libss from e2fsprogs on a Solaris machine, and then let the Sun Enterprise Authentication Mechanism (a propietary version of Kerberos v5) link against that version of libss (as opposed to the one derived from the MIT Kerberos version of libss), you can have a propietary Sun binary linking against libss which will called will dynamically pull in the GPL'ed version of readline (or the BSD licensed editline library, whichever one it finds first in its search path). Quick! Is there a GPL violation involved, and if so, who should the FSF try to sue first? There are indeed plenty of cases where the GPL has been upheld in a court of law, but usually it's some straightforward case of an embedded version of Linux being used without releasing source. As far as I know, there has been no case on point about GPL and dynamic linking, and I personally suspect it's at least partially because the FSF is afraid it would lose such a case. (As I've said, at least one law professor of mine from the MIT Sloan School of Management has told me that in her opinion the FSF's theory would be "laughed out of court"). - Ted ^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
@ 2006-12-18 2:43 Brendan Scott
0 siblings, 0 replies; 239+ messages in thread
From: Brendan Scott @ 2006-12-18 2:43 UTC (permalink / raw)
To: gregkh; +Cc: corbet, akpm, mbligh, medwards.linux, torvalds, linux-kernel
> It's just that I'm so damn tired of this whole thing. I'm tired of
> people thinking they have a right to violate my copyright all the time.
> I'm tired of people and companies somehow treating our license in ways
> that are blatantly wrong and feeling fine about it. Because we are a
> loose band of a lot of individuals, and not a company or legal entity,
> it seems to give companies the chutzpah to feel that they can get away
> with violating our license.
Why don't you consider some intermediate position? If the issue is that you don't want people infringing copyright, then don't load the module unless it's accompanied by a [text] file in a standard format which states that the module is not infringing.
So the default would be that non-GPL modules would not be loaded, but that the non-load could be easily circumvented by someone with a legitimate non-GPL module. That would mean truly non infringing modules could be loaded. Moreover, anyone could still load an infringing module, but to do so would mean they would need to actively be either reckless or lying (even if all the fields are left blank) - which would not look very good when it was exposed. It would also help educate those people who are bona fide, but ignorant of their obligations.
The file could include (eg):
Module name:
Version number:
License:
I have read the statement on GPL binary modules and the kernel developers' views on GPL-infringement available from [address]: yes/no
I verify that I have reviewed the developer's statement above and honestly believe that this version of this module does not infringe copyright in the kernel when assessed in accordance with that statement. I also verify that in making this verification I am, or am acting on behalf of, the author(s) and copyright owner(s) of this module : [name]
Date verified: [date]
Name of organisation:
Contact email:
If you're interested, I'd be happy to help draft something more involved.
Regards
Brendan
--
Brendan Scott IT Law Open Source Law
0414 339 227 http://www.opensourcelaw.biz
Liability limited by a scheme approved under Professional Standards Legislation
Open Source Law Weekly digest: oswald@opensourcelaw.biz
^ permalink raw reply [flat|nested] 239+ messages in thread
* Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
@ 2006-12-22 11:48 Niklas Steinkamp
0 siblings, 0 replies; 239+ messages in thread
From: Niklas Steinkamp @ 2006-12-22 11:48 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel
Hi,
Pavel wrote:
> Something is very wrong with German legal system, I'm afraid.
In this case you are right. Our legal system is often very strange.
______________________________________________________________________________
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
^ permalink raw reply [flat|nested] 239+ messages in thread
end of thread, other threads:[~2007-01-22 23:38 UTC | newest] Thread overview: 239+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-12-13 19:52 [GIT PATCH] more Driver core patches for 2.6.19 Greg KH [not found] ` <1166039585152-git-send-email-greg@kroah.com> [not found] ` <11660395913232-git-send-email-greg@kroah.com> [not found] ` <11660395951158-git-send-email-greg@kroah.com> [not found] ` <11660395998-git-send-email-greg@kroah.com> 2006-12-13 19:52 ` [PATCH 5/14] Driver core: show "initstate" of module Greg KH 2006-12-13 19:52 ` [PATCH 6/14] driver core: delete virtual directory on class_unregister() Greg KH 2006-12-13 19:52 ` [PATCH 7/14] DebugFS : inotify create/mkdir support Greg KH 2006-12-13 19:52 ` [PATCH 8/14] DebugFS : coding style fixes Greg KH 2006-12-13 19:53 ` [PATCH 9/14] DebugFS : file/directory creation error handling Greg KH 2006-12-13 19:53 ` [PATCH 10/14] DebugFS : more " Greg KH 2006-12-13 19:53 ` [PATCH 11/14] DebugFS : file/directory removal fix Greg KH 2006-12-13 19:53 ` [PATCH 12/14] Driver core: "platform_driver_probe() can save codespace": save codespace Greg KH 2006-12-13 19:53 ` [PATCH 13/14] Driver core: Make platform_device_add_data accept a const pointer Greg KH 2006-12-13 19:53 ` [PATCH 14/14] Driver core: deprecate PM_LEGACY, default it to N Greg KH 2006-12-13 20:12 ` [GIT PATCH] more Driver core patches for 2.6.19 Linus Torvalds 2006-12-13 20:31 ` Greg KH 2006-12-13 20:58 ` Linus Torvalds 2006-12-13 21:08 ` Linus Torvalds 2006-12-13 21:15 ` Arjan van de Ven 2006-12-14 9:30 ` Muli Ben-Yehuda 2006-12-14 10:13 ` Hans-Jürgen Koch 2006-12-13 21:36 ` Thomas Gleixner 2006-12-13 21:46 ` Benjamin Herrenschmidt 2006-12-13 23:40 ` Greg KH 2006-12-14 8:49 ` Duncan Sands 2006-12-14 9:56 ` Hans-Jürgen Koch 2006-12-14 11:51 ` Olivier Galibert 2006-12-14 12:45 ` Hans-Jürgen Koch 2006-12-14 19:16 ` Olivier Galibert 2006-12-14 12:39 ` Alan 2006-12-14 13:08 ` Hans-Jürgen Koch 2006-12-14 17:02 ` Jan Engelhardt 2006-12-14 17:17 ` Hans-Jürgen Koch 2006-12-14 17:57 ` Jan Engelhardt 2006-12-16 20:13 ` Lee Revell 2006-12-16 20:28 ` Jan Engelhardt 2006-12-14 17:34 ` Bernd Petrovitsch 2006-12-14 17:47 ` Hans-Jürgen Koch 2006-12-14 17:59 ` Bernd Petrovitsch 2006-12-14 12:27 ` James Courtier-Dutton 2006-12-13 20:38 ` Michael K. Edwards 2006-12-13 21:02 ` Greg KH 2006-12-13 21:32 ` Martin Bligh 2006-12-13 21:47 ` Andrew Morton 2006-12-13 22:09 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Greg KH 2006-12-14 0:32 ` Greg KH 2006-12-14 0:43 ` Jonathan Corbet 2006-12-14 0:55 ` Greg KH 2006-12-14 1:00 ` Linus Torvalds 2006-12-14 1:08 ` Michael K. Edwards 2006-12-14 1:30 ` Grzegorz Kulewski 2006-12-14 1:58 ` Greg KH 2006-12-14 4:15 ` Linus Torvalds 2006-12-14 5:39 ` Martin J. Bligh 2006-12-14 6:01 ` Hua Zhong 2006-12-14 11:14 ` Alan 2006-12-14 11:31 ` Hans-Jürgen Koch 2006-12-14 12:42 ` Alan 2006-12-14 12:54 ` Hans-Jürgen Koch 2006-12-14 16:59 ` Greg KH 2006-12-14 18:26 ` Alan 2006-12-14 21:16 ` Greg KH 2006-12-14 12:55 ` Jan Engelhardt 2006-12-14 13:10 ` Arjan van de Ven 2006-12-14 17:17 ` Jan Engelhardt 2006-12-17 10:54 ` Geert Uytterhoeven 2006-12-14 8:03 ` James Morris 2006-12-14 15:39 ` Adrian Bunk 2006-12-14 20:08 ` David Schwartz 2006-12-15 14:05 ` Paolo Ornati 2006-12-17 10:11 ` Geert Uytterhoeven 2006-12-17 10:56 ` Rafael J. Wysocki 2006-12-19 12:57 ` Marek Wawrzyczny 2006-12-19 13:56 ` Diego Calleja 2006-12-19 16:46 ` Gene Heskett 2006-12-19 17:11 ` Bill Nottingham 2006-12-19 17:24 ` Gene Heskett 2006-12-19 17:13 ` Diego Calleja 2006-12-20 5:11 ` Valdis.Kletnieks 2006-12-20 19:29 ` David Schwartz 2006-12-20 20:52 ` Valdis.Kletnieks 2006-12-20 21:10 ` alan 2006-12-21 15:34 ` Marek Wawrzyczny 2006-12-21 16:43 ` Horst H. von Brand 2006-12-21 19:28 ` Valdis.Kletnieks 2006-12-24 3:11 ` Horst H. von Brand 2006-12-20 4:27 ` Steven Rostedt 2006-12-14 13:07 ` Dave Jones 2006-12-14 15:05 ` Adrian Bunk 2006-12-14 16:11 ` Dave Jones 2006-12-14 16:31 ` Olivier Galibert 2006-12-14 15:36 ` Martin J. Bligh 2006-12-14 17:20 ` Jan Engelhardt 2006-12-14 14:12 ` Ben Collins 2006-12-14 15:10 ` James Courtier-Dutton 2006-12-14 16:09 ` Dave Jones 2006-12-14 16:36 ` Ben Collins 2006-12-14 17:34 ` Jan Engelhardt 2006-12-14 19:29 ` Michael Buesch 2006-12-14 20:19 ` Ben Collins 2006-12-14 7:24 ` Jeffrey V. Merkey 2006-12-14 8:21 ` David Woodhouse 2006-12-14 11:25 ` Alan 2007-01-22 23:37 ` dfsg isn't fsf (Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]) Oleg Verych 2006-12-14 14:53 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Theodore Tso 2006-12-14 16:52 ` Linus Torvalds 2006-12-14 17:33 ` Jeff V. Merkey 2006-12-14 18:01 ` Martin J. Bligh 2006-12-14 18:12 ` Jeff V. Merkey 2006-12-14 18:37 ` Linus Torvalds 2006-12-14 18:30 ` Jeff V. Merkey 2006-12-14 9:34 ` James Courtier-Dutton 2006-12-24 11:57 ` Mark Hounschell 2006-12-24 13:22 ` Sean 2006-12-24 14:42 ` Mark Hounschell 2006-12-14 10:49 ` Xavier Bestel 2006-12-14 13:04 ` Dave Jones 2006-12-14 13:46 ` Ben Collins 2006-12-14 17:21 ` Jan Engelhardt 2006-12-14 17:49 ` Ben Collins 2006-12-14 15:46 ` Jeff Garzik 2006-12-14 17:03 ` Linus Torvalds 2006-12-14 17:08 ` Chris Wedgwood 2006-12-14 17:38 ` Christoph Hellwig 2006-12-14 17:52 ` Chris Wedgwood 2006-12-14 18:09 ` Jan Engelhardt 2006-12-18 10:28 ` GPL only modules Eric W. Biederman 2006-12-14 18:15 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eric Sandeen 2006-12-14 18:39 ` Chris Wedgwood 2006-12-14 18:51 ` Linus Torvalds 2006-12-14 19:42 ` Scott Preece 2006-12-14 19:34 ` Jeff V. Merkey 2006-12-15 5:28 ` GPL only modules Alexandre Oliva 2006-12-15 10:13 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Eduard Bloch 2006-12-15 17:44 ` Dave Neuer 2006-12-18 10:55 ` Eric W. Biederman 2006-12-18 17:05 ` Jeff V. Merkey 2006-12-14 19:49 ` Hua Zhong 2006-12-17 10:57 ` Geert Uytterhoeven 2006-12-14 16:17 ` Adrian Bunk 2006-12-14 16:33 ` Alan 2006-12-14 16:54 ` Adrian Bunk 2006-12-14 17:17 ` Theodore Tso 2006-12-14 18:18 ` Alan 2006-12-14 19:51 ` Adrian Bunk 2006-12-21 15:38 ` Pavel Machek 2006-12-23 11:24 ` Adrian Bunk 2006-12-23 21:36 ` Pavel Machek 2006-12-24 1:07 ` Adrian Bunk 2006-12-19 15:12 ` free module selection Markus Elfring 2006-12-14 5:10 ` GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] Bill Nottingham 2006-12-14 8:48 ` Greg KH 2006-12-14 14:02 ` Rik van Riel 2006-12-14 15:42 ` Chris Friesen 2006-12-14 15:47 ` Alan 2006-12-14 15:48 ` Jeff Garzik 2006-12-14 22:21 ` Dave Airlie 2006-12-14 22:26 ` Michael Buesch 2006-12-14 22:39 ` Dave Airlie 2006-12-14 22:45 ` Michael Buesch 2006-12-14 19:32 ` Bill Nottingham 2006-12-14 5:58 ` Nigel Cunningham 2006-12-14 7:54 ` David Schwartz 2006-12-14 8:21 ` David Woodhouse 2006-12-14 10:36 ` Alan 2006-12-14 14:57 ` Adrian Bunk 2006-12-24 14:27 ` Pavel Machek 2006-12-24 19:59 ` Dmitry Torokhov 2006-12-13 22:20 ` [GIT PATCH] more Driver core patches for 2.6.19 Michael K. Edwards 2006-12-13 22:59 ` Kyle Moffett 2006-12-13 23:55 ` Alan 2006-12-14 2:11 ` Al Viro 2006-12-14 17:22 ` Linus Torvalds 2006-12-14 15:13 ` Rik van Riel 2006-12-13 21:48 ` Michael K. Edwards 2006-12-13 21:03 ` Linus Torvalds 2006-12-16 9:05 ` Pavel Machek 2006-12-16 11:04 ` Jörn Engel 2006-12-17 10:49 ` Pavel Machek 2006-12-13 21:14 ` Benjamin Herrenschmidt 2006-12-13 21:22 ` Jan Engelhardt 2006-12-13 23:28 ` Linus Torvalds 2006-12-14 11:18 ` Jan Engelhardt 2006-12-14 11:26 ` Jan Engelhardt 2006-12-14 17:32 ` Linus Torvalds 2006-12-14 18:04 ` Jan Engelhardt 2006-12-14 17:26 ` Linus Torvalds 2006-12-14 20:47 ` Thomas Gleixner 2006-12-14 22:59 ` Linus Torvalds 2006-12-14 23:37 ` Thomas Gleixner 2006-12-13 21:26 ` Linus Torvalds 2006-12-13 22:14 ` Benjamin Herrenschmidt 2006-12-13 22:30 ` Thomas Gleixner 2006-12-13 22:39 ` Benjamin Herrenschmidt 2006-12-13 23:11 ` Thomas Gleixner 2006-12-13 23:39 ` Michael K. Edwards 2006-12-14 0:00 ` Alan 2006-12-13 23:56 ` Alan 2006-12-14 0:08 ` Greg KH 2006-12-14 9:15 ` Thomas Gleixner 2006-12-14 11:33 ` Alan 2006-12-13 22:40 ` Thomas Gleixner 2006-12-13 22:45 ` Benjamin Herrenschmidt 2006-12-13 23:15 ` Thomas Gleixner 2006-12-15 23:56 GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19] karderio 2006-12-16 0:24 ` Linus Torvalds 2006-12-16 1:27 ` Alan 2006-12-16 1:53 ` Linus Torvalds 2006-12-16 3:59 ` jdow 2006-12-16 17:08 ` David Nicol 2006-12-16 2:32 ` karderio 2006-12-16 2:55 ` Linus Torvalds 2006-12-16 6:43 ` Willy Tarreau 2006-12-16 10:28 ` Rafael J. Wysocki 2006-12-16 10:50 ` Willy Tarreau 2006-12-16 11:09 ` Rafael J. Wysocki 2006-12-16 15:15 ` Gene Heskett 2006-12-17 11:04 ` Geert Uytterhoeven 2006-12-16 16:33 ` Linus Torvalds 2006-12-16 14:42 ` Theodore Tso 2006-12-16 16:30 ` Willy Tarreau 2006-12-16 20:23 ` Theodore Tso 2006-12-16 21:04 ` Willy Tarreau 2006-12-16 16:54 ` Jeremy Fitzhardinge 2006-12-16 16:28 ` Linus Torvalds 2006-12-16 16:49 ` Willy Tarreau 2006-12-16 17:20 ` Linus Torvalds 2006-12-16 18:33 ` Dave Jones 2006-12-17 1:56 ` Adrian Bunk 2006-12-17 3:06 ` Adrian Bunk 2006-12-17 20:23 ` Gerhard Mack 2006-12-21 19:39 ` Pavel Machek 2006-12-18 21:04 ` karderio 2006-12-18 22:05 ` Theodore Tso 2006-12-18 22:11 ` Linus Torvalds 2006-12-18 22:42 ` Scott Preece 2006-12-16 18:27 Ricardo Galli 2006-12-16 21:01 ` Linus Torvalds 2006-12-17 0:22 ` Ricardo Galli 2006-12-17 4:10 ` Theodore Tso 2006-12-18 2:43 Brendan Scott 2006-12-22 11:48 Niklas Steinkamp
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).