From: James Bottomley <James.Bottomley@HansenPartnership•com>
To: Ingo Molnar <mingo@elte•hu>
Cc: Linus Torvalds <torvalds@linux-foundation•org>,
Alan Cox <alan@lxorguk•ukuu.org.uk>,
Thomas Gleixner <tglx@linutronix•de>,
"H. Peter Anvin" <hpa@zytor•com>,
Andrew Morton <akpm@linux-foundation•org>,
Stephen Rothwell <sfr@canb•auug.org.au>,
linux-next@vger•kernel.org
Subject: Re: Request for linux-next inclusion of the voyager tree
Date: Wed, 10 Jun 2009 14:23:31 +0000 [thread overview]
Message-ID: <1244643811.4109.13.camel@mulgrave.site> (raw)
In-Reply-To: <20090610003055.GA26492@elte.hu>
On Wed, 2009-06-10 at 02:30 +0200, Ingo Molnar wrote:
> * Linus Torvalds <torvalds@linux-foundation•org> wrote:
>
> > On Wed, 10 Jun 2009, Ingo Molnar wrote:
> >
> > >
> > > * Alan Cox <alan@lxorguk•ukuu.org.uk> wrote:
> > >
> > > > > This code has been NAK-ed by the x86 maintainers:
> > > > >
> > > > > - Due to the absurd irrelevance of Voyager/x86/Linux hardware
> > > > >
> > > > > - Due to the thousands of lines of of code it adds to arch/x86
> > > > > to support a 486/P5 era piece of hardware
> > > > >
> > > > > - and due to its negative track record of:
> > > > >
> > > > > v2.6.27.0: Voyager was broken - it did not even build. (!)
> > > > > v2.6.28.0: Voyager was broken - it did not even build. (!)
> > > > > v2.6.29-rc5: Voyager was broken - it did not even build. (!)
> > > >
> > > > So Ingo you are arguing "It didn't work in some releases so we
> > > > want to make it continue not to work by trying to keep the fixes
> > > > out" ?
> > >
> > > No. This code is not in Linux right now, and that i see no reason to
> > > put it back, for the (many) reasons outlined.
> >
> > Ingo, "absurd irrelevance" is not a reason. If it was, we'd lose
> > about half our filesystems etc.
> >
> > Neither is "thousands of lines of code", or "it hasn't always
> > worked". Again, if it was, then we'd have to get rid of just about
> > all drivers out there.
> >
> > So give some real reasons. "It's a maintenance nightmare because
> > it does xyz" might be a reason. But then we really need to see the
> > "xyz" part too.
> >
> > Alan is definitely right that we're likely to see more of the
> > "non-PC" platforms as x86 tries to do embedded.
>
> That is true, and the whole painful conversion from the build-time
> 32-bit sub-arch code to the unified runtime quirk code (which is
> really 'non-PC platform driver' kind of thing) that i did a few
> months ago was partly about that.
>
> I dont dispute that aspect - in fact we merged a rare subarch as
> well.
>
> But Voyager has been the most painful subarchitecture by far - for
> an extended period of time the code didnt even build in its
> defconfig - and it is also the most useless one as well. So it was
> just a token really.
>
> The only action i got from James was when _I_ implemented the
> proper, runtime subarch mechanism and when we actually _removed_ the
> voyager code. Before it James resisted such changes, see this thread
> almost a year ago, in the Nth "voyager breaks the build" discussion,
> where i suggested:
>
> " btw., any chance to turn it into a quirk space thing? "
>
> http://lkml.org/lkml/2008/4/21/441
>
> I got no action from James for my technical requests.
However, you did get a reply worrying about the technical aspects:
http://marc.info/?l=linux-kernel&m=120881937304045
And later on me worrying about the increase in pointer function
indirections. When you forcibly did the conversion anyway the voyager
conversion was done within a couple of weeks.
> Right now i
> dont see any guarantee that this wont be repeated, once the code is
> upstream again after meeting some threshold minimally.
>
> Voyager was a painful experience to all x86 maintainers and i'd
> expect pushers and supporters of rarely used code to do such work,
> not maintainers.
>
> Are the quality thresholds i outlined in the previous thread(s)
> unreasonable? They were:
>
> " If the code is absolutely trouble-free out of tree, for an
> equivalent amount of time (3 kernel releases or so), and gathers
> users/testers/etc., then we might add it, after a thorough
> technical review. "
>
> http://lkml.org/lkml/2009/4/19/181
>
> Given that there are only two known boxes left (both James's, the
> other one went missing in action somewhere in Brasil), the 'gather
> testers' bit is unreasonable i guess. 'Prove you can stay trouble
> free' is more realistic. Dunno.
>
> See for example what happened in linux-next today: Voyager broke x86
> and didnt even build, and Stephen had to keep it out of today's
> linux-next build.
Integration testing in configurations I either can't build or don't have
the machine power to run over is one of the incredible values of
linux-next, and why stuff needs to be in there before being pulled into
mainline. The bug was fixed within about an hour of being found, but I
need linux-next to help me find this and other problems.
James
next prev parent reply other threads:[~2009-06-10 14:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 16:10 Request for linux-next inclusion of the voyager tree James Bottomley
2009-06-08 23:28 ` Tony Breeds
2009-06-10 14:45 ` James Bottomley
2009-06-09 9:45 ` Stephen Rothwell
2009-06-09 13:49 ` James Bottomley
2009-06-09 20:21 ` Ingo Molnar
2009-06-09 20:33 ` James Bottomley
2009-06-09 21:18 ` Ingo Molnar
2009-06-09 23:41 ` Alan Cox
2009-06-09 23:56 ` Ingo Molnar
2009-06-10 0:04 ` Linus Torvalds
2009-06-10 0:30 ` Ingo Molnar
2009-06-10 1:00 ` Ingo Molnar
2009-06-10 14:38 ` James Bottomley
2009-06-10 15:20 ` Linus Torvalds
2009-06-10 15:28 ` James Bottomley
2009-06-10 15:33 ` Linus Torvalds
2009-06-10 16:19 ` Ingo Molnar
2009-06-10 16:42 ` Ingo Molnar
2009-06-10 14:23 ` James Bottomley [this message]
2009-06-10 15:13 ` Thomas Gleixner
2009-06-10 15:23 ` Linus Torvalds
2009-06-10 15:39 ` Ingo Molnar
2009-06-10 16:02 ` James Bottomley
2009-06-10 16:53 ` Ingo Molnar
2009-06-11 1:35 ` Stephen Rothwell
2009-06-11 1:39 ` James Bottomley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1244643811.4109.13.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=alan@lxorguk$(echo .)ukuu.org.uk \
--cc=hpa@zytor$(echo .)com \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=tglx@linutronix$(echo .)de \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox