On Wed, Jan 07, 2015 at 04:15:00PM -0500, Nicolas Pitre wrote: > > > However, if running userland on platform A works, and but it doesn't > > work on platform B. The breakage may well be due to platform A reporting > > 300 bogomips because it's using the kernel software loop, and platform > > B reporting 6 bogomips because its using a hardware timer, but the CPU > > is actually faster. However, this is not a kernel problem, and it > > certainly is not a regression. It's a userspace bug which needs > > userspace to fix. > > There I disagree. In the spirit of "the kernel shall never break user > space ever" I'd say that the kernel is simply doing a poor job at > providing user space with a value that won't break user space > expectations. And since it is not that hard to do (I made a patch > already) I'd say we have less to lose by fixing it than keeping a > totally senseless value around.
It's not that the kernel shall never break userspace. It must not cause userspace regressions. If application A worked on box X and they upgrade the kernel and then application A no longer works. That's a regression, and must be fixed. Now if I understand what Russell stated, if application A works on box X and you move to box Y using the same kernel, and application A no longer works, that's not a regression with the kernel (unless it use to work on box Y). If it never worked on box Y, it's a platform issue and application A is not robust enough to deal with it. AKA, not a kernel bug. Now, it gets interesting if a fix was made that lets application A work on box Y, but that fix broked application B on box X. Reverting that fix will cause a regression for A or Y, but the fix itself caused a regression for B on X. In that case we need a new fix (which may be the case we are here). -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
