Chris Wedgwood wrote:
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
Think of uio as just a class of driver, like input or v4l. It's still
up to the driver writer to provide a proper bus interface to the
hardware (pci, usb, etc.) in order for the device to work at all.
Understood. That leads me to ask another question of the folks who deal
with a lot of these
On Dec 14 2006 09:52, Chris Wedgwood wrote:
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty
On Thu, 2006-12-14 at 10:56 +0100, Hans-Jürgen Koch wrote:
[]
A small German manufacturer produces high-end AD converter cards. He sells
100 pieces per year, only in Germany and only with Windows drivers. He would
now like to make his cards work with Linux. He has two driver programmers
Martin J. Bligh wrote:
Jeff V. Merkey wrote:
Again, I agree with EVERY statement Linus made here. We operate
exactly as Linus describes, and
legally, NO ONE can take us to task on GPL issues. We post patches of
affected kernel code
(albiet the code resembles what Linus describes as a
On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
No. That's really a purely technical thing.
You can still do whatever you want, but people who support the resulting
mess know that they shouldn't.
Linus
-
To
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
Please don't use that name, it strikes me as much more confusing
than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
convey what it means, either.
Calling internal symbols _INTERNAL is confusing?
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Jeff V. Merkey wrote:
Yeah, like that one. WITH THE POLITICAL AGENDA CODE REMOVED.
No. That's really a purely technical thing.
I'm not certain I understand what you mean here. Nasty messages using
the word taint is purely subjective.
On Thu, 14 Dec 2006, Chris Wedgwood wrote:
Calling internal symbols _INTERNAL is confusing?
Well, I'm not sure the _INTERNAL name is all that much better than the
_GPL one.
In many ways, the _GPL one describes the _effects_ better, and also points
out the reason _why_ something is marked
On Thu, Dec 14, 2006 at 01:45:16PM +0100, Hans-Jürgen Koch wrote:
What you suggest is not a small kernel module. It's what we have now,
writing a complete driver.
Who says a complete driver has to be big?
That's what UIO does, plus some standard sysfs files, that tell you e.g.
the size of
Rik van Riel ([EMAIL PROTECTED]) said:
Maybe we should just educate users and teach them to
avoid crazy unsupportable configurations and simply buy
the hardware that has open drivers available?
Educating the users may help, but it's hard to do the
education once they've already bought the
On 12/14/06, Chris Wedgwood [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
Please don't use that name, it strikes me as much more confusing
than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
convey what it means, either.
Calling
This whole effort is pointless. This is the same kind of crap MICROSOFT
DOES to create incompatibilities
DELIBERATELY. The code is either FREE or its NOT FREE.If the code
is FREE then let it be. You can put whatever
you want in the code -- I will remove any such constructs, just like I
On Thu, Dec 14, 2006 at 12:17:49PM -0500, Theodore Tso wrote:
On Thu, Dec 14, 2006 at 04:33:47PM +, Alan wrote:
The trick is to let a lawyer send cease and desist letters to people
distributing the infringing software for 1 Euro at Ebay.
Doesn't that sound even more like the music
Wedgwood
Cc: Eric Sandeen; Christoph Hellwig; Linus Torvalds; Jeff
Garzik; Greg KH; Jonathan Corbet; Andrew Morton; Martin
Bligh; Michael K. Edwards; linux-kernel@vger.kernel.org
Subject: Re: GPL only modules [was Re: [GIT PATCH] more
Driver core patches for 2.6.19]
On 12/14/06, Chris
And there's also the common misconception all costumers had enough
information when buying something. If you are a normal Linux user and
buy some hardware labelled runs under Linux, it could turn out that's
with a Windows driver running under ndiswrapper...
That is something that I think is
On Thursday 14 December 2006 15:12, Ben Collins wrote:
You can't talk about drivers that don't exist for Linux. Things like
bcm43xx aren't effected by this new restriction for GPL-only drivers.
There's no binary-only driver for it (ndiswrapper doesn't count). If the
hardware vendor doesn't
On Thu, 2006-12-14 at 20:29 +0100, Michael Buesch wrote:
On Thursday 14 December 2006 15:12, Ben Collins wrote:
You can't talk about drivers that don't exist for Linux. Things like
bcm43xx aren't effected by this new restriction for GPL-only drivers.
There's no binary-only driver for it
On Thu, 2006-12-14 at 09:26 -0800, Linus Torvalds wrote:
On Thu, 14 Dec 2006, Jan Engelhardt wrote:
I don't get you. The rtc module does something similar (RTC generates
interrupts and notifies userspace about it)
The RTC module knows how to shut the interrupt up.
The kernel part of
On Thu, Dec 14, 2006 at 06:26:26PM +, Alan wrote:
Think of uio as just a class of driver, like input or v4l. It's still
up to the driver writer to provide a proper bus interface to the
hardware (pci, usb, etc.) in order for the device to work at all.
Understood. That leads me to ask
On 12/15/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Alan wrote:
Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example.
ACK++ We should definitely push Nouveau[1] as hard as we can.
On Thursday 14 December 2006 23:21, Dave Airlie wrote:
On 12/15/06, Jeff Garzik [EMAIL PROTECTED] wrote:
Alan wrote:
Another thing we should do more is aggressively merge prototype open
drivers for binary only hardware - lets get Nouveau's DRM bits into the
kernel ASAP for example.
It'll get in when the developers feel it is at a stage where it can be
supported, at the moment (I'm not speaking for all the nouveau team
only my own opinion) the API isn't stable and putting it into the
kernel only means we've declared the API supportable, I know in theory
marking it
On Thursday 14 December 2006 23:39, Dave Airlie wrote:
It'll get in when the developers feel it is at a stage where it can be
supported, at the moment (I'm not speaking for all the nouveau team
only my own opinion) the API isn't stable and putting it into the
kernel only means we've
On Thu, 14 Dec 2006, Thomas Gleixner wrote:
The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?
Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this thread has been.
The point
Linus Torvalds wrote:
On Thu, 14 Dec 2006, Thomas Gleixner wrote:
The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?
Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this
Linus,
On Thu, 2006-12-14 at 14:59 -0800, Linus Torvalds wrote:
The kernel part of the UIO driver also knows how to shut the interrupt
up, so where is the difference ?
Thomas, you've been discussing some totally different and private
Thomas-only thread than everybody else in this thread
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
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
> 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
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
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
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
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
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 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
>
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
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
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
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",
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,
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
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
> 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
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.
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, 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
>
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
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
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
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
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,
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 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
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
> 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
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
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 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
> 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
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,
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 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
>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 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
> 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
501 - 600 of 629 matches
Mail list logo
