Keith Owens wrote:
>
> On Wed, 12 Sep 2001 10:39:39 -0700,
> "Matt D. Robinson" <yakker@xxxxxxxxxxxxxx> wrote:
> >None at this time. Go ahead and move it. BTW, if there are variables
> >that will remain static at all times (such as dump_function_ptr), make
> >sure they are declared in one file. If this means moving dump_function_ptr
> >to init/main.c and declaring everything there, or moving them all to
> >kernel/panic.c, that's fine.
>
> It is better to put dump related static variables in their own file
> with a globally unique name and export the variables from that file.
> Patching an existing file is a bad idea, it results in overlapping
> patches for different add on components. Separate files makes for a
> cleaner patch and a cleaner build.
I'm not sure this is easily accomplished, Keith. We currently have
hooks into panic(), die_if_kernel(), setup_kernel(), and inevitably in
other places as well. Creating a new file which contains just dump
variables, do you think that would be accepted into 2.5? I would
think they'd want the file removed and the variables place somewhere
else.
For example, our dump_function_ptr gets assigned in setup_kernel() if
the dump capability is built into the kernel, or assigned if an insmod
takes place.
There's also dump_in_progress, and eventually a bunch of dump device
tables (4.1).
So, you're saying create kernel/dump.c, put the stuff in there, and
just patch kernel/Makefile? You still have to reference all of those
externs in the other files (or at the very least, #include <linux/dump.h>).
--Matt
|