* Mike Snitzer <snitzer@xxxxxxxxx> wrote:
> Yes, especially from someone who lacks the ability to properly configure
> kdump. I'm fairly surprised others are giving you a free pass when you
> keep asserting how broken kdump is with such hollow criticism. I rely
> heavily on kdump and it works quite well (kvm integration was lacking
> but has improved).
hm, you say you rely heavily on kdump ... for what exactly, and how does
it help the upstream Linux kernel?
I see a single fix from you in the whole repository:
ffc41cf: nbd: prevent sock_xmit from attempting to use a NULL socket
... and that single fix is a NULL pointer dereference that ought to have
been quite debuggable from a plain oops alone.
In practice i rarely see bugfixes that were debugged via kdump. Normal
oops based fixes outnumber kdump based fixes by a ratio of 1:100 or worse
- and kdump is readily available these days - just nobody configures it.
For example, in the whole kernel repo there's just 45 commits that mention
'kdump' [excluding those commits that develop kdump itself]:
$ git log --pretty=format:"%h: %s" --no-merges -i --grep="kdump" |
grep -viE 'kdump|kexec|dump|mem' | wc -l
45
Contrast that to the 1954 commits that contain the string 'oops' or
'crash':
$ git log --pretty=format:"%h: %s" --no-merges -i -E --grep="oops|crash" |
wc -l
5900
That's a ratio of 1:131. (and probably optimistic in favor of kdump.)
Note, i dont have any negative feelings towards kdump - some people use it
and enterprise folks with their frozen, immutable kernels love it - it
just has not yet given me a reason to have particularly positive feelings
towards it in the upstream kernel space.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
