[Ksummit-2012-discuss] [ATTEND] <ding> "Bring out your dead" <ding>...

Paul E. McKenney paulmck at linux.vnet.ibm.com
Wed Jun 27 00:12:40 UTC 2012

On Tue, Jun 26, 2012 at 02:06:32PM -0700, H. Peter Anvin wrote:
> On 06/26/2012 01:05 PM, Paul E. McKenney wrote:
> > 
> >> Maybe it's time to start a linux-legacy kernel project and move stuff
> >> in there that we are no longer interested in having in the regular
> >> kernel. I don't think we should be doing this as long as the maintainer
> >> is reasonably active and prefers to have the code upstream, but if either
> >> there is no maintainer or the maintainer prefers to have his code in the
> >> legacy tree, we could have a fast-path out.
> > 
> > Makes sense to me, though as of 2010 the Alpha guys were definitely
> > interested in remaining in the Linux kernel.
> Who are the "alpha guys" and to what extent are they willing to make
> sure they don't become a roadblock to general kernel development?  It is
> getting a *very* frequent objection to various design choices that "I
> would have to touch every architecture if we did it this way."
> Obviously, this indicates a real problem if contributors are pushing
> suboptimal solutions, often because of a semi-arbitrary boundary what is
> arch and what is not.

I agree that further consolidation of arch code would be good.  After all,
the more that is core code, presumably the lower the probability of a
given change needing to change all architectures.  And there has been
a tendency for people to implement new things totally within their own
architecture for various reasons.

> One *serious* issue is that we have things in the "arch" domain that are
> there only because we keep using handcrafted ABIs for system calls
> instead of picking rules that can be mechanized.

The Alpha guys are particularly bad offenders here, or is this a
separate issue?

							Thanx, Paul

> asm-generic helps that somewhat for new arches, but there are a lot of
> old ones that don't use asm-generic, and even asm-generic doesn't cover
> all the bases.

More information about the Ksummit-2012-discuss mailing list