[Ksummit-2012-discuss] [ATTEND] <ding> "Bring out your dead" <ding>...
arnd at arndb.de
Tue Jun 26 19:55:01 UTC 2012
On Tuesday 26 June 2012, Paul Gortmaker wrote:
> In hpa's section 4 "Archaic Hardware" he emphasizes the difference
> between it probably might still work vs. "actually *using*" it when
> discussing sub-50MHz i386 parts. I think this is probably as good a
> starting point as any for guiding us in general -- i.e. "is it used?".
> In commit f6072452c903f2e4dcbae1230f8fbcbf058bd71a I tried to fix up
> arch/xtensa -- but looking at:
> you can see the defconfig has failed more often than not, going back to
> late 2008. Is the arch dead? Or does it have an active user base who
> just does not change version often (i.e. tied to a vendor SDK) and just
> no real regular maintenance? I don't know. Something worth learning.
There seems to be some activity in xtensa according to
but nothing really targetted at recent kernels.
The score architecture is actually in a worse shape after the
maintainer left the company and nobody else has stepped up.
> Linus mentioned that perhaps someday we might be able to remove EISA as
> well. It seems to make sense to me too, given that EISA (at least in
> x86) was largely confined to 486 and 586 (sub-200MHz) server machines,
> and largely all crushed out of existence by PCI around 1996. But some
> non-x86 boxes may rely on EISA -- such as some Alpha boxes, I think.
Sounds reasonable to me, but only if the arch maintainers for
mips, alpha and parisc are ok with this.
Those are actually more likely to still in the hands of someone who
cares about them than the x86 PCs are. Removing EISA support might
imply killing a few platforms altogether.
> 3) Things that are being considered for removal are least likely to
> see an advantage by being on the bleeding edge. Take the MCA case.
> If you'll allow me the conclusion that MCA on 3.5 wouldn't have
> been any fundamentally better than MCA on 3.4 -- then you can
> get on the (semi announced) 3.4 LTSI train, and have a supported
> kernel base for your MCA that will take you well into the year 2014!
Very interesting point. This could also help give some life to hobbyist
projects. So if we were to remove ia64 support in 3.5, 3.4-ltsi could
be the "official" ia64 upstream kernel until it gets replaced by
3.9-ltsi or so ;-)
> I'm not suggesting that we've never done deletions before, as powerpc
> shed old targets in the ppc->powerpc move, ARM has tossed out some
> early IXP stuff, and Sparc recently got rid of sun4[c,m]. Instead
> I'm suggesting that it remain something we always keep reconsidering.
We've actually done quite a few removals on ARM over the last year,
typically throwing out two platforms per release, and now getting
rid of the ARMv3 support after it turned out to be broken. This is
partly a symptom of large-scale changes going on in ARM that makes
the unmaintained bits show up more noticeably.
> Lets also briefly consider additions, as a way to prevent removals.
> For a long time we've been telling people to "get your code in tree,
> so that you get fixes for free". There is definitely still a component
> of truth there, especially from the point of view of the submitter, but
> I agree with Alan's point of there being a time when the right answer
> may simply be "no". I say this with the experience of having seen many
> SOC/SDK vendor patches which are so ugly that there is no hope of
> them ever being salvageable, even just for staging. There is also the
> factors of number of users, churn of integration, expected maintenance
> (vs. a dump-n-run) and expected lifetime of interest -- all should be
> considered as part of the "do we merge this?" question, I think.
Again on the ARM example, we're setting the bar pretty high for a new
platform port these days, but they keep coming in, and I think that's
good. For whole new architectures, things have slowed down a bit, and
as I mentioned I have not heard much from meta, arc, lm32 and nios2
in some time, though when the code looks good I would definitely recommend
them going in.
More information about the Ksummit-2012-discuss