On Thu, 22 May 2008 19:50:08 +0300
Adrian Bunk <bunk@kernel.org> wrote:
and on a 2.4 kernel, and with likely with some binary modules at that.
it's cool to brag about market share, but these boxes unfortunately
don't have any value for Linux development.
You know, and I hate to say this, I'm getting a bit tired of your
attitude of just throwing up your arms at the problem and at the same
time trying to discredit anything and anybody who tries to improve the
situation. Really, it's not helping nor does it improve ANYTHING.
I gave you real data before based on first hand experience from
maintainers. We now have crash data, and we have data from every place
in the kernel that dumps a backtrace. We track regressions and we can
show that we attack the majority of those very agressively, and Linus
has delayed releases for serious regressions. Just throwing your hands
in the air and saying "it's hard don't even try and I don't want you to
try" doesn't cut it.
Are we perfect? No. Can we do better? Absolutely. Should we try to do
better? YES PLEASE. Lets get constructive and try to make things better.
In the past, a few simple things improved the situation, such as
printk'ing the kernel version in the oops, as well as (longer back)
kksymoops. Or think of things like lockdep, or the pagealloc-debug
stuff. Going forward there are things we can do to improve things in the
kernel, even if you don't have hardware. We need to make the kernel
more selfdiagnosing. Detecting the problem, and if it's likely a
driver/hw interaction bug, sticking in a WARN_ON(). That's the sort of
thing even starting kernel developers can do to help improve the
quality even wihtout hardware access, because it helps us improve the
quality of bugreports, and it improves our ability to find patterns and
group duplicates into a top 10.
Adrian, how about working on that sort of thing rather than keep saying
"impossible, we're doomed"... pretty please?
--
