Arjan van de Ven <[EMAIL PROTECTED]> wrote: > > On Sun, Jul 11, 2004 at 03:42:58AM -0700, Andrew Morton wrote: > > > We do not want to enable preempt for Fedora yet because it > > > breaks just too much stuff > > > > What stuff? > > just look over all the "fix preempt" stuff that got added to the kernel in > the last 6 months. Sometimes subtle sometimes less so. From a distribution > POV I don't want a potential slew of basically impossible to reproduce > problems, especially this young in 2.6, there are plenty of other problems > already (and before you ask "which", just look at how many bugs got fixed in > the last X weeks for any value of X, and look at say acpi issues). > Yes I understand this puts you into a bit of a bad position, several distros > not enabling preempt means that it gets less testing than it should. > However.. there's only so much issues distros can take and with 2.6 still > quite fresh... >
IOW: "we haven't found any such stuff". Sounds fuddy to me. > > > (Long-term i'd like to see preempt be used unconditionally - at which > > > point the 10-line CONFIG_VOLUNTARY_PREEMPT Kconfig and kernel.h change > > > could go away.) > > > > And "stuff" is already broken on SMP, yes? > > That's the classic preempt "myth"; it's true if you ignore per cpu stuff and > some other subtle issues ;) ? Sticking a WARN_ON(!in_atomic()) if CONFIG_PREEMPT into smp_processor_id() should catch any missed fixes. > And even then, yes a lot of our drivers are not > quite SMP safe. Take ISDN or any of the other declared SMP-broken drivers. > Not to speak of the ones that aren't declared as such yet still are. > Regardless of Hyperthreading, smp is still quite rare while crappy > hardware/drivers are not. > Oh I can buy the make-the-bugs-less-probable practical argument, but sheesh. If you insist on going this way we can stick the patch in after 2.7 has forked. I spose. The patch will actually slow the rate of improvement of the kernel :(
