On Thu, 31 Mar 2011, Russell King - ARM Linux wrote:
On Thu, Mar 31, 2011 at 10:54:40AM +0100, Alan Cox wrote:
If I boot it on a current PC I'm booting on a multiprocessor system with
different timers, totally different IRQ controllers, different keyboard
controllers (USB), PCI Express, an IOMMU, NCQ SATA, ACPI, graphics
running in shared host memory able to give/take pages from the host,
extra instructions, etc etc
And the same kernel boots just fine on both just fine.
We've been there for a long time with ARM. Right from the start I had
a single kernel image which booted over a range of ARM CPUs and
platforms.
As far as ARM CPU architectures go, today we can have a single kernel
image which covers ARMv3 to ARMv5, and a separate kernel image which
covers ARMv6 to ARMv7 including SMP and UP variants. The thing which
currently stops ARMv3 to ARMv7 all together is the different page table
layouts, the ASID tagging, the exclusive load/store support for cmpxchg
and other atomic operations, etc.
I don't think the push is to get a single kernel image that boots
absolutly everywhere. having separate ARM5 and ARM7 kernels doesn't seem
to be a big deal to anyone.
Outside of the CPU architecture, things become a lot more complicated.
exactly, and this is where there is an issue.
The biggest one up until this merge window was that there is no fixed
address for system RAM, which makes stuff like virt_to_phys() rather
horrible to deal with - which in turn makes setting up and walking page
tables a nightmare. We've just solved that issue with run-time patching
of the kernel code to replace the add/sub instructions with ones with
the appropriate offset, so we're a step closer to unifying everything
into one single kernel image. This work alone produced this diffstat:
87 files changed, 450 insertions(+), 190 deletions(-)
so it actually resulted in a net increase in the amount of code to be
maintained rather than reducing it. That's hardly surprising as what
that replaced was just a bunch of #define's for PHYS_OFFSET with some
complex assembly code to do run-time patching of instructions.
but I don't think this sort of work is what anyone is complaining about.
Given this thread, I've lost the motivation to continue with it because
it's just going to cause more 'pointless churn' and end up annoying
Linus even more.
it sounds like you are part of the solution, not part of the problem. the
biggest problem is the general response from 'the ARM community' when
these sorts of issues are raised claiming that there is no problem. you
seem to be very aware of the problem and are working to fix it. that is a
very different situaion.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
