lkml.org 
[lkml]   [2007]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Determine version of kernel that produced vmcore
    On Wed, Jul 11, 2007 at 10:43:04PM +0900, Ken'ichi Ohmichi wrote:
    >
    > Hi Dan,
    >
    > 2007/07/11 10:32:16 +0300, Dan Aloni <da-x@monatomic.org> wrote:
    > >> This implementation looks interesting. No need of debug compiled
    > >> vmlinux for dump filtering purposes. No run time vmlinux binary modifications
    > >> as suggested by your previous mails. People can export kernel CONFIG info
    > >> like PAGESIZE etc with the help of this ELF note and any tool which is
    > >> processing kernel core file can benifit from this. No guesses required for
    > >> determining the page size of crashed kernel.
    > >>
    > >> All the info required by dump filtering tool, put it into an ELF note,
    > >> pass it to second kernel which appends it to final vmcore. The only concern
    > >> here again is that type of ELF note is not standard. The contents of
    > >> ELF notes will keep on changing over a period of time. For example if a
    > >> new memory model evolves. Now everytime this note data changes one shall
    > >> have to update mkdumpfile and user shall have to newer version. If there
    > >> are any issues, user will not come to know about the issue during kdump
    > >> service enablement time, instead it will be detected during dump
    > >> capture time. It is too late till then.
    > >
    > >I guess that dump filtering will needed to be tested at least once
    > >under various platforms for every major release of the kernel to see
    > >if the information exported by the kernel through this elf note is
    > >still sufficient.
    > >
    > >Adding more info to this elf note as needed can be done through a simple
    > >patch to the kernel and it can be tested along with mkdumpfile changes
    > >even before a major version gets released.
    >
    > As Vivek said, I think it is not a good idea that both kernel's code and
    > makedumpfile's code should be changed when makedumpfile needs more debug
    > information (ex. To extend the supported CPU architectures. To fix some
    > machine-specific problems, etc.).
    > Also it is difficult to change the list of necessary items in kernel,
    > because we should be careful about CPU architecture, linux version, and
    > memory model. makedumpfile needs the following items, and those existence
    > depends on CPU architecture, linux version, and memory model. If we don't
    > be careful about them, the kernel building may fail.
    > I think it is not a good idea that each items are defined by ifdef, it
    > is too complex.
    >

    Hi Ken'ichi,

    This approach seems to have advantages also. For example, now one will not
    require a kernel debuginfo file to configure kdump with dump filtering.
    I think having to have a debug info file is a big restriction.

    Now vmcore ELF note contain all the data rquired to filter core dump and
    there will be no need to parse DWARF debuginfo and makedumpfile code will be
    smaller and simpler.

    Given the fact that more and more architectures are supporting multiple
    page sizes. Now one can also export relevant kernel CONFIG variables
    through this ELF note. makedumpfile's job will be simpler. You don't have
    to make any guesses about various config options like page size.

    This approach will make second kernel truly independent of first kernel.
    Currently, if first kernel changes one shall have to regenerate the
    initrd for second kenrel. Hence in a sense, second kernel is dependent on
    first kernel. Now kernel will export all the required data for dump filtering
    so one does not have to rebuild the seond kernel initrd even if first kernel
    changes.

    I think overall the approach of exporting right info from kernel should
    help. Only thing is that we shall have to manage the ELF note better in
    terms of making it more generic.

    Thanks
    Vivek
    -
    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/

    \
     
     \ /
      Last update: 2007-07-13 06:01    [W:2.821 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site