regarding module parameters and __initdata, i did some experimenting
to clarify this in my own mind, and here's what i found. if someone
else can confirm this, that would be just ducky.
here's a basic module we can work with, in tst.c:
========================================
#include <linux/module.h>
#include <linux/moduleparam.h>
static int p = 42 ;
module_param(p, uint, 0644);
static int __init hi(void)
{
printk(KERN_INFO "Hello from tst.\n");
printk(KERN_INFO "p = %d.\n", p);
return 0;
}
static void __exit bye(void)
{
printk(KERN_INFO "Goodbye from tst.\n");
}
module_init(hi);
module_exit(bye);
=========================================
as i see it, there are two flavours of module parameters:
1) those that are used only during module initialization, after which
they can be thrown away (ie., __initdata) 2) those that need to hang
around for the entire time that the module is loaded
in the above module, the lifetime of parameter p will be for as long
as the module is loaded, and it can be viewed while the module is
loaded with:
$ cat /sys/module/tst/parameters/p
42
$
if you *don't* want a module parameter to show up under the
/sys/module directory, just change its permission setting:
module_param(p, uint, 0);
now that module won't be viewable, but it will still have a lifetime
of as long as the module is loaded. however, if you don't allow
userspace access to a parameter, and you have no further need of it
after the module is loaded, you might as well tag it as __initdata so
it's thrown away after loading and you don't waste space:
static int __initdata p = 42 ;
module_param(p, uint, 0);
and as for one final variation, the following would be a really bad
idea:
static int __initdata p = 42 ;
module_param(p, uint, 0644);
that's a bad combination since you're saying that the parameter is
__initdata so it will be deleted after module loading, and yet you're
asking that it show up under /sys/module after loading. in fact, that
combination will compile and load, but if you try to view the contents
of that parameter, bad things will happen (probably segmentation
/kernel panic). trust me on this one. i tried it.
in short, if you're *absolutely sure* that you have no need for a
module parameter after loading, you can free up a bit of space by
setting its perms as 0 and tagging it as __initdata. which leads us
to wonder how many parameters currently could be tagged as __initdata
to save space.
here's an example i was curious about: drivers/scsi/gdth.c, which
contains the following snippets:
...
/* parameters for modprobe/insmod */
module_param_array(irq, int, NULL, 0);
module_param(disable, int, 0);
module_param(reserve_mode, int, 0);
module_param_array(reserve_list, int, NULL, 0);
module_param(reverse_scan, int, 0);
module_param(hdr_channel, int, 0);
module_param(max_ids, int, 0);
module_param(rescan, int, 0);
module_param(shared_access, int, 0);
module_param(probe_eisa_isa, int, 0);
module_param(force_dma32, int, 0);
...
so ... loads of non-displayable parameters. and how many are tagged
as __initdata?
static int disable __initdata = 0;
that's it. so what about the rest of them? even if they're not
displayed, they might still need to hang around for the lifetime of
the module. or do they?
consider, say, the parameter reserve_mode. first, since it's
"static", it can't be accessed from outside of this source file.
second, the only references to it in that source file are (apparently)
from within routines that are tagged as __init, so *those* routines
will be discarded after loading.
in other words, from what i can tell, the parameter reserve_mode
might as well be tagged as __initdata as well. and a bunch of others,
too.
does all this logic make sense? because it suggests that there's
probably a truckload of driver module parameters throughout the tree
that could be tagged with __initdata to save some space.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
