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

[Aravinda Prasad]

On 2012-12-08 03:29, Vivek Goyal wrote:

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


Consider this simple eppic macro, which prints the value of the global
kernel variable "modules":

smod()
{
	struct list_head *mod;

	mod = (struct list_head *)modules;
	printf("Modules = %p \n", mod);
}

Eppic has logic to interpret this C program, but needs some help in
resolving the actual value of "modules" (as well as members of struct
list_head) and defines few call-back functions to help it. This generic
logic forms libeppic.a. The glue logic implements these call back
function to help libeppic.a.

Eg: whenever libeppic.a encounters struct list_head, it calls
apimember("list_head") call back function to learn about the details of
the members of the structure. Glue logic implement this call-back
function and calls libeppic.a calls with information -
eppic_member_sname("list_head", "next"), eppic_member_sname("list_head",
"prev") etc., inside apimember("list_head").

In crash, the glue logic contains gdb related calls and in makedumpfile
it contains dwarf related calls to get the structure members, value of
global variables etc. However, libeppic.a does not care what calls we
use in the background. It just needs the data. This makes it very
generic and powerful.

Now the glue logic along with libeppic.a makes the shared library *.so
(named eppic.so for crash, planning to name eppic_makedumpfile.so for
makedumpfile), which applications can dlopen().

Hope this helps.

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


Glue logic is 450K lines of code (all of them in extension_eppic.c) and
calls lot of eppic library calls, making this glue logic static requires
libeppic.a to be statically included, which was our first approach.


> Thanks
> Vivek
> 


-- 
Regards,
Aravinda