linux-kernel - Re: [PATCH] uio_pdrv: Unique IRQ Mode

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:	Mon, 9 Jun 2008 18:01:23 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	"Hans J. Koch" <hjk@...utronix.de>
Cc:	Magnus Damm <magnus.damm@...il.com>, linux-kernel@...r.kernel.org,
	Uwe.Kleine-Koenig@...i.com, gregkh@...e.de,
	akpm@...ux-foundation.org, tglx@...utronix.de
Subject: Re: [PATCH] uio_pdrv: Unique IRQ Mode

On Mon, Jun 09, 2008 at 10:44:12AM +0200, Hans J. Koch wrote:
> On Mon, Jun 09, 2008 at 10:12:09AM +0900, Magnus Damm wrote:
> > >> > If it's a device within the SoC, you won't use UIO for that. If you did,
> > >> > your platform would depend on certain userspace software which is simply
> > >> > crap. And devices outside the SoC are board specific.
> > >>
> > >> Why wouldn't we use UIO for device within the Soc?
> > >
> > > Can't you read? I've answered that in the lines above your question.
> > 
> > I'm sure there are blocks within the SoC that must be managed by the
> > kernel, but that's not always the case. Certain things can be managed
> > by user space just fine. For instance, video acceleration hardware.
> 
> There are standard kernel subsystems to handle such devices. You should
> only make it a UIO driver if v4l, drm, fb doesn't work for some
> important reason.
> 
It's _precisely_ because the kernel is not the place to manage the
devices in question that UIO is being used in the first place. Some
things simply don't belong in the kernel. This has been stated several
times. Are you purposely only selectively reading this thread?

> > > Once more (for the last time): The technical argument against your patch
> > > is that it offers no advantages. It makes other code more complicated,
> > > less obvious, and less consistent. This might be OK if we had big
> > > advantages in return, but this isn't the case.
> > 
> > I say:
> > a) We need this for 5+ different SuperH hardware blocks.
> > b) This approach can be used by most architectures.
> > c) The code is architecture independent.
> > 
> > You say "it offers no advantages".
> 
> Yes, and your answer is the proof.
> 
Given that stunning technical rebuttal, the constructive way forward
seems to be to follow Uwe's suggestions and respin the patch.
--
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/