linux-kernel - Re: ARM defconfig files

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]

Message-ID: <1275613325.1931.849.camel@pasglop>
Date:	Fri, 04 Jun 2010 11:02:05 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Russell King <rmk@....linux.org.uk>
Cc:	Tony Lindgren <tony@...mide.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Daniel Walker <dwalker@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: ARM defconfig files

On Thu, 2010-06-03 at 19:13 +0100, Russell King wrote:
> On Thu, Jun 03, 2010 at 07:46:23PM +0300, Tony Lindgren wrote:
> > Compiling in multiple ARM platforms is trickier, we would have to get
> > rid of the duplicate defines like NR_IRQS, then have some common clock
> > framework etc. Then figure out some way to get rid of Makefile.boot.
> > Russell probably has some other things in mind that would have to be
> > changed to make this happen.

Ok so multiple platforms in one kernel is a different subject and could
warrant a different thread. However it's interesting because we do that
quite well on powerpc :-)

(Note also that while the device-tree helps make it even easier, it's
not fundamentally necessary to achieve that goal).

> - Find someway to handle the wide variety of interrupt controllers.

We have a very nice and simple interrupt mapping scheme on powerpc that
makes that quite trivial along with the generic irq changes that went in
a couple of years ago (which we mostly based on ARM iirc).

We have a structure that define an interrupt numbering domain (which can
be associated 1:1 with a given controller but doesn't have to), and
simple APIs to allocate "linux" interrupt numbers associated with a
given domain/HW number pair. From there, we support multiple domains,
arbitrary layout and cascades, etc...

> - Be able to handle any multitude of V:P translations, including non-linear
>   alongside linear transations.

For the kernel "linear" mapping you mean ? Yeah, that's a bit of a sore
spot, though sparsemem + vmemmap helps a lot. Creative use of dynamic
patching would do nicely here though it's problematic with XIP kernels
(though my understanding is that those are getting less common).

> - Different PAGE_OFFSETs

Does this have to be a per SoC or mach family ? Users can change
PAGE_OFFSET on powerpc to change the user/kernel split (for example in
order to get more ioremap space or avoid turning on HIGHMEM) but it's in
the domain of the config and a kernel with a lower PAGE_OFFSET can
always boot all platforms even those that don't require it.

Alternatively, you can always try to do like we do on ppc64 with fully
runtime relocatable kernels :-)

> - Different kernel VM layouts allowing for a variety of different ioremap
>   region sizes
> 
> and so the list goes on...

That's quite easily done at runtime.

> > That way maybe you can wait a bit longer for the other defconfigs
> > and as an extra bonus I won't get flamed for removing these omap
> > defconfigs ;)
> 
> Note that Linus is talking about removing all but one or two ARM
> defconfigs - which means your omap3_defconfig will probably be
> eventually culled.

Cheers,
Ben.

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