[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOesGMjL5EgshxssehxkRTMMyJWyKVaSkAfoY_3SFbkfnJNAGA@mail.gmail.com>
Date: Sun, 4 Aug 2013 12:19:36 -0700
From: Olof Johansson <olof@...om.net>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Subject: Re: Build breakage due to latest ARM fixes
On Sun, Aug 4, 2013 at 12:01 PM, Russell King - ARM Linux
<linux@....linux.org.uk> wrote:
> 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@....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@....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.
All I was really trying to say is that it's unfortunate to add a
non-DT enabled platform now that we've done so much work towards the
goal of getting rid of them.
Software vs hardware testing was mostly tangential and unrelated.
-Olof
--
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/
Powered by blists - more mailing lists