> -----Original Message----- > From: Aravinda Prasad [mailto:aravinda at linux.vnet.ibm.com] > Sent: Friday, December 07, 2012 1:05 AM > To: Dave Anderson > Cc: ananth at in.ibm.com; mahesh at linux.vnet.ibm.com; > kexec at lists.infradead.org; Luc Chouinard; tachibana at mxm.nes.nec.co.jp; > Atsushi Kumagai; Vivek Goyal; buendgen at de.ibm.com > Subject: Re: [PATCH v2 0/7] makedumpfile security key filtering with eppic > > > > On 2012-12-06 20:56, Dave Anderson wrote: > > > > > > > ----- 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? > > > This is what I am planning. > > A new extension_eppic.c file will be created under makedumpfile source > directory. This file is equivalent to applications/crash/eppic.c in upstream eppic > repository. A new target will be added to the Makefile of makedumpfile to build > the shared library and to build this shared library libeppic.a would be required. > The makedumpfile specific shared library will be named different - say > eppic_mkdumpfile.so to avoid conflict with crash specific libeppic.so. > > The reason for including extension_eppic.c under makedumpfile source is > because it will be dependent on other functions in makedumpfile code like dwarf > related calls etc. People modifying those functions should be aware of the > callers in extension_eppic.c and if this is included in upstream eppic code, it will > be easily overlooked (or may not be aware of its existence). The same reasons exists for applications/crash/eppic.c. It only ended up on eppic's git for two reasons. To provide for a complete example of integration into a tool and, because I originally wrote it, I could support it from there without having to send a patch Dave's way. I expect other applications to own their glue/integration file(s) and only grab libeppic from the git. These applications, will comply to libeppic's APIs and only fixes or new functions will be added to libeppic to support these applications and valid new requirements they may have. Like we did for mkdumpfile. Same libeppic.so and same libeppic Makefile for all. > > A flag --eppic will be added to makedumpfile which will dlopen the shared > library. Few additional helper functions will be added to dwarf_info.c and > erase_info.c - the same functions which are in v2 of the patchset. > > > > > > Dave > > > > > > _______________________________________________ > > kexec mailing list > > kexec at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/kexec > > > > > -- > Regards, > Aravinda
