Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 30 Jul 2003 12:44:21 +0200 | From | Adrian Bunk <> | Subject | Re: [2.6 patch] let broken drivers depend on BROKEN{,ON_SMP} |
| |
On Wed, Jul 30, 2003 at 10:11:17AM +0100, John Bradford wrote: >... > > * Driver does not work, and is thus disabled. If it is not > > fixed in the near future, it will be considered to be > > OBSOLETE as well. > > > > CONFIG_BROKEN > > Please do _NOT_ do this - there is a far more important and worthwhile > reason to have a CONFIG_BROKEN than to simply save the few minutes of > inconvenience that including a non-compiling option in a kernel build > causes. > > Imagine the situation where a driver such as a SCSI driver builds > successfully, but it silently corrupts data under certain, (possibly > rare), circumstances. > > In that case, it's important to warn people that it's broken, because > it's not necessarily obvious, and could case significant data loss. > If something doesn't compile, it already gives you an error message. > The only problem is a few minutes of wasted time.
You forget one important thing: If a _user_ of a stable kernel notices "it doesn't even compile" this gives a very bad impression of the quality of the Linux kernel.
> > * Driver works on uniprocessor but not on SMP and is thus > > disabled when compiling for SMP. It is assumed that the > > driver will be fixed for SMP if relevant. > > > > CONFIG_BROKEN_ON_SMP > > Please _don't_ do this either. It implies that if > CONFIG_BROKEN_ON_SMP isn't set, then it's SMP safe - a lot of drivers > will NOT have been tested on SMP, so it's a bad thing to assume that > is the case. >...
My patch adds BROKEN_ON_SMP only to drivers that don't compile, but if a driver causes e.g. data corruption on SMP I don't see a reason against letting it depend on BROKEN_ON_SMP.
> John.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |