Re: Ingo, no more kconfig patches
From: Adrian Bunk
Date: Sat May 03 2008 - 18:04:43 EST
On Sat, May 03, 2008 at 11:52:14PM +0200, Ingo Molnar wrote:
>
> * Adrian Bunk <bunk@xxxxxxxxxx> wrote:
>
> > > at minimum a warning needs to be emitted by the kconfig tool if such
> > > incomplete selects are used. I've stopped counting the number of
> > > times such issues have broken the build and have held up kernel
> > > development.
> >
> > It might held up your randconfig compiles.
> >
> > Actual kernel development isn't much affected.
>
> uhm, you are quite wrong - countless times have people been bitten by
> select's breakages in the past, and not via randconfig. That's the main
> reason why select use in Kconfig was not encouraged for a long time.
But it has not "held up kernel development".
Send a bug report to linux-kernel or with a Cc to me and I'll look at
the bug.
I've done this for years.
> Select does make sense in some situations but it's a double-edged sword:
> kconfig does not warn at all about the situations where it's "unsafe" to
> use it - while it has all the information in the Kconfig files to emit
> that warning. Instead we get build breakages not visible when an
> incorrect select is added, but much later, if someone happens to stumble
> on the wrong kind of .config. That is obviously harmful.
And how would a warning help?
>From an UI perspective we often want to select options that have
dependencies.
> My larger point is that this kconfig tool bug breeds a constant stream
> of avoidable breakages, which causes lost manpower and causes a stream
> of trivial patches hindering maintainers all around the tree. Because
> every such trivial patch has to be reviewed, tested, it clogs the commit
> logs, etc.
>
> So the more trivial patches we _avoid_ having to do in the future, the
> better. I'm not sure why you are even arguing against this this rather
> simple point - your arguments are rather hard to understand. Wouldnt you
> be happier if a whole category of trivial breakages was avoided and if
> you didnt have to deal with and waste your time on that category of
> trivial patches anymore?
>
> Most of the time reoccuring trivial patches are an indicator of some
> deeper structural problem - as in this case.
Your conclusions are based on an assumption that isn't true.
"trivial patches" are the patches you send.
But they are often bogus.
Fixing these issues properly often requires a deeper understanding of
both kconfig and the dependencies of the underlying code.
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
--
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/