> Masashige Kotani wrote:
> > Hello.
> > I am a Jyunji's co-worker too.
> > I am making a new command for module support of lkcd as in the above
> Hi, Masashige-san. I have no problems including this into the tree,
> as long as it isn't conflicting with Andreas' work, and it can be
> packaged nicely together. The conflict issue is just to make sure
> multiple LKCD developers are working on the same page. I'm all for
> the right thing going into the code base regardless, I just don't
> want to see conflicts in the way the work is completed.
lkcd_ksyms and symtab subcommand has the overlapped function (use the nm
command), and it becomes unnecessary to use symtab.
I think debugging that will becomes easy, if it uses with lkcd_ksyms
reproducing the module command and /proc/ksyms reproducing /proc/modules.
> The other thing I need to know is that you
> are releasing this code under the GPL. Your copyright is included,
> which is fine, but I need to know that this code is GPL'd before
> I can include it into the LKCD source tree.
There is no probrem to apply GPL to this code.
> Also, can I call this 'lkcd_ksyms'? I'd like to use that name instead
> of lcd_ksyms, for consistency with the package name.
I agree entirely. Please call it 'lkcd_ksyms'.
> Otherwise, I can include this into the tree tonight.
> BTW, I'm almost done with the next revision of the patch (3.2), which
> has the dump_silence_system()/dump_resume_system(), changes to include
> gzip support, and a matching lkcdutils-3.2. I'm going to bump up the
> revision of lkcdutils to match that of the kernel patch. That way we
> have some more consistency with what is compatible with what.
> There are some big changes going into LKCD 3.2 to change tunable names,
> to allow for expandability for future enhancements.
> Are people reviewing the source tree? If so, I'll check my intermediate
> changes in for now so people can review them.