----- Original Message ----- > > Another approach is to dynamically load libeppic library - similar way > how crash does it. No major changes will be done to makedumpfile code, > except the addition of --eppic flag. Upon specifying --eppic flag > makedumpfile will dlopen libeppic.so, which will have functionality to > scrub the specified data. This will prevent makedumpfile bloat and will > not affect the size of initramfs as --eppic is only specified during > post processing. The distribution should build and ship libeppic.so and > the procedure for building .so will be similar to what we have in > crash. OK, so based upon the most recent discussion here: Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic http://lists.infradead.org/pipermail/kexec/2012-December/007452.html Aravinda states that he will be posting an update for makedumpfile that will dlopen() a new "libeppic.so" shared object that is built with the libeppic.a library. The upstream eppic git tree contains an "applications/crash" subdirectory that contains the code that creates a crash-utility-specific "eppic.so" file. Accordingly, this new proposal will also require new source file(s) and a build process to create this new makedumpfile-specific "libeppic.so" shared object. Arvinda -- will you be proposing an additional "applications/makedumpfile" subdirectory for the upstream eppic git tree that can be used to create the makedumpfile-specific libeppic.so file? Dave
