[PATCH v2 0/7] makedumpfile security key filtering with eppic

[Vivek Goyal]

On Fri, Dec 07, 2012 at 08:46:33AM -0500, Luc Chouinard wrote:

[..]
> > 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.

I am lost here. Can somebody explain this thing in layman's terms with
simple example. (We have a function foo() in libeppic which makeudmpfile
wants to call. Now what?)

Few questions come to my mind.

- What is glue logic and why do we need application specific glue
  logic to use this library.

- Assuming we need glue logic and assuming it is small enough, will
  it make sense to build statically build glue logic in application
  and build actual libeppic as shared object and do dlopen() on it.

Thanks
Vivek