[GIT PATCH] more Driver core patches for 2.6.19
Greg KH
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Greg KH
Class virtual directory is created as the need arises.
But it is not deleted when the class is unregistered.
Signed-off-by: Akinobu Mita <akinob...@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gre...@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
Greg KH
Show the initialization state(live, coming, going) of the module:
$ cat /sys/module/usbcore/initstate
live
Signed-off-by: Kay Sievers <kay.s...@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gre...@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
Greg KH
Minor coding style fixes along the way : 80 cols and a white space.
Signed-off-by: Mathieu Desnoyers <mathieu....@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gre...@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;
Greg KH
Add inotify create and mkdir events to DebugFS.
Signed-off-by: Mathieu Desnoyers <mathieu....@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gre...@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)
Greg KH
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....@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gre...@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);
Greg KH
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....@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gre...@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;
Greg KH
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....@polymtl.ca>
Signed-off-by: Greg Kroah-Hartman <gre...@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);
Linus Torvalds
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
Greg KH
>
>
> 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
Michael K. Edwards
> 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
Linus Torvalds
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
Greg KH
> 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
Linus Torvalds
On Wed, 13 Dec 2006, Michael K. Edwards wrote:
>
> On 12/13/06, Linus Torvalds <torv...@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
Linus Torvalds
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.
Benjamin Herrenschmidt
>
> 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.
Arjan van de Ven
>
> 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.
Jan Engelhardt
>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'
--
Linus Torvalds
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
Thomas Gleixner
> 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
Benjamin Herrenschmidt
> 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.
Andrew Morton
Martin Bligh <mbl...@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)
Michael K. Edwards
> 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
Martin Bligh
> 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.
Greg KH
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbl...@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
Benjamin Herrenschmidt
> 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.
Michael K. Edwards
> On Wed, 13 Dec 2006 13:32:50 -0800
> Martin Bligh <mbl...@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
Thomas Gleixner
> 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
Thomas Gleixner
It works well for shared irqs. Thats the whole reason why you need an in
kernel part.
tglx
Benjamin Herrenschmidt
> 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.
Benjamin Herrenschmidt
> 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.
Kyle Moffett
> On 12/13/06, Andrew Morton <ak...@osdl.org> wrote:
>> On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh
>> <mbl...@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
Thomas Gleixner
> > 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
Thomas Gleixner
> 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
Linus Torvalds
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
Michael K. Edwards
> 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
Greg KH
> 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
Alan
> 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.
Alan
Thomas Gleixner <tg...@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.
Alan
> 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.
Greg KH
> On Wed, 13 Dec 2006 23:30:55 +0100
> Thomas Gleixner <tg...@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
Greg KH
> On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
> > On Wed, 13 Dec 2006 13:32:50 -0800
> > Martin Bligh <mbl...@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 <gre...@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 <gre...@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...@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 <gr...@kroah.com> or <gre...@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);
Greg KH
> 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);
>
> 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 <gre...@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 <gre...@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...@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 <gr...@kroah.com> <gre...@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);
Linus Torvalds
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.
Jonathan Corbet
> + 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
Michael K. Edwards
no, teach suits how to leave more
fish to go around
Cheers,
- Michael
Greg KH
> Hi,
>
> I think that...
>
> On Wed, 13 Dec 2006, Greg KH wrote:
>
> ... (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 <gre...@suse.de>
>
>
> 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
Grzegorz Kulewski
I think that...
On Wed, 13 Dec 2006, Greg KH wrote:
> From: Greg Kroah-Hartmna <gre...@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 <gre...@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?
-
Al Viro
> > 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?
Linus Torvalds
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
Bill Nottingham
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
Martin J. Bligh
>
> 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.
Hua Zhong
> 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?
Jeffrey V. Merkey
Well said, and I agree with ALL of your statements contained in this
post. About damn time this was addressed.
Jeff
Nigel Cunningham
Good arguments have already been put against it, so I'll just keep it
short and sweet (FWIW)
Nacked-by: Nigel Cunningham <ni...@suspend2.net>
Regards,
Nigel
David Schwartz
> 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
James Morris
> 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
<jmo...@namei.org>
David Woodhouse
> 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
David Woodhouse
> 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
Greg KH
>
> Greg KH (gre...@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.
Duncan Sands
> 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.
Thomas Gleixner
> On Wed, 13 Dec 2006 23:30:55 +0100
> Thomas Gleixner <tg...@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
Muli Ben-Yehuda
> 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
Hans-Jürgen Koch
> 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
Alan
> 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
Hans-Jürgen Koch
> > 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
Alan
"Hua Zhong" <hzh...@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.
Alan
David Woodhouse <dw...@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
Jan Engelhardt
>> 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'
--
Alan
>
> 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
Jan Engelhardt
> 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)
Hans-Jürgen Koch
> On Wed, 13 Dec 2006 22:01:15 -0800
> "Hua Zhong" <hzh...@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
Xavier Bestel
> 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.
Olivier Galibert
> 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.
James Courtier-Dutton
>> 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
Alan
Hans-Jürgen Koch <h...@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.
Alan
Hans-Jürgen Koch <h...@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
Hans-Jürgen Koch
> 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
Hans-Jürgen Koch
> On Thu, 14 Dec 2006 12:31:16 +0100
> Hans-Jürgen Koch <h...@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
Dave Jones
> 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
Dave Jones
> 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.
Jan Engelhardt
On Dec 14 2006 12:42, Alan wrote:
>On Thu, 14 Dec 2006 12:31:16 +0100
>Hans-Jürgen Koch <h...@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'
--
Hans-Jürgen Koch
> On Thu, 14 Dec 2006 10:56:03 +0100
> Hans-Jürgen Koch <h...@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
Arjan van de Ven
> On Dec 14 2006 12:42, Alan wrote:
> >On Thu, 14 Dec 2006 12:31:16 +0100
> >Hans-Jürgen Koch <h...@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 .. )
Ben Collins
> So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees
> 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.
Rik van Riel
> 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.
Ben Collins
> 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?
vadim....@gmail.com
Working in a company that has to deal with RIAA and the like, and
seeing them (RIAA) kill the music industry, it is very sad to see
people, who are talking about freedom, impose all sorts of restrictions
and limitations to make damn sure everyone is "free" their way...
Hope there are enough people with common sense to stop this "mandatory
freedom" from happening.
I guess I'll put this quote as a footnote on my mail:
> 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).
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
Adrian Bunk
> > 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
Adrian Bunk
> 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
-
James Courtier-Dutton
>
> 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
Rik van Riel
> 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
Theodore Tso
>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
Adrian Bunk
> 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
-
Alan
> 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
Martin J. Bligh
> 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.
Jeff Garzik
> 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
Jeff Garzik
> 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/
Chris Friesen
> 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
Dave Jones
> 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