RFC: crash extension module handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Lucio's post of his latest Cell/B.E. SPU commands extension module:

  https://www.redhat.com/archives/crash-utility/2007-September/msg00041.html

leads to a larger discussion of how extension modules should best
be handled.

In Lucio's patch, he modified the top-level Makefile and the extensions
subdirectory Makefile to build his extension module, following the
directions in the extensions/Makefile file itself, which states:

# To add a new extension object:
#
#  - add the new source file to the EXTENSION_SOURCE_FILES list
#    in the top-level Makefile
#  - add the object file name to the EXTENSION_OBJECT_FILES list
#    in the top-level Makefile
#  - create a compile stanza below, typically using "echo.so" as
#    a base template.

Now, currently in the extensions subdirectory are two extension modules,
echo.c and dminfo.c, and there are explicit compile lines for the two
of them, which are identical in nature:

echo.so: ../defs.h echo.c
        gcc -nostartfiles -shared -rdynamic -o echo.so echo.c -fPIC \
                                                -D$(TARGET) $(TARGET_CFLAGS)
dminfo.so: ../defs.h dminfo.c
        gcc -nostartfiles -shared -rdynamic -o dminfo.so dminfo.c -fPIC \
                                                -D$(TARGET) $(TARGET_CFLAGS)

and in Lucio's patch, he follows the template:

+spu.so: ../defs.h spu.c
+	gcc -nostartfiles -shared -rdynamic -o spu.so spu.c -fPIC \
+						-D$(TARGET) $(TARGET_CFLAGS)

That's all well and good, but I've decided that I really don't
want the crash source package to be a placeholder of this, and
numerous other, extension module source files.

My feeling is that the crash package should only have to deal with
the *mechanism* of handling dynamic extension modules, and not
the modules' source code itself.

A little history first...

The "echo.c" extension module is simply a template from which
a new module can be created.  The "dminfo.c" extension module
is a special-case Red Hat extension module, created as an alternative
to the device-mapper guys from having to write their own utility
that would do the same kind of kernel-memory grok'ing that crash
does.  To be honest, I'd prefer it if it were not there in the
crash source tree, but there was no acceptable alternative at the
time.

Furthermore, since that dminfo.c module was added, the crash src.rpm now
creates an additional "crash-devel" rpm, which consists of just
the defs.h file, which is the only thing needed for building an
extension module, and which is installed in /usr/include/crash/defs.h.
So, for example, the systemtap folks have their own crash extension
module package that they control on their own.  They can simply
install the crash-devel package -- without having to install the
crash source package -- and with their own package Makefile, they
compile their stap module, basically doing their own thing "elsewhere".
Had that been in place at the time, the dminfo guys could have
done the same type of thing.

That being said, it is still convenient for many to be able to
do the module building from within a crash source tree's extensions
subdirectory.  Now, given that extension modules should be
compile'able in precisely the same manner as echo.c and dminfo.c,
what I'd like to do is simply have the "make extensions" command
from the top-level Makefile cause the extensions/Makefile to pick
up *any* C file in the extensions subdirectory, and compile a module
automatically -- without having to modify the top-level Makefile or
extensions/Makefile.

In other words, just throw your module's C file into the extensions
subdirectory, enter "make extensions" from the top-level, and it gets
build automatically.  No changes required for the top-level Makefile,
no changes required for the extensions/Makefile, nor any need to store
a myriad of extension modules in the crash source tree.  BTW, I'm perfectly
willing to add an "extensions" repository accessible from my people page,
where contributors can store their latest-and-greatest.

Anyway, I've been tinkering with the extensions/Makefile to do such
a thing, and have a crude addition that does just that, although
it does the compile of all "new" C files every time whether they
need it or not -- via the additional "contrib" target:

30c30
< all: link_defs $(OBJECTS)
---
> all: link_defs $(OBJECTS) contrib
43a44,50
> contrib:
> @for CFILE in `/bin/ls *.c | grep -v echo.c | grep -v dminfo.c | grep -v sial.c`; do \
> 	   OUTPUT=`echo $$CFILE | cut -d. -f1`.so; \
> echo "gcc -nostartfiles -shared -rdynamic -o $$OUTPUT $$CFILE -fPIC -D$(TARGET) $(TARGET_CFLAGS)"; \ > gcc -nostartfiles -shared -rdynamic -o $$OUTPUT $$CFILE -fPIC -D$(TARGET) $(TARGET_CFLAGS); \
>         done
>

It prevents the re-compilation of echo.c and dminfo.c, and of Luc
Chouinard's upcoming sial.c extension module.  (SIAL is an alternative
crash extension mechanism -- more on that when it's available...)

Anyway, I've tried screwing around with the Makefile to use a generic
*.so target, using $@, $(basename ...) and so on, but I'm not a Makefile
master, and I cannot quite get it quite right, although I'm sure it can
be done.

So if anybody out there can do it cleaner than the "contrib" target above,
I'd like to take a look.

Thanks,
  Dave



--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux