[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1166051517.29505.66.camel@localhost.localdomain>
Date: Thu, 14 Dec 2006 00:11:57 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Linus Torvalds <torvalds@...l.org>, Greg KH <gregkh@...e.de>,
Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists