I'm a user, and I request that LKCD get merged into the kernel. :-)
On Thu, Oct 31, 2002 at 07:46:08AM -0800, Linus Torvalds wrote:
> What I'm saying by "vendor driven" is that it has no relevance for the
> standard kernel, and since it has no relevance to that, then I have no
> incentives to merge it. The crash dump is only useful with people who
> actively look at the dumps, and I don't know _anybody_ outside of the
> specialized vendors you mention who actually do that.
I actively look at LKCD dumps. I have no affiliation with SGI, IBM, or any
of the previously mentioned companies. I'm not aware of any vendors providing
pre-patched kernels with LKCD; right now my only option for reasonable crash
data is to patch and build my own kernel.
> I will merge it when there are real users who want it - usually as a
> result of having gotten used to it through a vendor who supports it. (And
> by "support" I do not mean "maintain the patches", but "actively uses it"
> to work out the users problems or whatever).
Here at Purdue University we're building several Linux clusters. LKCD is
most useful to help find in-kernel problems. Most of the time our crashes
are due to a flakey stick of RAM or a dying disk (or controller), but LKCD
dumps are still useful. With a crash dump I can analyze the cause of the
crash after the fact, but without a dump my only option to get _any_ crash
data is to leave a console plugged into each node of my clusters.
Do you feel like donating a 700-port console server? Right, so it's LKCD
for me then.
> People have to realize that my kernel is not for random new features. The
> stuff I consider important are things that people use on their own, or
> stuff that is the base for other work. Quite often I want vendors to merge
> patches _they_ care about long long before I will merge them (examples of
> this are quite common, things like reiserfs and ext3 etc).
>
> THAT is what I mean by vendor-driven. If vendors decide they really want
> the patches, and I actually start seeing noises on linux-kernel or getting
> requests for it being merged from _users_ rather than developers, then
> that means that the vendor is on to something.
I understand that Linux can't have random new features (especially going into
a feature-freeze). However, any additions that provide better debugging info
are (in my opinion, at any rate) worth it. Every other UNIX I've used (with
the possible exception of an early Ultrix) has some facility to inspect the
kernel - all have _at_least_ dumps that get written to a swap disk on a crash
and many have an in-core debugger. Running gdb on a live kernel from a
remote machine isn't unheard of, at least with other OSes. Unfortunately,
only aid you'll get in debugging a Linux kernel is the source code. Sure,
you can add a mess of printk's all over suspect code, and yes, the console
gets a register dump on a panic, but that really isn't enough. Some times
it's nice to be able to walk through the kernel's data structures and figure
out just what was going on when things died. I get this with LKCD.
To that end, it'd be nice if the trace toolkit and SGI's kernel debugger were
added. No, I haven't used them, but then I don't do much kernel development
either. I'd bet that LTT and the kernel debugger would be very useful to
those who do, though.
-- Mike Shuey - 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/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:55 EST