Messages in this thread | | | Date | Fri, 24 Jun 2011 10:06:22 -0700 | From | Mandeep Singh Baines <> | Subject | Re: [PATCH] char drivers: Ram oops kernel configuration parameters |
| |
Marco Stornelli (marco.stornelli@gmail.com) wrote: > 2011/6/24 Mandeep Singh Baines <msb@chromium.org>: > > On Thu, Jun 23, 2011 at 2:33 PM, Greg KH <gregkh@suse.de> wrote: > >> On Thu, Jun 23, 2011 at 01:43:49PM -0700, Sergiu Iordache wrote: > >>> On Thu, Jun 23, 2011 at 12:59 PM, <Valdis.Kletnieks@vt.edu> 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
| |