[Ksummit-2012-discuss] [ATTEND] <ding> "Bring out your dead" <ding>...
paul.gortmaker at windriver.com
Tue Jun 26 00:03:34 UTC 2012
With the CFP asking for a list of expertise, I was hesitant to really
apply that label to anything I've done, and hence add my name to the
pool. I'd like to think my work has been useful, but it sure would be
one heck of a stretch to say it was anything like the technical
innovations of an expert.
But with the hindsight of a week's worth of topic discussions, I think
there could be good value in being present; there are clearly going to
be discussions around "where are we going and how do we get there" vs.
it all being super low level "optimize this code block in your head"
type of discussions (the latter for which I won't even pretend to be
With that said, I'll substitute "experience" for "expertise" and hope
nobody notices. Some more recent work has been the header cleanups
(module/export.h, device.h, bug.h), maintainer of the 2.6.34 release
(also created 2.6.34-RT), the removal of micro channel architecture and
token ring, UART reorg and better compartmentalization of SOC specific
UART errata, closure of the net/tipc backlog integration, the 15000
line autoconf/IS_ENABLED thing, scattered changes in the drivers/net
dir, and a lot of quasi random linux-next build fixes (mostly in the
less common arch.)
The last of the above is the one that leads me into one of the main
discuss points I'd like to be involved in. The header shuffles had
me more involved in the linux-next process, watching to see if I
somehow broke something. Often it wasn't clear without a bisect, and
by then I was typically 95% of the way to having a fix, even if
I wasn't the cause -- hence all the scattered build fixes coming from
my triage of linux-next.
But in doing so, it got me thinking about the time spent fixing fringe
bugs. I started to become more aware of the "tax" it imposed. (The
same one that hpa brought up here last week in "Wither the baseline".)
In hpa's mail, he categorized things as constraints, and at the risk of
stating the obvious, I'd say the tax goes beyond constraints and into
the "lost time" territory. For an API update, we end up editing files
that are no longer actively used. For a "git grep" you've searched
files that you shouldn't need to care about. For an "allyesconfig" you
(and all the automated build tests across the planet) have waited on the
successful outcome of a compilation that doesn't matter. For runs of
Coccinelle/sparse/coverity, you are doing analysis on (and proposing
fixes to) code that has expired from use. No one item is huge, but they
add up, and they affect us all.
As tglx noted, there is a finite number of people available with the
skills required to review some of the more complicated patches and
subsystems that we have today. As a recent concrete example, I
(and I'm sure many others) watched as Al was cursing, suffering through
trying to parse asm files on unfamiliar architectures for an arch wide
signal handling fixups. Raise your hand if you think Al would have
been happier (and the community better off as a whole) if Al was
instead free in that time to rummage around looking for VFS bugs or
The removal of MCA and token ring was driven by this exact "reduce the
tax" motive, and I was happily surprised it didn't get filibustered
into not happening at all. (I think part of why that didn't happen is
thanks to DaveM not wasting any time in saying he wanted the TR removal
in net-next ASAP.) But that aside, I think it was also a relatively
clear case of where removal made sense. Others are not so clear.
Old [essentially dead] code is like the guy going on the cart from
Monty Python. Just when you think it well and truly time to push it
off a cliff, I can guarantee someone somewhere will pop up and say "I'm
not dead yet". [Possibly with ad hominem arguments against the
submitter.] But it is wrong to let one squeaky wheel prevent us from
doing the right thing, or worse -- to cause us to shy away from at least
considering what the right thing to do [and when] is.
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.
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.
What about Alpha? It was effectively killed 10+ years ago by Compaq.
I suspect most of the Alpha machines still hiding in basements here and
there are EV5/EV6 desktops with Pentium-3 class performance. Sure
there were faster machines made in the post Compaq takeover era, but
given that they could be in excess of $1,000,000 -- I'll guess that the
number hiding in basements is low. Are Alpha machines being actively
used? I don't know. Also worth investigating. Not so we can remove
it tomorrow, but even the most ardent supporter would have to admit
that _someday_ removal will make sense. Lets discuss the EISA
dependency (if it exists) and set a ballpark on when that someday just
might be. Then we can warn people well in advance.
Generally speaking, what about stuff that clearly has fallen exclusively
into the "hobby" class, with an almost zero user base, but is to all
intents and purposes actively maintained. Is being maintained enough to
offset not being used? I don't think we can boil this down to a simple
yes or no. But to some degree, old hardware needs old software, simply
from constraints on RAM size and CPU power. For example, anyone with a
20 year old desktop MCA sytem was better served by using a 2.4 kernel
than they ever would have been by trying to use anything of today. This
showed up in practice too -- web evidence largely indicated they never
made the move from 2.4 to 2.6. And if anything isn't _used_, we should
be taking a hard look at why we are carrying it.
Part of dealing with removal should be diminishing the perception of
what it means to be removed from tree. We know we will sometimes get
a defensive reaction as people overlook the tax aspect and instead the
focus gets misinterpreted as as someone attacking someone else's pet
project. I think we can mitigate that. I can think of several simple
points we can highlight to do that already.
1) Once you step outside of the mainstream arch and/or into the hobby
realm, you are pretty much guaranteed to not be using a distro, but
rather a custom build, custom .config and even custom kernel. But
of course you have the source too. How else could you have
created your custom build? So, you are free to revert/patch back in
whatever driver(s) or support you want, and share it (made easy with
github) with whoever you want. If there is interest in it, it will
survive. Even if you are the one and only person interested, you've
still made it survive. The actual location of the source code really
is not of unconditional importance.
2) With point #1 in mind, there simply isn't the absolute finality
associated with mainline removal in linux as there would be in the
binary world, say if Windows8 said they were dropping Adaptec AHA1542
SCSI support (assuming it isn't long gone already.)
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!
Point #1 above goes in the right direction of assisting with hpa's
issue of having the cost of supporting the fringe being fronted by the
userbase who want it, vs being on the developers at large.
Overall, if we make it clear that these things are being actively
considered by maintainers and core linux people, it will mitigate the
"gold rush" factor -- where lots of random people start proposing less
than fully researched deletion proposals, complete with thousands of
meaningless lines of deleted file content in each lkml post.
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.
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.
OK. Enough on being selective with additions, and proactive about tree
pruning and the like. Quickly, some other things I'd like to be
involved in discussing are:
-general things about stable; learning more about how Greg automates
things, about folks who don't take stable as a whole, but pick bits out
of it, when does it make sense to end the 2.6.34 stable, how best to
queue things for 3.4 LTSI etc.
-discussions about linux-next, and triage, and expanded build coverage;
all hopefully leading to catching things before they become build
regressions in the rc0 --> rc1 history that make bisection increasingly
difficult once you land in that range.
If there is interest, I'd also be open to having informal hallway
discussions covering what we (WR) do and what we don't do to our
kernels, where we spend our time most, and things like that. Part of
that would also be information gathering for me -- in that as one
example, I'd like to hear how others balance the tradeoff between
getting more people involved vs. trying to stave off over-eager newbie
eruptions that do little more than annoy subsystem maintainers. Or how
others decide what problem spaces they will spend time on.
Anyway, if you managed to get this far, then thanks for reading.
Regardless of whether I get there or not, hopefully these topics
can make it into some of the discussions that take place.
More information about the Ksummit-2012-discuss