Re: [2.6 patch] don't allow users to set CONFIG_BROKEN=y

[Adrian Bunk]

On Tue, Dec 13, 2005 at 08:01:06PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 07:05:52PM +0100, Adrian Bunk wrote:
> > On Tue, Dec 13, 2005 at 05:31:12PM +0000, Russell King wrote:
> > > The defconfig files in arch/arm/configs are for platform configurations
> > > and are provided by the platform maintainers as a _working_ configuration
> > > for their platform.  They're not "defconfigs".  They got called
> > > "defconfigs" as a result of the kbuild "cleanups".  Please don't confuse
> > > them as such.
> > > 
> > > If, in order to have a working platform configuration, they deem that
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> > 
> > if a working platform configuration configuration requires 
> > CONFIG_BROKEN=y, the problem is a bug that should be fixed properly.
> 
> Maybe they're only broken for a small subset of platforms, and someone
> added a BROKEN without properly considering whether it should be global
> or not?
> 
> I don't disagree with the overall notion that CONFIG_BROKEN should not
> be set _where_ _possible_.  However, if it needs to be set to get the
> required options, then that's what needs to happen until such time that
> the above is corrected.

Where is the bug report from the person who set CONFIG_BROKEN=y in the 
collie defconfig that the BROKEN dependency on MTD_SHARP was wrong?

> However - and now to the main bug bear - how can we tell what is really
> broken if you _just_ change the default configuration file settings for
> CONFIG_BROKEN?  What happens is that, on review, we see a simple change.
> We'd assume that it has little impact, and we accept that change.
> 
> Maybe a month or two down the line, someone whines that their platform
> doesn't work for some reason, and it's tracked down to this and the
> resulting fallout from disabling CONFIG_BROKEN.

The whining is the bug report the person who set the CONFIG_BROKEN=y in 
the defconfig didn't send.

And things would have been even worse if I had sent a patch erasing 
MTD_SHARP from the kernel because code "both marked as obsolete and 
BROKEN can clearly be removed" and the code was therefore completely 
removed two months before the first person whined?

> That means that the original review was _worthless_.  It wasn't a
> review at all.
> 
> So, what I am trying to get across is the need to show the _full_ set
> of changes to a default configuratoin when you disable CONFIG_BROKEN,
> which is trivially producable if you run the script I've already posted.
> 
> You can even use that in conjunction with your present patch to produce
> a patch which shows _exactly_ _everything_ which changes as a result of
> disabling CONFIG_BROKEN.  Surely giving reviewers the _full_ story is
> far better than half a story, and should be something that any change
> to the kernel strives for.
> 
> If not, what's the point of the original change?

The point is that I haven't yet heard any good reason for 
CONFIG_BROKEN=y in a defconfig.

No, it's not a good reason if someone used it as a workaround instead of 
sending a bug report that would result in a fixing of the wrong BROKEN 
dependency.

Where is the bug report of the person setting CONFIG_BROKEN=y in the 
collie defconfig that the MTD_SHARP dependency on BROKEN was wrong?

> Russell King

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/