Re: [GIT PATCH] more Driver core patches for 2.6.19
> Ok, what kind of ass-hat idiotic thing is this?
>
> irqreturn_t uio_irq_handler(int irq, void *dev_id)
> {
> return IRQ_HANDLED;
> }
>
> exactly what is the point here? No way will I pull this kind of crap. You
> just seem to have guaranteed a dead machine if the irq is level-triggered,
> since it will keep on happening forever.
>
> Please remove.
>
> YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!
Actually, you can... but wether you want is a different story :-)
You can simply mask it, have it handled by userspace and re-enable it
when that's done. Though say hello to horrible interrupt latencies and
hope you aren't sharing it with anything critical...
I don't mean I -like- the approach... I just say it can be made to
sort-of work. But I don't see the point.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006, Linus Torvalds wrote: > > Btw: there's one driver we _know_ we want to support in user space, and > that's the X kind of direct-rendering thing. So if you can show that this > driver infrastructure actually makes sense as a replacement for the DRI > layer, then _that_ would be a hell of a convincing argument. Btw, the other side of this argument is that if a user-space driver infrastructure can _not_ help the DRI kind of situation, then it's largely by definition not interesting. Merging something like that would just mean that we end up with multiple _different_ user-space helper infrastructure shells, which sounds distinctly unpalatable. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006, Michael K. Edwards wrote: > > On 12/13/06, Linus Torvalds <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: > Seriously, though, please please pretty please do not allow a facility > for "going through a simple interface to get accesses to irqs and > memory regions" into the mainline kernel, with or without toy ISA > examples. Why? X does it today :) > Embedded systems integrators have enough trouble with chip vendors who > think that exposing the device registers to userspace constitutes a > "driver". Yes, and because of this, they create binary only drivers today. Lots of them. All over the place. Doing crazy stupid crap in kernelspace. Then there are people who do irq stuff in userspace but get it wrong. I've seen that happen many times in lots of different research papers and presentations. This interface does it correctly, and it allows those people who for some reason feel they do want to keep their logic in non-gpl code, to do it. It also allows code that needs floating point to not be in the kernel and in one instance using this interface actually sped up the device because of the lack of the need to go between kernel and userspace a bunch of times. > The correct description is more like "porting shim for MMU-less RTOS > tasks"; and if the BSP vendors of the world can make a nickel > supplying them, more power to them. Just not in mainline, please. Again, X does this today, and does does lots of other applications. This is a way to do it in a sane manner, to keep people who want to do floating point out of the kernel, and to make some embedded people much happier to use Linux, gets them from being so mad at Linux because we keep changing the internal apis, and makes me happier as they stop violating my copyright by creating closed drivers in the kernel. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On 12/13/06, Linus Torvalds <[EMAIL PROTECTED]> wrote: Ok, what kind of ass-hat idiotic thing is this? C'mon, Linus, tell us how you _really_ feel. Seriously, though, please please pretty please do not allow a facility for "going through a simple interface to get accesses to irqs and memory regions" into the mainline kernel, with or without toy ISA examples. Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a "driver". The correct description is more like "porting shim for MMU-less RTOS tasks"; and if the BSP vendors of the world can make a nickel supplying them, more power to them. Just not in mainline, please. Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 12:12:04PM -0800, Linus Torvalds wrote:
>
>
> On Wed, 13 Dec 2006, Greg KH wrote:
> >
> > - userspace io driver interface added. This allows the ability
> > to write userspace drivers for some types of hardware much
> > easier than before, going through a simple interface to get
> > accesses to irqs and memory regions. A small kernel portion
> > is still needed to handle the irq properly, but that is it.
>
> Ok, what kind of ass-hat idiotic thing is this?
>
> irqreturn_t uio_irq_handler(int irq, void *dev_id)
> {
> return IRQ_HANDLED;
> }
>
> exactly what is the point here? No way will I pull this kind of crap. You
> just seem to have guaranteed a dead machine if the irq is level-triggered,
> since it will keep on happening forever.
It's a stupid test module for the uio core for isa devices. It's not
the main code, or core.
> Please remove.
>
> YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!
I agree, that's why this code doesn't let userspace sort it out. You
have to have a kernel driver to handle the irq.
> It's really that easy. The irq handler has to be _entirely_ in kernel
> space. No user-space ass-hattery here.
Agreed.
> And I don't care one whit if it happens to work on parport with an old
> legacy ISA interrupt that is edge-triggered. That's not even the
> interesting case. Never will be.
I agree. But that's all that this test module did. It handled an isa
interrupt that was edge triggered.
> NAK NAK NAK NAK.
Ok, I can pull this example module out if you want, but people seem to
want examples these days. If I do that, any objection to the rest?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] more Driver core patches for 2.6.19
Here are some more driver core patches for 2.6.19 They contain: - minor driver core bugfixes and memory savings - debugfs bugfixes and inotify support added. - userspace io driver interface added. This allows the ability to write userspace drivers for some types of hardware much easier than before, going through a simple interface to get accesses to irqs and memory regions. A small kernel portion is still needed to handle the irq properly, but that is it. - other minor cleanups and fixes. All of these patches have been in the -mm tree for a while. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h Documentation/DocBook/kernel-api.tmpl |4 + Documentation/DocBook/uio-howto.tmpl | 434 +++ drivers/Kconfig |1 + drivers/Makefile |1 + drivers/base/class.c |2 + drivers/base/platform.c |4 +- drivers/uio/Kconfig | 39 ++ drivers/uio/Makefile |4 + drivers/uio/uio.c | 618 + drivers/uio/uio_dummy.c | 174 + drivers/uio/uio_events.c | 119 +++ drivers/uio/uio_irq.c | 86 + drivers/uio/uio_parport.c | 84 + fs/debugfs/inode.c| 39 ++- include/linux/platform_device.h |2 +- include/linux/uio_driver.h| 71 kernel/module.c | 25 ++ kernel/power/Kconfig |9 +- 18 files changed, 1700 insertions(+), 16 deletions(-) create mode 100644 Documentation/DocBook/uio-howto.tmpl create mode 100644 drivers/uio/Kconfig create mode 100644 drivers/uio/Makefile create mode 100644 drivers/uio/uio.c create mode 100644 drivers/uio/uio_dummy.c create mode 100644 drivers/uio/uio_events.c create mode 100644 drivers/uio/uio_irq.c create mode 100644 drivers/uio/uio_parport.c create mode 100644 include/linux/uio_driver.h --- Akinobu Mita (1): driver core: delete virtual directory on class_unregister() Andrew Morton (1): Driver core: "platform_driver_probe() can save codespace": save codespace David Brownell (1): Driver core: deprecate PM_LEGACY, default it to N Hans J. Koch (4): UIO: Add the User IO core code UIO: Documentation UIO: dummy test module for the uio core UIO: irq test module for the uio core Kay Sievers (1): Driver core: show "initstate" of module Mathieu Desnoyers (5): DebugFS : inotify create/mkdir support DebugFS : coding style fixes DebugFS : file/directory creation error handling DebugFS : more file/directory creation error handling DebugFS : file/directory removal fix Scott Wood (1): Driver core: Make platform_device_add_data accept a const pointer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PATCH] more Driver core patches for 2.6.19
Here are some more driver core patches for 2.6.19 They contain: - minor driver core bugfixes and memory savings - debugfs bugfixes and inotify support added. - userspace io driver interface added. This allows the ability to write userspace drivers for some types of hardware much easier than before, going through a simple interface to get accesses to irqs and memory regions. A small kernel portion is still needed to handle the irq properly, but that is it. - other minor cleanups and fixes. All of these patches have been in the -mm tree for a while. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ or if master.kernel.org hasn't synced up yet: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ Patches will be sent as a follow-on to this message to lkml for people to see. thanks, greg k-h Documentation/DocBook/kernel-api.tmpl |4 + Documentation/DocBook/uio-howto.tmpl | 434 +++ drivers/Kconfig |1 + drivers/Makefile |1 + drivers/base/class.c |2 + drivers/base/platform.c |4 +- drivers/uio/Kconfig | 39 ++ drivers/uio/Makefile |4 + drivers/uio/uio.c | 618 + drivers/uio/uio_dummy.c | 174 + drivers/uio/uio_events.c | 119 +++ drivers/uio/uio_irq.c | 86 + drivers/uio/uio_parport.c | 84 + fs/debugfs/inode.c| 39 ++- include/linux/platform_device.h |2 +- include/linux/uio_driver.h| 71 kernel/module.c | 25 ++ kernel/power/Kconfig |9 +- 18 files changed, 1700 insertions(+), 16 deletions(-) create mode 100644 Documentation/DocBook/uio-howto.tmpl create mode 100644 drivers/uio/Kconfig create mode 100644 drivers/uio/Makefile create mode 100644 drivers/uio/uio.c create mode 100644 drivers/uio/uio_dummy.c create mode 100644 drivers/uio/uio_events.c create mode 100644 drivers/uio/uio_irq.c create mode 100644 drivers/uio/uio_parport.c create mode 100644 include/linux/uio_driver.h --- Akinobu Mita (1): driver core: delete virtual directory on class_unregister() Andrew Morton (1): Driver core: platform_driver_probe() can save codespace: save codespace David Brownell (1): Driver core: deprecate PM_LEGACY, default it to N Hans J. Koch (4): UIO: Add the User IO core code UIO: Documentation UIO: dummy test module for the uio core UIO: irq test module for the uio core Kay Sievers (1): Driver core: show initstate of module Mathieu Desnoyers (5): DebugFS : inotify create/mkdir support DebugFS : coding style fixes DebugFS : file/directory creation error handling DebugFS : more file/directory creation error handling DebugFS : file/directory removal fix Scott Wood (1): Driver core: Make platform_device_add_data accept a const pointer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 12:12:04PM -0800, Linus Torvalds wrote:
On Wed, 13 Dec 2006, Greg KH wrote:
- userspace io driver interface added. This allows the ability
to write userspace drivers for some types of hardware much
easier than before, going through a simple interface to get
accesses to irqs and memory regions. A small kernel portion
is still needed to handle the irq properly, but that is it.
Ok, what kind of ass-hat idiotic thing is this?
irqreturn_t uio_irq_handler(int irq, void *dev_id)
{
return IRQ_HANDLED;
}
exactly what is the point here? No way will I pull this kind of crap. You
just seem to have guaranteed a dead machine if the irq is level-triggered,
since it will keep on happening forever.
It's a stupid test module for the uio core for isa devices. It's not
the main code, or core.
Please remove.
YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!
I agree, that's why this code doesn't let userspace sort it out. You
have to have a kernel driver to handle the irq.
It's really that easy. The irq handler has to be _entirely_ in kernel
space. No user-space ass-hattery here.
Agreed.
And I don't care one whit if it happens to work on parport with an old
legacy ISA interrupt that is edge-triggered. That's not even the
interesting case. Never will be.
I agree. But that's all that this test module did. It handled an isa
interrupt that was edge triggered.
NAK NAK NAK NAK.
Ok, I can pull this example module out if you want, but people seem to
want examples these days. If I do that, any objection to the rest?
thanks,
greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On 12/13/06, Linus Torvalds [EMAIL PROTECTED] wrote: Ok, what kind of ass-hat idiotic thing is this? C'mon, Linus, tell us how you _really_ feel. Seriously, though, please please pretty please do not allow a facility for going through a simple interface to get accesses to irqs and memory regions into the mainline kernel, with or without toy ISA examples. Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a driver. The correct description is more like porting shim for MMU-less RTOS tasks; and if the BSP vendors of the world can make a nickel supplying them, more power to them. Just not in mainline, please. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006, Michael K. Edwards wrote: On 12/13/06, Linus Torvalds [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: Seriously, though, please please pretty please do not allow a facility for going through a simple interface to get accesses to irqs and memory regions into the mainline kernel, with or without toy ISA examples. Why? X does it today :) Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a driver. Yes, and because of this, they create binary only drivers today. Lots of them. All over the place. Doing crazy stupid crap in kernelspace. Then there are people who do irq stuff in userspace but get it wrong. I've seen that happen many times in lots of different research papers and presentations. This interface does it correctly, and it allows those people who for some reason feel they do want to keep their logic in non-gpl code, to do it. It also allows code that needs floating point to not be in the kernel and in one instance using this interface actually sped up the device because of the lack of the need to go between kernel and userspace a bunch of times. The correct description is more like porting shim for MMU-less RTOS tasks; and if the BSP vendors of the world can make a nickel supplying them, more power to them. Just not in mainline, please. Again, X does this today, and does does lots of other applications. This is a way to do it in a sane manner, to keep people who want to do floating point out of the kernel, and to make some embedded people much happier to use Linux, gets them from being so mad at Linux because we keep changing the internal apis, and makes me happier as they stop violating my copyright by creating closed drivers in the kernel. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006, Linus Torvalds wrote: Btw: there's one driver we _know_ we want to support in user space, and that's the X kind of direct-rendering thing. So if you can show that this driver infrastructure actually makes sense as a replacement for the DRI layer, then _that_ would be a hell of a convincing argument. Btw, the other side of this argument is that if a user-space driver infrastructure can _not_ help the DRI kind of situation, then it's largely by definition not interesting. Merging something like that would just mean that we end up with multiple _different_ user-space helper infrastructure shells, which sounds distinctly unpalatable. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
Ok, what kind of ass-hat idiotic thing is this?
irqreturn_t uio_irq_handler(int irq, void *dev_id)
{
return IRQ_HANDLED;
}
exactly what is the point here? No way will I pull this kind of crap. You
just seem to have guaranteed a dead machine if the irq is level-triggered,
since it will keep on happening forever.
Please remove.
YOU CANNOT DO IRQ'S BY LETTING USER SPACE SORT IT OUT!
Actually, you can... but wether you want is a different story :-)
You can simply mask it, have it handled by userspace and re-enable it
when that's done. Though say hello to horrible interrupt latencies and
hope you aren't sharing it with anything critical...
I don't mean I -like- the approach... I just say it can be made to
sort-of work. But I don't see the point.
Ben.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 2006-12-13 at 13:08 -0800, Linus Torvalds wrote: On Wed, 13 Dec 2006, Linus Torvalds wrote: Btw: there's one driver we _know_ we want to support in user space, and that's the X kind of direct-rendering thing. So if you can show that this driver infrastructure actually makes sense as a replacement for the DRI layer, then _that_ would be a hell of a convincing argument. Btw, the other side of this argument is that if a user-space driver infrastructure can _not_ help the DRI kind of situation, then it's largely with DRI you have the case where something needs to do security validation of the commands that are sent to the card. (to avoid a non-privileged user to DMA all over your memory) That and a tiny bit of resource management is the bulk of the kernel DRM code... and I don't think userspace can do it fundamentally better. Sure you could pipe things to a root daemon instead of doing a system call. But I don't see that being superior. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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'
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 2006-12-13 at 12:58 -0800, Linus Torvalds wrote:
In other words, I'd like to see code that uses this that is actually
_better_ than an in-kernel driver in some way.
For USB, the user-mode thing made sense. You have tons of random devices,
and the abstraction level is higher to begin with. Quite frankly, I simply
don't even see the same being true for something like this.
We started to work on this for industrial I/O devices. Many of them are
dual port memory based, others are dedicated chips for motion control or
field busses.
The design requires to have an in kernel stub driver with interrupt
handler which is capable to handle shared interrupts. User space
_cannot_ override an irq_disable(), it just has access to the chip
registers of the device, which is possible right now as well.
The risk, that such a driver stalls the kernel is exactly the same as
the risk you have with any other badly written driver.
This is a real world example of such a drivers interrupt handler:
/*
* The chip specific portion of the interrupt handler. The framework code
* takes care of userspace notification when we return IRQ_HANDLED
*/
static irqreturn_t sercos_handler(int irq, void *dev_id, struct pt_regs *reg)
{
/* Check, if this interrupt is originated from the SERCOS chip */
if (!(sercos_read(IRQ_STATUS) SERCOS_INTERRUPT_MASK))
return IRQ_NONE;
/* Acknowledge the chip interrupts */
sercos_write(IRQ_ACK1, SERCOS_INTERRUPT_ACK1);
sercos_write(IRQ_ACK2, SERCOS_INTERRUPT_ACK2);
return IRQ_HANDLED;
}
With a full kernel driver we need:
1. Interrupt handler
check interrupt
acknowledge interrupt
copy data from/to chip into a kernel buffer
wakeup user space task
2. read data from driver, which goes through copy to user
3. do calculations
4. write data to driver, which goes through copy from user
After changing the driver concept we have only:
1. Interrupt handler
check interrupt
acknowledge interrupt
wakeup user space task
2. User space task handles the mmaped chip directly
The change gave a serious performance gain in the range of 20% after the
application was optimized for dealing with the chip directly.
There are tons of such exotic hardware devices out there, which now have
either a closed source driver or an out of tree patch with an horrible
amount of individual ioctl functions to get to the same point with less
performance.
Btw: there's one driver we _know_ we want to support in user space, and
that's the X kind of direct-rendering thing. So if you can show that this
driver infrastructure actually makes sense as a replacement for the DRI
layer, then _that_ would be a hell of a convincing argument.
I did not look closely into that, but I think that it is a valid usage
candidate. The interface of graphic cards is user space mappable and it
probably needs some interrupt handling + notification mechanism as well
as the devices mentioned above.
tglx
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh [EMAIL PROTECTED] 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) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
Btw: there's one driver we _know_ we want to support in user space, and that's the X kind of direct-rendering thing. So if you can show that this driver infrastructure actually makes sense as a replacement for the DRI layer, then _that_ would be a hell of a convincing argument. And even X is trying to move away from that at least partially... With the DRI driver handling IRQs and processing command buffers... except for cards with multiple hardware contexts, but then, we are in a case similar to Infiniband where the HW is -designed- to have specific areas mapped into user space, and there is still a kernel driver to arbitrate, decide who gets what, establish those mappings, etc... Thus X isn't even a good example :-) Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On 12/13/06, Greg KH [EMAIL PROTECTED] wrote: On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: Seriously, though, please please pretty please do not allow a facility for going through a simple interface to get accesses to irqs and memory regions into the mainline kernel, with or without toy ISA examples. Why? X does it today :) Er, I rest my case? Anyway, the history around X11 is completely different from the present situation, and there were good arguments at the time for structuring the problem so that the X server was relatively kernel-neutral even if it was banging directly on a framebuffer, and later on 2-D acceleration hardware. As graphics chips have become more sophisticated, pure-userspace X11 has become less tenable. Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a driver. Yes, and because of this, they create binary only drivers today. Lots of them. All over the place. Doing crazy stupid crap in kernelspace. It does not get less crazy and stupid because we open a big hole from kernelspace to userspace and let them pretend that they have a GPL driver when all of the chip init logic is peeked and poked from the same closed code in userspace. Most low-level drivers (the kind that involve IRQs and registers local to the CPU; USB is different) cannot be done right from userspace and we shouldn't encourage people to try. Then there are people who do irq stuff in userspace but get it wrong. I've seen that happen many times in lots of different research papers and presentations. Their problems need not become our problems. This interface does it correctly, and it allows those people who for some reason feel they do want to keep their logic in non-gpl code, to do it. People who want to keep their logic in non-GPL code do so by providing binary-only drivers. That's a sane compromise in certain sectors, and occasionally results in the eventual opening of the driver (when the illusion of competitive advantage in closed-ness wears off) in integrable shape. A customer with some leverage and technical skill can negotiate for access to the source code so that he can fix the bugs that are biting him, rebuild with a toolchain that isn't from the Dark Ages, and so forth: a real-life demonstration to the vendor that letting outsiders work on the code will sell more chips. But if you actively encourage a brain-damaged userspace driver strategy, that opportunity is lost. It also allows code that needs floating point to not be in the kernel and in one instance using this interface actually sped up the device because of the lack of the need to go between kernel and userspace a bunch of times. What instance is that? Are you sure it wasn't a case of things being done in the driver that should have been done in a library all along? The correct description is more like porting shim for MMU-less RTOS tasks; and if the BSP vendors of the world can make a nickel supplying them, more power to them. Just not in mainline, please. Again, X does this today, and does does lots of other applications. This is a way to do it in a sane manner, to keep people who want to do floating point out of the kernel, and to make some embedded people much happier to use Linux, gets them from being so mad at Linux because we keep changing the internal apis, and makes me happier as they stop violating my copyright by creating closed drivers in the kernel. Today's problem is that too many chip suppliers' in-house software people have neither the skills nor the schedule room nor the influence to insist that drivers be written competently and maintainably, whether or not they are maintained in the public view. So chipmakers turn to the BSP vendors, whose business model is built around being the only people who can do incremental development on the code they write. I'm not at all hostile to BSP vendors or to chipmakers who wind up in this position; that's the way most of the industry works nowadays. But I do want to know when I'm dealing with that situation, because the appropriate strategies for getting a product to market are different when it costs the chip vendor real cash money each time they commission a recompile to meet some customer's expectations. Pretending that driver code doesn't need reviewing every few months as the kernel's locking strategies, timer handling, internal APIs, etc. evolve makes things worse. Just like the only thing worse that a salesperson who's on commission is a salesperson who isn't on commission, the only thing worse than a closed device driver in kernelspace is a closed device driver in userspace. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
Greg KH wrote: On Wed, Dec 13, 2006 at 12:38:05PM -0800, Michael K. Edwards wrote: Seriously, though, please please pretty please do not allow a facility for going through a simple interface to get accesses to irqs and memory regions into the mainline kernel, with or without toy ISA examples. Why? X does it today :) Umm ... and you're trying to use the current X model for a positive example of what we should be doing? that's ... interesting. Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a driver. Yes, and because of this, they create binary only drivers today. Lots of them. All over the place. Doing crazy stupid crap in kernelspace. So let's come out and ban binary modules, rather than pussyfooting around, if that's what we actually want to do. It comes down to a question of whether we have enough leverage to push them into doing what we want, or not - are we prepared to call their bluff? The current half-assed solution of chipping slowly away at things by making them EXPORT_SYMBOL_GPL one by one makes little sense - would be better if we actually made an affirmative decision one way or the other. And yes, I know which side of that argument you'd fall on ;-) Again, X does this today, and does does lots of other applications. This is a way to do it in a sane manner, to keep people who want to do floating point out of the kernel, and to make some embedded people much happier to use Linux, gets them from being so mad at Linux because we keep changing the internal apis, and makes me happier as they stop violating my copyright by creating closed drivers in the kernel. I don't see how this really any different than letting them create GPL shims to export data to binary modules (aside from all the legal wanking over minutae details, which really isn't that interesting). M. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote: On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On 12/13/06, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: the edge flow is easy. the level one is: - IRQ happens - kernel handler masks it and queue a msg for userland - later on, userland gets the message, talks to the device, (MMAP'ed mmio, acks the interrupt on the device itself) and does an ioctl/syscall/write/whatever to tell kernel it's done - kernel unmasks it. That's simply not true. - IRQ happens - kernel handler runs and masks the chip irq, which removes the IRQ request - user space message get queued or waiting reader woken - kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC - user space handles the device - user space reenables the device irq No need for an ioctl. Neither for edge nor for level irqs. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: Oh, it works well enough for non shared iqs if you are really anal about It works well for shared irqs. Thats the whole reason why you need an in kernel part. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 2006-12-13 at 23:30 +0100, Thomas Gleixner wrote: On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: the edge flow is easy. the level one is: - IRQ happens - kernel handler masks it and queue a msg for userland - later on, userland gets the message, talks to the device, (MMAP'ed mmio, acks the interrupt on the device itself) and does an ioctl/syscall/write/whatever to tell kernel it's done - kernel unmasks it. That's simply not true. - IRQ happens - kernel handler runs and masks the chip irq, which removes the IRQ request - user space message get queued or waiting reader woken - kernel handler returns IRQ_HANDLED, which reenables the irq in the PIC - user space handles the device - user space reenables the device irq No need for an ioctl. Neither for edge nor for level irqs. Wait wait wait... your scenario implies that the kernel has knowledge of the chip to mask the irq in the chip in the first place. If that is the case, then you have a chip specific kernel driver, yadada, the whole story is moot :-) We were talking about the idea of having some generic reflector of irqs to userspace without device specific knowledge. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote: On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: Oh, it works well enough for non shared iqs if you are really anal about It works well for shared irqs. Thats the whole reason why you need an in kernel part. As soon as you have an in-kernel part that is chip specific, yes, of course it works, because essentially, what you have done is a kernel driver for your chip and the whole discussion is moot :-) And I agree, that's the right thing to do btw. Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Dec 13, 2006, at 17:20:35, Michael K. Edwards wrote: On 12/13/06, Andrew Morton [EMAIL PROTECTED] wrote: On Wed, 13 Dec 2006 13:32:50 -0800 Martin Bligh [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 09:39 +1100, Benjamin Herrenschmidt wrote: No need for an ioctl. Neither for edge nor for level irqs. Wait wait wait... your scenario implies that the kernel has knowledge of the chip to mask the irq in the chip in the first place. If that is the case, then you have a chip specific kernel driver, yadada, the whole story is moot :-) We were talking about the idea of having some generic reflector of irqs to userspace without device specific knowledge. Which simply is not possible, especially for shared irqs. Can you please elaborate why this effort is moot, instead of throwing the usual flamewar arguments around ? The concept of UIO divides the problem in two spaces: - kernel interface, which controls interrupts and mapping - user space restricted interface I don't see why the necessarity of a kernel stub driver is a killer argument. The chip internals, which companies might want to protect are certainly not in the interrupt registers. Aside of that there are huge performance gains for certain application / driver scenarios and I really don't see an advantage that people are doing excactly the same thing in out of tree hackeries with a lot of inconsistent user land interfaces. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Thu, 2006-12-14 at 09:45 +1100, Benjamin Herrenschmidt wrote: On Wed, 2006-12-13 at 23:40 +0100, Thomas Gleixner wrote: On Thu, 2006-12-14 at 09:14 +1100, Benjamin Herrenschmidt wrote: Oh, it works well enough for non shared iqs if you are really anal about It works well for shared irqs. Thats the whole reason why you need an in kernel part. As soon as you have an in-kernel part that is chip specific, yes, of course it works, because essentially, what you have done is a kernel driver for your chip and the whole discussion is moot :-) And I agree, that's the right thing to do btw. Still the framework has a benefit, as it removes the bunch of incompatible out of tree attempts to achieve the same result. tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On 12/13/06, Thomas Gleixner [EMAIL PROTECTED] wrote: Aside of that there are huge performance gains for certain application / driver scenarios and I really don't see an advantage that people are doing excactly the same thing in out of tree hackeries with a lot of inconsistent user land interfaces. Greg's effort is noble but I think it is targeted at the wrong problem and would actually make things worse. Inconsistent interfaces from one driver to another are the surface design flaw that obscures the fundamental design flaw of exposing hardware to userland: abdication of the driver writer's responsibility to choose and justify which things belong in the driver and which belong in a hardware-agnostic driver framework or a userspace library instead. When you are talking about unique, one-off hardware, it doesn't really matter whether the shim for a closed, out-of-tree, userspace driver fits into a framework or not. Who cares whether they use the preferred MMIO reservation paths or just throw ioctl(POKE_ME_HARDER) or mmap(/dev/mem) at the problem? But I don't want to see ALSA or iwconfig or i2c-core or any of the other competently designed and implemented driver frameworks mangled into unusability by attempts to facilitate this design pattern. Truth in advertising is an advantage even if it doesn't change the underlying reality. I can (and do) tell chip vendors, that's not a driver, that's a shim for some other customer's pre-existing eCos task, and justify the cost of writing an actual driver to the client. I may or may not succeed in arguing that the new driver should be designed to an existing API when that means rethinking the userspace app, or that it should be implemented against a current kernel and offered promptly up to the appropriate Linus lieutenant. But at least the project isn't crippled by confusion about whether or not the existing blob constitutes a driver. Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 12:58:24PM -0800, Linus Torvalds wrote: I'm really not convinced about the user-mode thing unless somebody can show me a good reason for it. Not just some wouldn't it be nice kind of thing. A real, honest-to-goodness reason that we actually _want_ to see used. No features just for features sake. Ok, Thomas just showed at least one example of where this interface is a big advantage over the all-in-kernel model. I'll work with him and try to dig up other real examples before submitting this code again. In the mean time, I'll leave it in my tree and it will get some more exposure in the -mm releases. So please push the tree without this userspace IO driver at all. Done. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ It contains the changes listed below. thanks, greg k-h drivers/base/class.c|2 ++ drivers/base/platform.c |4 ++-- fs/debugfs/inode.c | 39 ++- include/linux/platform_device.h |2 +- kernel/module.c | 25 + kernel/power/Kconfig|9 + 6 files changed, 65 insertions(+), 16 deletions(-) --- Akinobu Mita (1): driver core: delete virtual directory on class_unregister() Andrew Morton (1): Driver core: platform_driver_probe() can save codespace: save codespace David Brownell (1): Driver core: deprecate PM_LEGACY, default it to N Kay Sievers (1): Driver core: show initstate of module Mathieu Desnoyers (5): DebugFS : inotify create/mkdir support DebugFS : coding style fixes DebugFS : file/directory creation error handling DebugFS : more file/directory creation error handling DebugFS : file/directory removal fix Scott Wood (1): Driver core: Make platform_device_add_data accept a const pointer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
I don't see why the necessarity of a kernel stub driver is a killer argument. The chip internals, which companies might want to protect are certainly not in the interrupt registers. So they can go off and write themselves a driver. Without putting junk in the kernel just in case, and if the driver and the user space code using it are closely interdependant I'd suggest they look up the *legal* definition of derivative work. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, 13 Dec 2006 23:30:55 +0100 Thomas Gleixner [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
IIRC, Linus has deliberately and explicitly estopped himself from claiming that loading a binary-only driver is a GPL violation. Do you He only owns a small amount of the code. Furthermore he imported third party GPL code using the license as sole permission. So he may have dug a personal hole but many of the rest of us have been repeatedly saying whenever he said that - that we do not agree. The FSF has always said binary modules are wrong and there is FSF code imported into the kernel by Linus on license only grounds. Whether it is a good idea is a different question. Alan. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 11:56:01PM +, Alan wrote: On Wed, 13 Dec 2006 23:30:55 +0100 Thomas Gleixner [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wed, Dec 13, 2006 at 02:09:11PM -0800, Greg KH wrote:
On Wed, Dec 13, 2006 at 01:47:21PM -0800, Andrew Morton wrote:
On Wed, 13 Dec 2006 13:32:50 -0800
Martin Bligh [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
---
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 [EMAIL PROTECTED]
---
+
+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 [EMAIL PROTECTED] or [EMAIL PROTECTED]
+
+---
--- 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);
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wed, Dec 13, 2006 at 05:43:29PM -0700, Jonathan Corbet wrote:
Greg's patch:
+ printk(KERN_WARNING %s: This module will not be able
+ to be loaded after January 1, 2008 due to its
+ license.\n, mod-name);
If you're going to go ahead with this, shouldn't the message say that
the module will not be loadable into *kernels released* after January 1,
2008? I bet a lot of people would read the above to say that their
system will just drop dead of a New Year's hangover, and they'll freak.
I wouldn't want to be the one getting all the email at that point...
Heh, good point.
An updated version is below.
Oh, and for those who have asked me how we would enforce this after this
date if this decision is made, I'd like to go on record that I will be
glad to take whatever legal means necessary to stop people from
violating this.
Someone also mentioned that we could just put a nice poem into the
kernel module image in order to be able to enforce our copyright license
in any court of law.
Full bellies of fish
Penguins sleep under the moon
Dream of wings that fly
thanks,
greg k-h
--
From: Greg Kroah-Hartmna [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
---
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 [EMAIL PROTECTED]
---
+
+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 [EMAIL PROTECTED] [EMAIL PROTECTED]
+
+---
--- gregkh-2.6.orig/kernel/module.c
+++ gregkh-2.6/kernel/module.c
@@ -1393,9 +1393,14 @@ static void set_license(struct module *m
license = unspecified;
if (!license_is_gpl_compatible(license)) {
- if (!(tainted TAINT_PROPRIETARY_MODULE))
+ if (!(tainted TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING %s: module license '%s' taints
kernel.\n, mod-name, license);
+ printk(KERN_WARNING %s: This module will not be able
+ to be loaded in any kernel released after
+ January 1, 2008 due to its license.\n,
+ mod-name);
+ }
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
}
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
fish for birds alone? no, teach suits how to leave more fish to go around Cheers, - Michael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Greg's patch: + printk(KERN_WARNING %s: This module will not be able + to be loaded after January 1, 2008 due to its + license.\n, mod-name); If you're going to go ahead with this, shouldn't the message say that the module will not be loadable into *kernels released* after January 1, 2008? I bet a lot of people would read the above to say that their system will just drop dead of a New Year's hangover, and they'll freak. I wouldn't want to be the one getting all the email at that point... jon - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Thu, Dec 14, 2006 at 02:30:26AM +0100, Grzegorz Kulewski wrote: Hi, I think that... On Wed, 13 Dec 2006, Greg KH wrote: From: Greg Kroah-Hartmna [EMAIL PROTECTED] ... (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 [EMAIL PROTECTED] ... or (less probably) there... is a typo in your name. :-) Heh, thanks. I've also fixed up the wording in the feature-removal-schedule.txt file to say: What: non-GPL-licensed modules will no longer be loaded. The wording I had before was not very easy to understand. PS. Are you _really_ sure you want this change accepted into mainline kernel? Yes, I do. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi, I think that... On Wed, 13 Dec 2006, Greg KH wrote: From: Greg Kroah-Hartmna [EMAIL PROTECTED] ... (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 [EMAIL PROTECTED] ... 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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] more Driver core patches for 2.6.19
On Wed, Dec 13, 2006 at 11:55:00PM +, Alan wrote: IIRC, Linus has deliberately and explicitly estopped himself from claiming that loading a binary-only driver is a GPL violation. Do you He only owns a small amount of the code. Furthermore he imported third party GPL code using the license as sole permission. So he may have dug a personal hole but many of the rest of us have been repeatedly saying whenever he said that - that we do not agree. The FSF has always said binary modules are wrong and there is FSF code imported into the kernel by Linus on license only grounds. Whether it is a good idea is a different question. Wait a bloody minute - the only FSF code in the kernel I know of is from libgcc, which does allow linking to non-GPL code. Is there anything else? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid shell game drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of derived work. It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I happen to believe that there shouldn't be technical measures that keep me from watching my DVD or listening to my music on whatever device I damn well please. Fair use, man. But it should go the other way too: we should not try to assert _our_ copyright rules on other peoples code that wasn't derived from ours, or assert _our_ technical measures that keep people from combining things their way. If people take our code, they'd better behave according to our rules. But we shouldn't have to behave according to the RIAA rules just because we _listen_ to their music. Similarly, nobody should be forced to behave according to our rules just because they _use_ our system. There's a big difference between copy and use. It's exatcly the same issue whether it's music or code. You can't re-distribute other peoples music (becuase it's _their_ copyright), but they shouldn't put limits on how you personally _use_ it (because it's _your_ life). Same goes for code. Copyright is about _distribution_, not about use. We shouldn't limit how people use the code. Oh, well. I realize nobody is likely going to listen to me, and everybody has their opinion set in stone. That said, I'm going to suggest that you people talk to your COMPANY LAWYERS on this, and I'm personally not going to merge that particular code unless you can convince the people you work for to merge it first. In other words, you guys know my stance. I'll not fight the combined opinion of other kernel developers, but I sure as hell won't be the first to merge this, and I sure as hell won't have _my_ tree be the one that causes this to happen. So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees first. This is not something where we use my tree as a way to get it to other trees. This is something where the push had better come from the other direction. Because I think it's stupid. So use somebody else than me to push your political agendas, please. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Greg KH ([EMAIL PROTECTED]) said: An updated version is below. If you're adding this, you should probably schedule EXPORT_SYMBOL_GPL for removal at the same time, as this essentially renders that irrelevant. That being said... First, this is adding the measure at module load time. Any copyright infringment happens on distribution; module load isn't (necessarily) that; if I write random code and load it, without ever sending it to anyone, I'm not violating the license, and this would prevent that. So it seems somewhat misplaced. Secondly... Oh, and for those who have asked me how we would enforce this after this date if this decision is made, I'd like to go on record that I will be glad to take whatever legal means necessary to stop people from violating this. There's nothing stopping you undertaking these means now. Addition of this measure doesn't change the copyright status of any code - what was a violation before would still be a violation. Copyright's not something like trademark, where it's sue-or-lose - there's no requirement for constant action, and there's no requirement for enforcement measures. If I reproduce and start selling copies of the White album, it doesn't matter that there wasn't a mechanism on the CD that prevented me doing that - it's still a copyright violation. Hence, the only purpose of a clause like this legally would seem to be to *intentionally* go after people using the DMCA. Which seems... tacky. Of course, I don't have significant code of note in the kernel, so I can't really prevent you from doing this if you want... Bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid shell game drivers that don't actually help anything at all, and move code into user space instead. I don't think pushing the drivers into userspace is a good idea at all, that wasn't what I was getting at. Pushing the problem into a different space doesn't fix it. IMHO, we're not a microkernel, and drivers for hardware belong in the kernel. Whether we allow binary kernel modules or not, I don't think we should allow an API for userspace drivers - obviously that's not my call, it's yours, but at least I don't want my opinion / intent misinterpreted. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? The point of banning binary drivers would be to leverage hardware companies into either releasing open source drivers, or the specs for someone else to write them. Whether we have that much leverage is debatable ... I suspect we do in some cases and not in others. It'll cause some pain, as well as some gain, but I think we'd live through it pretty well, personally. The details of the legal minutiae are, I feel, less interesting than what goal we want to acheive. If we decided to get rid of binary drivers, we could likely find a way to achieve that. Is it a worthwhile goal? I've done both Linux support, where binary drivers are involved, before, as well as supporting Sequent's Dynix/PTX in the face of a similar situation with CA Unicenter. It makes life extremely difficult, if not impossible for a support organisation, for fairly obvious and well known reasons. When there are two binary drivers from different vendors in there, any semblence of support becomes farcical. The Ubuntu feisty fawn mess was a dangerous warning bell of where we're going. If we don't stand up at some point, and ban binary drivers, we will, I fear, end up with an unsustainable ecosystem for Linux when binary drivers become pervasive. I don't want to see Linux destroyed like that. I don't think the motive behind what we decide to do should be decided by legal stuff, though I'm sure we'd have to wade through that to implement it. It's not about that ... it's about what kind of ecosystem we want to create, and whether that can be successful or not. Indeed, there are good arguments both for and against binary drivers on that basis. But please can we have the pragmatic argument about what we want to achieve, and why ... rather than the legal / religious arguments about licenses? The law is a tool, not an end in itself. If you don't feel it's legitimate to leverage that tool to achieve a pragmatic end, fair enough. But please don't assume that the motivation was legal / religious, at least not on my part. Perhaps, in the end, we will decide we'd like to ban binary drivers, but can't. Either for pragmatic reasons (e.g. we don't have enough leverage to create the hardware support base), or for legal ones (we don't think it's enforcable). But we seem to be muddled between those different reasons right now, at least it seems that way to me. I think allowing binary hardware drivers in userspace hurts our ability to leverage companies to release hardware specs. The 'grey water' of binary kernel drivers convinces a lot of them to release stuff, and Greg and others have pushed that cause, all credit to them. In one way, it does make the kernel easier to support, but I don't think it really helps much to make a supportable *system*. M. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Hi. Good arguments have already been put against it, so I'll just keep it short and sweet (FWIW) Nacked-by: Nigel Cunningham [EMAIL PROTECTED] Regards, Nigel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
Well said, and I agree with ALL of your statements contained in this post. About damn time this was addressed. Jeff Linus Torvalds wrote: On Wed, 13 Dec 2006, Greg KH wrote: Numerous kernel developers feel that loading non-GPL drivers into the kernel violates the license of the kernel and their copyright. Because of this, a one year notice for everyone to address any non-GPL compatible modules has been set. Btw, I really think this is shortsighted. It will only result in _exactly_ the crap we were just trying to avoid, namely stupid shell game drivers that don't actually help anything at all, and move code into user space instead. What was the point again? Was the point to alienate people by showing how we're less about the technology than about licenses? Was the point to show that we think we can extend our reach past derived work boundaries by just saying so? The silly thing is, the people who tend to push most for this are the exact SAME people who say that the RIAA etc should not be able to tell people what to do with the music copyrights that they own, and that the DMCA is bad because it puts technical limits over the rights expressly granted by copyright law. Doesn't anybody else see that as being hypocritical? So it's ok when we do it, but bad when other people do it? Somehow I'm not surprised, but I still think it's sad how you guys are showing a marked two-facedness about this. The fact is, the reason I don't think we should force the issue is very simple: copyright law is simply _better_off_ when you honor the admittedly gray issue of derived work. It's gray. It's not black-and-white. But being gray is _good_. Putting artificial black-and-white technical counter-measures is actually bad. It's bad when the RIAA does it, it's bad when anybody else does it. If a module arguably isn't a derived work, we simply shouldn't try to say that its authors have to conform to our worldview. We should make decisions on TECHNICAL MERIT. And this one is clearly being pushed on anything but. I happen to believe that there shouldn't be technical measures that keep me from watching my DVD or listening to my music on whatever device I damn well please. Fair use, man. But it should go the other way too: we should not try to assert _our_ copyright rules on other peoples code that wasn't derived from ours, or assert _our_ technical measures that keep people from combining things their way. If people take our code, they'd better behave according to our rules. But we shouldn't have to behave according to the RIAA rules just because we _listen_ to their music. Similarly, nobody should be forced to behave according to our rules just because they _use_ our system. There's a big difference between copy and use. It's exatcly the same issue whether it's music or code. You can't re-distribute other peoples music (becuase it's _their_ copyright), but they shouldn't put limits on how you personally _use_ it (because it's _your_ life). Same goes for code. Copyright is about _distribution_, not about use. We shouldn't limit how people use the code. Oh, well. I realize nobody is likely going to listen to me, and everybody has their opinion set in stone. That said, I'm going to suggest that you people talk to your COMPANY LAWYERS on this, and I'm personally not going to merge that particular code unless you can convince the people you work for to merge it first. In other words, you guys know my stance. I'll not fight the combined opinion of other kernel developers, but I sure as hell won't be the first to merge this, and I sure as hell won't have _my_ tree be the one that causes this to happen. So go get it merged in the Ubuntu, (Open)SuSE and RHEL and Fedora trees first. This is not something where we use my tree as a way to get it to other trees. This is something where the push had better come from the other direction. Because I think it's stupid. So use somebody else than me to push your political agendas, please. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
