Question about make-kpkg
I know that what I want to do is not really "the Debian Way", but I do not
have an option, so I want to make the best of a bad deal.
I am trying to install Debian onto a Compulab 586BASE which has some
Flash memory built into it. This flash memory is supported by a compulab
supplied driver, part of which is object not source. I want to add this to
a 2.4.21 or 2.4.22 kernel.
As the flash memory will be the / root, I need, eventualy, to build this into
the kernel rather than as a module as I do not want to use initrd.
As supplied the driver comes as a directory with two source .c files, a .h
file, two .o files, and two makefiles, one for building into the kernel and
one as a module. The resulting driver is the combination of the compiled
.c files and the two .o files.
This is all done (in the compulab documentation) in the assumption that it
will be added to a Redhat system.
The procedure is to run the relevant makefile outside the kernel tree,
which builds a file called fdrv.o. This is then copied into the driver/block
directory in the kernel source tree, and the makefile in that directory
modified to include the new .o file. Finally calls to the initialisation code
in the modules is added to ll_rw_blk.c.
I tried this, and for a reason which I have not yet got to the bottom of
the kernel trapped. So I want to make a module instead so that I can
debug the problem before commiting to including it in the kernel.
But make-kpkg kernel_image seems to clean out all the .o files after a build,
so next time around I have a problem. So when I come to build the kernel
I have to copy in the directory each time.
Now I realise that including binaries in the kernel is not the
right thing to do, but short of persuading Compulab that
they really should either release all the source or should
move to using the MTD drivers for their flash, I have no
option. I have by the way tried, and their reaction was that they
had no plans to do either.
It occured to me that perhaps I should rename the .o files to
something that will not get deleted, and then put in a dependancy
to copy them to .o. Is this the right way to proceed, or can
anyone think of a better way to do this.
Thanks in advance,
David
Reply to: