Re: [PATCH] uio_pdrv: Unique IRQ Mode

["Hans J. Koch" <hjk@linutronix.de>]

On Mon, Jun 09, 2008 at 10:12:09AM +0900, Magnus Damm wrote:
> >
> > The objection is that your code offers no advantages. What can we do
> > with your patch applied that we cannot do with uio_pdrv alone?
> 
> Yes, it is possible to have board or architecture specific hooks, but
> does that really make sense if the code is generic and can be reused
> by multiple architectures? I say it doesn't make sense at all.

So that's your answer when I ask what your code has to offer?

> 
> >> > 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.

> 
> >> I've been doing
> >> that for quite some time now.
> >
> > Really? I haven't seen any such driver yet. IMO, support for everything
> > inside a SoC should be completely within the kernel, I wouldn't do it
> > with UIO. But it's up to the arch maintainer to decide that. Did you ask
> > him?
> 
> Regarding driver source, I have posted a user space test driver here:
> 
> http://article.gmane.org/gmane.linux.ports.sh.devel/3927
> 
> As for kernel driver source, you have it earlier in this thread. I'm
> planning on pushing my user space VIDIX driver upstream, but I'd like
> to get the kernel parts merged first or at least acked. This UIO
> specific piece of the puzzle unfortunately seems to take forever.
> Which really is a shame, because it's all very simple.

Why do you need that stuff that works only with irqs that are not
shared? Why don't you simply do it with uio_pdrv? Or a normal UIO
driver?
After a brief look over your userspace code, I cannot see why you need
any additions to the UIO core code.

> > 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.

Thanks,
Hans