Build breakage due to latest ARM fixes

[Russell King - ARM Linux]

On Sun, Aug 04, 2013 at 11:47:04AM -0700, Olof Johansson wrote:
> On Sun, Aug 4, 2013 at 11:37 AM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Sun, Aug 04, 2013 at 11:20:21AM -0700, Olof Johansson wrote:
> >> On Sun, Aug 4, 2013 at 5:53 AM, Russell King - ARM Linux
> >> <linux at arm.linux.org.uk> wrote:
> >> > On Sat, Aug 03, 2013 at 01:07:31AM +0100, Russell King - ARM Linux wrote:
> >> >> I'll look into that.  Obviously, I never build nommu because it isn't
> >> >> part of the build system and the nommu platform I do have - OKI67001 -
> >> >> doesn't have mainline kernel support.  (And if it did, it would not be
> >> >> DT, so I doubt it's submittable.)
> >> >
> >> > Okay, what I'm going to do is push the OKI67001 stuff into mainline
> >> > irrespective of DT or not, so that I can then add noMMU build _and_
> >> > boot tests to my build system, which should ensure that problems
> >> > like that get detected before they're pushed upstream.
> >>
> >> That seems like a step backwards. How have !MMU changes been handled
> >> until now? Someone external has been relied on for testing?
> >
> > No, they've had no testing as far as I'm aware.  noMMU never got to the
> > stage when it was merged that it had any platforms before Hiyok went
> > silent.
> >
> > The only real testing I'm aware of is when I recreated the OKI67001
> > support a while back and got my board to boot.
> 
> Uwe has been busy pushing various patches for M3/M4 support, I don't
> know how far it is from having some real hardware usable though. Uwe?
> 
> > As for qemu, software emulations while nice and convenient don't
> > accurately reflect real hardware.
> 
> Oh, agreed, it doesn't beat hardware-based testing but in the absence
> of hardware it's better than nothing.

Let's summarise this then:

"Hardware based testing is better than software testing".
"I have OKI 67001 hardware".
"I have OKI 67001 patches".
"We're going to not merge the patches but you can use software testing
 instead".

That's utterly idiotic if you ask me - and as long as you hold that view
I'm damned well totally uninterested in noMMU.

Thanks but no thanks.  If I break noMMU builds in future, so be it - I
don't give a damn about them.