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]

Date:	Fri, 4 Jun 2010 08:29:44 +0300
From:	Tony Lindgren <tony@...mide.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Russell King <rmk@....linux.org.uk>,
	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

* Benjamin Herrenschmidt <benh@...nel.crashing.org> [100604 03:56]:
> 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).

Yeah both platform data and device tree should work just fine.
 
> > - 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.

Thanks for all the good info, that will be handy when trying to
figure out how to change things to support multiple ARM platforms.

Regards,

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