On 2012-12-10 13:02, Aravinda Prasad wrote:
>
>
> 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
Correction: it is just 450 lines of code not 450K !!
> 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
