From: Ingo Molnar <mingo@elte•hu>
To: Linus Torvalds <torvalds@linux-foundation•org>
Cc: Alan Cox <alan@lxorguk•ukuu.org.uk>,
James Bottomley <James.Bottomley@HansenPartnership•com>,
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 02:30:55 +0200 [thread overview]
Message-ID: <20090610003055.GA26492@elte.hu> (raw)
In-Reply-To: <alpine.LFD.2.01.0906091702580.6847@localhost.localdomain>
* 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. 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.
Ingo
next prev parent reply other threads:[~2009-06-10 0:31 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 [this message]
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
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=20090610003055.GA26492@elte.hu \
--to=mingo@elte$(echo .)hu \
--cc=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=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