Re: [PATCH] uio_pdrv: Unique IRQ Mode

[Paul Mundt <lethal@linux-sh.org>]

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.