James Washer wrote:
>
> I hope these are not too small to bring to your attention.. but here's a
> couple of things I noticed today, after downing lkcd 4
>
> The README.lkcd refers several times to "/sbin/vmdump", however it seems
> that in rev 4, the should now be /sbin/lkcd
I've fixed most of these -- it needs more content, and the FAQ really
requires some major changes. It's now checked in.
> Also, the webpage (http://lkcd.sourceforge.net/) has a link to
> the "Mailing List" which does not work.
The mailing list has not moved yet -- see my previous E-mail in the
announcement. :)
> On a slightly more technical note, installing the kernel patch
> (lkcd-2.4.8-4.0.diff) resulted in a broken arch/i386/config.in (at
> least 'make xconfig' thought it was broken).
>
> The following block was added near the end of the file:
>
> tristate 'Linux Kernel Crash Dump (LKCD) Support' CONFIG_DUMP
> if [ "$CONFIG_DUMP" = "y" ]; then
> dep_bool ' LKCD RLE compression' CONFIG_DUMP_COMPRESS_RLE $CONFIG_DUMP
> elif [ "$CONFIG_DUMP" = "m" ]; then
> dep_tristate ' LKCD RLE compression' CONFIG_DUMP_COMPRESS_RLE $CONFIG_DUMP
> fi
>
> A quick check of Documentation/kbuild/config-language.txt show's no
> "elif" ( this is with a 2.4.8 tree). The workaround was trivial, given
> that I wasn't intending to compile lkcd as a module.
I've corrected this in the source tree. I've changed 'elif' to an
'fi' followed by an 'if', and that seems to do the trick for now.
> Sorry to bring up such silly little things, but I suppose they should get
> fixed.
They're fixed in the CVS tree, and I'll roll a version later this week
when I get back from SNW in Orlando.
> - jim
>
> p.s. If I were to have changes for lkcd in the future, should I submit those
> as a 'patch' file, to this alias, or is there a different/preferred method.
Submit them here -- that's always fine, or if you think you'll be making
a lot of modifications, we should talk to discuss the process (it's
pretty
simple, just to make sure people don't step on each other).
We take lots of patches, and in almost every case, we review them, but
we don't get everything.
Thanks, Jim. :)
--Matt
> --
> James Washer
> IBM Linux Change Team
|