From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 20:12:36 UTC
Message-ID: <fa.1eGQy/81clvI4ZLh/+eI+lG90B0@ifi.uio.no>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 20:58:59 UTC
Message-ID: <fa.iiXiMXy6gocqbD4u1U2p0eOm5cM@ifi.uio.no>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 21:08:39 UTC
Message-ID: <fa.4M1hiVye7jjJm9Cr/FCy/wNKIFU@ifi.uio.no>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 21:03:56 UTC
Message-ID: <fa.9oif/cung1sqPsVodijASR5qEFE@ifi.uio.no>

On Wed, 13 Dec 2006, Michael K. Edwards wrote:
>
> On 12/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > Ok, what kind of ass-hat idiotic thing is this?
>
> C'mon, Linus, tell us how you _really_ feel.

I'll try to be less subtle next time ;)

> Seriously, though, please please pretty please do not allow a facility
> for "going through a simple interface to get accesses to irqs and
> memory regions" into the mainline kernel, with or without toy ISA
> examples.

I do agree.

I'm not violently opposed to something like this in practice (we've
already allowed it for USB devices), but there definitely needs to be a
real reason that helps _us_, not just some ass-hat vendor that looks for a
way to avoid open-sourcing their driver.

If there are real and valid uses (and as mentioned, I actually think that
the whole graphics-3D-engine-thing is such a use) where a kernel driver
simply doesn't work out well, or where there are serious technical 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 dead, 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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 23:29:23 UTC
Message-ID: <fa.d7l2tjhYwtexm1uHvFlnvbOJ5iQ@ifi.uio.no>

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

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Thu, 14 Dec 2006 17:33:15 UTC
Message-ID: <fa.xiAA5joJV7ChkSBaW15ceBql3Hg@ifi.uio.no>

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>
> Rather than IRQ_HANDLED, it should have been: remove this irq handler
> from the irq handlers for irq number N, so that it does not get called
> again until userspace has acked it.

Wrongo.

That just means that the _handler_ won't be called.

But the irq still stays active, and if it's shared, ALL THE OTHER HANDLERS
FOR THAT INTERRUPT will be called.

Over and over again. Forever. Because the machine won't be making any
progress, and the user-level code (which might know how to shut it up)
won't ever be called, because the machine is busy just doing interrupt
delivery all the time.

> See, maybe I don't have enough clue yet to exactly figure out why you
> say it does not work. However, this is how simple people see it 8)

You may be a bit simple. But I think it's more polite to call you
"special". Or maybe just not very used to how hardware works.

Btw, this is not something theoretical. We used to have this particular
problem _all_ the time with PCMCIA back when we weren't as good at
interrupt routing. You'd insert a PCMCIA card, and the machine just hung.
Hard.

And the reason was that it would send an irq, but we were expecting it on
another interrupt. But if it showed up on something that was shared, you'd
have a hung machine, because you'd just have the (say) ethernet driver
saying "not for me", and returning. And obviously not able to actually
shut it up, so when we returned from the interrupt handler, the interrupt
happened immediately again.

So this really isn't theoretical. It's a very common failure scenario for
mishandled interrupts. In fact, exactly because it's so common, these days
we have all this special logic in the generic interrupt layer that
notices, and shuts them up entirely (but does so by disabling _all_ the
devices on that interrupt, so when this happens, you might well lose your
disk driver or something else).

			Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Thu, 14 Dec 2006 17:26:50 UTC
Message-ID: <fa.YGhPYp5NCaszakiJCVEnJkpNsQ8@ifi.uio.no>

On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>
> I don't get you. The rtc module does something similar (RTC generates
> interrupts and notifies userspace about it)

The RTC module knows how to shut the interrupt up.

(And in many cases, timers are special. Timers, by design, are often "edge
triggered" even in systems that have no other interrupts that work that
way. Exactly because a timer is special. So the RTC module often knows
that it doesn't need to do anything at all to shut it up, but even that
is special per-device knowledge, that is NOT TRUE for any normal devices).


		Linus

From: Linus Torvalds <torvalds@osdl.org>
Newsgroups: fa.linux.kernel
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
Date: Wed, 13 Dec 2006 21:27:08 UTC
Message-ID: <fa.8IHHjdL8l02zkO6AwOorYY1mcVA@ifi.uio.no>

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