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  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:	Fri, 4 Jul 2008 17:29:59 +0900
From:	Paul Mundt <>
To:	Uwe Kleine-K?nig <>
Cc:	Magnus Damm <>,
	"Hans J. Koch" <>,
	"" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [PATCH] uio: User IRQ Mode

On Fri, Jul 04, 2008 at 10:11:25AM +0200, Uwe Kleine-K?nig wrote:
> Magnus Damm wrote:
> > > Maybe it's sensible to add the User IRQ Mode functions at least for now
> > > into platform code.  Then at a later time if and when there are several
> > > copies the discussion to move it to the generic part might be easier.
> > 
> > Do you mean your uio_pdrv driver?
> No, I don't.  I meant arch/whatever/...
Placing it in arch/ makes no sense, as there is nothing platform or
architecture specific about it. It is a generic bit of functionality that
various platforms may or may not want to enable, it should be reflected
in UIO directly and simply enabled by those that care. Copying it around
all over the place to make up for the fact the UIO people don't want to
take patches is not a solution.

> If you want to add it to uio_pdrv you either have to introduce a new
> header file or you need to add it to uio_driver.h.  IMHO the first is
> ugly and I'm sure Hans will object the latter.
I'm sure Hans will object to pretty much any UIO patch that adds
functionality he didn't envision from the beginning, but that doesn't
justify burying this crap in the architecture code. Likewise, without any
serious technical objections to the user IRQ mode, it's also difficult to
care. So far all of the technical issues raised in this thread and the
ones before it have all been readily addressed, and I'm unaware of any
outstanding issues here.

Having said that, it would be nice to respin this encapsulating your
rewrite of the commit log so there's less confusion, and then see about
having Greg or Andrew merge this. The patch can easily be reworked if
anyone else raises any technical concerns about this particular approach.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists