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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080609084411.GA3223@local>
Date:	Mon, 9 Jun 2008 10:44:12 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	"Hans J. Koch" <hjk@...utronix.de>, linux-kernel@...r.kernel.org,
	Uwe.Kleine-Koenig@...i.com, gregkh@...e.de,
	akpm@...ux-foundation.org, lethal@...ux-sh.org, tglx@...utronix.de
Subject: Re: [PATCH] uio_pdrv: Unique IRQ Mode

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

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