Message-ID: <19092.32844.283719.302357@cargo.ozlabs.ibm.com>
Date:	Wed, 26 Aug 2009 10:22:36 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	dwalker@...o99.com, mingo@...hat.com, hpa@...or.com,
	linux-kernel@...r.kernel.org, johnstul@...ibm.com,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:timers/core] timekeeping: Increase granularity of
	read_persistent_clock()

Theodore Tso writes:

> Paul, Ingo, it seems like the two of you are talking past each other.
> He's said he's OK with generic code which somehow affects an
> architecture only being tested on one architecture, so what you're
> proposing is a straw man.  What he has requested it would be nice that
> each line of code be compile-tested on at least *one* architecture.
> If it's generic code, then by definition when you compile on x86, it's
> met the criterion he has proposed.
> 
> On the other hand, your claim that it would slow down development too
> much is based on the assumption that if you make a change in generic
> code that breaks architecture-specific code, it's good manners to at
> least *attempt* to fix up the architecture-specific code, as opposed
> to leaving it broken.  So you could meet Paul's request of "not
> committing code that hasn't been compile-tested" by simply leaving
> that particular architecture broken when you change generic code.
> 
> Personally, I think that would be worse, since that exchanges the risk
> that a generic change might break the PowerPC architecture, with the
> *certainty* that the PowerPC architecture would be broken by said
> change.  :-)  So it may very well be that you are doing the right
> thing.

Upon reflection, I think that a large part of the problem in this
particular instance is that while an attempt was made to fix up the
powerpc architecture code, it was never cc'd to any powerpc developer
or mailing list, and as far as I can tell it wasn't sent to linux-arch
either.

> I will note, by the way, that in the file system space, where we have
> almost 70 filesystems, I doubt very much that every single generic
> change in the core VM or FS code that might have a potential to affect
> every single filesystem gets compile-tested using allyesconfig.  Maybe

I think Stephen Rothwell does an x86 allyesconfig build of the
linux-next tree every day, so if the generic changes are in linux-next
they will in fact get tested against every filesystem.

> In the case of architecture code where compile-testing on every single
> architecture would require keeping very large number of
> cross-compilers, and a non-trivial amount of time, it's much less
> reasonable.  Doing a full test on all architectures before pushing to
> Linus (as opposed to publication in a -tip git branch) may be the best
> that can be expected.

Well, it used to be that if you had a patch that affected several
architectures, you'd post it to Andrew Morton and linux-arch, and
collect acks from as many architecture maintainers as you could in a
reasonable time.  And if you could cross-compile your patch yourself,
that was a good thing to do as well.

Ingo seems to be bypassing that step in order to speed up development
on x86.  Now, I can imagine a value system where that is a logical
thing to do, but it is not my value system. :)  I think this is why
several architecture maintainers have got unhappy with Ingo recently.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists