linux-kernel - Re: [RFC PATCH 1/5] irq_work: Move irq_work_raise() declaration/default definition to arch headers

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:	Tue, 16 Oct 2012 16:40:09 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Catalin Marinas <catalin.marinas@....com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>
Subject: Re: [RFC PATCH 1/5] irq_work: Move irq_work_raise()
	declaration/default definition to arch headers

On Tue, Oct 16, 2012 at 09:25:11AM +0000, Arnd Bergmann wrote:
> On Tuesday 16 October 2012, Mark Brown wrote:

> > That'd work, but I assume there is some reason why we've got this system
> > of explicitly adding each file.  It's not like cpp can test for the
> > presence of include files.  If we can't figure out why we're not doing
> > this I'd propose we start.

> We discussed renaming asm-generic to asm before, but some people objected
> to the use of #include_next. There is a smaller problem with opening the
> asm/*.h namespace to header files that are not relevant for architctures,
> so I'd prefer to have a well-defined list of headers that are implicitly
> shared, but it's not a technical argument.

Perhaps what we need here is a more elegantly named
asm-default-implementation which is for the headers which almost every
architecture should be using (like clk and gpio) since the APIs should
be at least stubbed in order to avoid making the architecture terminally
annoying.

Alternatively we go to the gpiolib approach where I just made
architectures that want to do fun stuff select a Kconfig symbol and
otherwise the default is directly in the linux/ header.  This was
massively easier to deploy all round.

The case where the current situation is really annoying is the case
where we want to allow some sort of performance optimisation in
something that's normally there and probably doesn't need it; right now
the cost is on the API users to convince every single architecture
maintainer to adopt the API.
--
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/