Ramoops currently has module parameters for setting the configuration
variables (ram start, ram size and dump oopses). This makes it difficult to
configure when the module is compiled as a builtin.
This patch adds the following 3 configuration options which set the same
variables as the module parameters:
1. RAMOOPS_RAM_START
2. RAMOOPS_RAM_SIZE
3. RAMOOPS_RAM_DUMP_OOPS
Module parameters take precedence over configuration parameters.
Signed-off-by: Sergiu Iordache <[email protected]>
---
drivers/char/Kconfig | 36 ++++++++++++++++++++++++++++++++++++
drivers/char/ramoops.c | 6 +++---
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 49502bc..0284f9f 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -608,6 +608,42 @@ config RAMOOPS
This enables panic and oops messages to be logged to a circular
buffer in RAM where it can be read back at some later point.
+config RAMOOPS_RAM_START
+ hex "Ramoops physical start address"
+ depends on RAMOOPS
+ default "0"
+ ---help---
+ Start address of the memory area that is used by Ramoops.
+
+ For this feature to be useful, the selected memory area must be
+ preserved across reboot, so not used by the boot loader, for example.
+
+ Module parameter takes precedence over this.
+
+config RAMOOPS_RAM_SIZE
+ hex "Ramoops used RAM size"
+ depends on RAMOOPS
+ default "0"
+ ---help---
+ Size of the memory area that is used by Ramoops.
+
+ For this feature to be useful, the selected memory area must be
+ preserved across reboot, so not used by the boot loader, for example.
+
+ Module parameter takes precedence over this.
+
+config RAMOOPS_DUMP_OOPS
+ int "Dump oopses or only panics"
+ depends on RAMOOPS
+ default "1"
+ help
+ Flag to determine what gets dumped to RAM.
+
+ If set to 1 then both oopses and panics are dumped to RAM.
+ If set to 0 only kernel panics get dumped to RAM.
+
+ Module parameter takes precedence over this.
+
config MSM_SMD_PKT
bool "Enable device interface for some SMD packet ports"
default n
diff --git a/drivers/char/ramoops.c b/drivers/char/ramoops.c
index 1a9f5f6..31b2c30 100644
--- a/drivers/char/ramoops.c
+++ b/drivers/char/ramoops.c
@@ -32,17 +32,17 @@
#define RECORD_SIZE 4096UL
-static ulong mem_address;
+static ulong mem_address = CONFIG_RAMOOPS_RAM_START;
module_param(mem_address, ulong, 0400);
MODULE_PARM_DESC(mem_address,
"start of reserved RAM used to store oops/panic logs");
-static ulong mem_size;
+static ulong mem_size = CONFIG_RAMOOPS_RAM_SIZE;
module_param(mem_size, ulong, 0400);
MODULE_PARM_DESC(mem_size,
"size of reserved RAM used to store oops/panic logs");
-static int dump_oops = 1;
+static int dump_oops = CONFIG_RAMOOPS_DUMP_OOPS;
module_param(dump_oops, int, 0600);
MODULE_PARM_DESC(dump_oops,
"set to 1 to dump oopses, 0 to only dump panics (default 1)");
--
1.7.2.3
Hi,
Il 23/06/2011 20:36, Sergiu Iordache ha scritto:
> Ramoops currently has module parameters for setting the configuration
> variables (ram start, ram size and dump oopses). This makes it difficult to
> configure when the module is compiled as a builtin.
>
isn't it enough to set them via command line?
Marco
On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
> Ramoops currently has module parameters for setting the configuration
> variables (ram start, ram size and dump oopses). This makes it difficult to
> configure when the module is compiled as a builtin.
Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
to your kernel cmdline?
On Thu, Jun 23, 2011 at 12:59 PM, <[email protected]> wrote:
> On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
> > Ramoops currently has module parameters for setting the configuration
> > variables (ram start, ram size and dump oopses). This makes it difficult to
> > configure when the module is compiled as a builtin.
>
> Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
> to your kernel cmdline?
You can but the problem is that when you're using the module as a
builtin managing the command line is harder than managing Kconfig
files. Instead of having different platform dependent config files
(which already exist in most of the cases) under source control you
would have to have different scripts which run the kernel with
different parameters.
Sergiu
On Thu, Jun 23, 2011 at 01:43:49PM -0700, Sergiu Iordache wrote:
> On Thu, Jun 23, 2011 at 12:59 PM, <[email protected]> wrote:
> > On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
> > > Ramoops currently has module parameters for setting the configuration
> > > variables (ram start, ram size and dump oopses). This makes it difficult to
> > > configure when the module is compiled as a builtin.
> >
> > Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
> > to your kernel cmdline?
>
> You can but the problem is that when you're using the module as a
> builtin managing the command line is harder than managing Kconfig
> files. Instead of having different platform dependent config files
> (which already exist in most of the cases) under source control you
> would have to have different scripts which run the kernel with
> different parameters.
Then why not make the sysfs files writable?
Stuff like this should not be picked from the configuration build if at
all possible. The fact that you feel changing the Kconfig is easier
than your boot command line shows a problem in your overall system
configuration.
greg k-h
On Thu, Jun 23, 2011 at 2:33 PM, Greg KH <[email protected]> wrote:
> On Thu, Jun 23, 2011 at 01:43:49PM -0700, Sergiu Iordache wrote:
>> On Thu, Jun 23, 2011 at 12:59 PM, <[email protected]> wrote:
>> > On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
>> > > Ramoops currently has module parameters for setting the configuration
>> > > variables (ram start, ram size and dump oopses). This makes it difficult to
>> > > configure when the module is compiled as a builtin.
>> >
>> > Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
>> > to your kernel cmdline?
>>
>> You can but the problem is that when you're using the module as a
>> builtin managing the command line is harder than managing Kconfig
>> files. Instead of having different platform dependent config files
>> (which already exist in most of the cases) under source control you
>> would have to have different scripts which run the kernel with
>> different parameters.
>
> Then why not make the sysfs files writable?
>
We do use sysctl and sysfs for most of our tuning stuff.
But in this case, you wouldn't be able to write the sysfs file until
late in boot
so an early crashed would be lost.
Our command-line is pretty generic across targets. Even across archs.
> Stuff like this should not be picked from the configuration build if at
> all possible. ?The fact that you feel changing the Kconfig is easier
> than your boot command line shows a problem in your overall system
> configuration.
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
2011/6/24 Mandeep Singh Baines <[email protected]>:
> On Thu, Jun 23, 2011 at 2:33 PM, Greg KH <[email protected]> wrote:
>> On Thu, Jun 23, 2011 at 01:43:49PM -0700, Sergiu Iordache wrote:
>>> On Thu, Jun 23, 2011 at 12:59 PM, <[email protected]> wrote:
>>> > On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
>>> > > Ramoops currently has module parameters for setting the configuration
>>> > > variables (ram start, ram size and dump oopses). This makes it difficult to
>>> > > configure when the module is compiled as a builtin.
>>> >
>>> > Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
>>> > to your kernel cmdline?
>>>
>>> You can but the problem is that when you're using the module as a
>>> builtin managing the command line is harder than managing Kconfig
>>> files. Instead of having different platform dependent config files
>>> (which already exist in most of the cases) under source control you
>>> would have to have different scripts which run the kernel with
>>> different parameters.
>>
>> Then why not make the sysfs files writable?
>>
>
> We do use sysctl and sysfs for most of our tuning stuff.
>
> But in this case, you wouldn't be able to write the sysfs file until
> late in boot
> so an early crashed would be lost.
>
> Our command-line is pretty generic across targets. Even across archs.
>
Maybe using platform data? With archs with device tree support can be easy.
Marco
Marco Stornelli ([email protected]) wrote:
> 2011/6/24 Mandeep Singh Baines <[email protected]>:
> > On Thu, Jun 23, 2011 at 2:33 PM, Greg KH <[email protected]> wrote:
> >> On Thu, Jun 23, 2011 at 01:43:49PM -0700, Sergiu Iordache wrote:
> >>> On Thu, Jun 23, 2011 at 12:59 PM, <[email protected]> wrote:
> >>> > On Thu, 23 Jun 2011 11:36:00 PDT, Sergiu Iordache said:
> >>> > > Ramoops currently has module parameters for setting the configuration
> >>> > > variables (ram start, ram size and dump oopses). This makes it difficult to
> >>> > > configure when the module is compiled as a builtin.
> >>> >
> >>> > Can't you add 'ramoops.ram_start=128M ramoops.ram_size=64M' or similar
> >>> > to your kernel cmdline?
> >>>
> >>> You can but the problem is that when you're using the module as a
> >>> builtin managing the command line is harder than managing Kconfig
> >>> files. Instead of having different platform dependent config files
> >>> (which already exist in most of the cases) under source control you
> >>> would have to have different scripts which run the kernel with
> >>> different parameters.
> >>
> >> Then why not make the sysfs files writable?
> >>
> >
> > We do use sysctl and sysfs for most of our tuning stuff.
> >
> > But in this case, you wouldn't be able to write the sysfs file until
> > late in boot
> > so an early crashed would be lost.
> >
> > Our command-line is pretty generic across targets. Even across archs.
> >
>
> Maybe using platform data? With archs with device tree support can be easy.
>
FDT is a good idea. Thanks.
I guess for x86, we could add a file to drivers/platform/x86 to register
a device.
> Marco