> 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
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_
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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,
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
401 - 457 of 457 matches
Mail list logo
