lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ