Re: [tip:timers/core] timekeeping: Increase granularity ofread_persistent_clock()

[Theodore Tso]

On Tue, Aug 25, 2009 at 03:50:17PM +0200, Ingo Molnar wrote:
> > [...]  It's like making changes inside #ifdef CONFIG_FOO but never 
> > testing with CONFIG_FOO turned on.  You'd complain, and rightly, 
> > if someone did that.
> 
> You again seem to ignore the very valid case i pointed out: if i 
> change generic code (or an include, an inline function or a define) 
> which somehow affects an architecture, by your logic i'd be 
> compelled to test it on that architecture - because it affects it. 
> That's not reasonable overhead.

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.

It's the combination of Paul's request that it be good manners that
all architecture specific code be compile-tested at least once, and
the generally accepted criterion that when someone makes a change in
generic code, that all in-tree users should be converted to use the
new calling convention --- after all, that's one of the benefits that
we tout to device driver writers for merging code into the mainline.


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
it should, but I suspect it's not all that uncommon for people to
assume that simple syntactical change of adding an extra parameter to
a function signature (for example) can be addressed using a global
search and replace, and not necesarily tested on every single
filesystem.  Maybe it *should* in the ideal world, but I'm guessing
that sometimes that doesn't happen...

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.

						- Ted

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