On Tue, Dec 13, 2005 at 07:53:14PM +0000, Russell King wrote:
> On Tue, Dec 13, 2005 at 06:38:36PM +0100, Geert Uytterhoeven wrote:
> > On Tue, 13 Dec 2005, Russell King wrote:
> > > If, in order to have a working platform configuration, they deem that
> > ^^^^^^^
> > > CONFIG_BROKEN must be enabled, then that's the way it is.
> > ^^^^^^
> > Still funny...
> >
> > So either one of them is lying...
>
> They might be broken in other situations. However, if you look at
> the latest build at:
>
> http://armlinux.simtec.co.uk/kautobuild/
>
> you'll notice that all, even the ones with CONFIG_BROKEN build
> successfully. Without any bug reports to the contary, we must
> assume that the configuration files supplied by the folk who
> developed the support for the platform are correct and working.
The bug in this case was the (implicit) BROKEN dependency of MTD_SHARP.
> Therefore, CONFIG_BROKEN may have been added to configuration
> options which don't work for some particular small corner cases.
Such corner cases could easily be handled using
depends on (BROKEN || SA1100_COLLIE)
Or in other cases wie have
depends on (BROKEN || !64BIT)
If it works its not BROKEN, and we can express this.
> This brings on to another subject. If we mark something broken
> we should say _why_ we're doing so, especially if it is non-obvious.
> That seems to be the case here - if these drivers are broken, it's
> non-obvious why they're broken.
The vast majority of drivers depending on BROKEN simply don't compile.
How many examples besides MTD_SHARP can you name where you have problems
to determine why something is marked as BROKEN?
> So, all in all, CONFIG_BROKEN is a broken idea in itself!
The idea behind BROKEN is to not offer drivers where we know that they
don't compile or will for sure not work to users.
The ARM case that people are using the supplied defconfig's more or less
unchanged is a big exception.
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]