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-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
