There are so many ways to feed configuration parameters into the
kernel these days.
There is sysctl. There is sysfs. And there are module paramters.
(procfs? who said procfs? I certainly didn't).
I have a module - let's call it 'lockd'.
I want to make it configurable - say to be able to identify
peers by IP address (as it currently does) or host name
(good for multi homed peers, if you trust them).
And I want Jo Sysadmin to be able to set some simple configuration
setting somewhere and have it 'just work'.
Options:
- I could make it a module parameter: use_hostnames, and tell
Jo to put
options lockd use_hostnames=yes
in /etc/modprobe.d/lockd if that is what (s)he wants.
But that won't work if the module is compiled in (will it?).
- I could make a sysctl /proc/sys/fs/nfs/nsm_use_hostnames
at tell Jo to put
fs.nfs.nsm_use_hostnames=1
if /etc/sysctl.conf if desired.
But that wouldn't work if lockd is a module that is loaded
after "/usr/sbin/sysctl -p" has been run.
- I could do both and tell Jo to make both changes, just in case,
but that is rather ugly, though that is what we currently do
for nlm_udpport, nlm_tcpport, nlm_timeout, nlm_grace_period.
It occurs to me that since we have /sys/module/X/parameters,
it wouldn't be too hard to have some functionality, possibly
in modprobe, that looked for all the 'options' lines in
modprobe config files, checked to see if the modules was loaded,
and then imposed those options that could be imposed.
Thus we could just have a module option, just add module config
information to /etc/modprobe.d and run
modprobe --apply-option-to-active-modules
at the same time as "sysctl -p" and it would all 'just work'
whether the module were compiled in to not.
Is that a reasonable idea?
(I'll probably add both a sysctl and a mod param for my current
problem, but I'd love it if there were a better approach
possible in the future).
Thanks,
NeilBrown
On Fri, Sep 01, 2006 at 12:02:52PM +1000, Neil Brown wrote:
>
> There are so many ways to feed configuration parameters into the
> kernel these days.
> There is sysctl. There is sysfs. And there are module paramters.
> (procfs? who said procfs? I certainly didn't).
>
> I have a module - let's call it 'lockd'.
> I want to make it configurable - say to be able to identify
> peers by IP address (as it currently does) or host name
> (good for multi homed peers, if you trust them).
>
> And I want Jo Sysadmin to be able to set some simple configuration
> setting somewhere and have it 'just work'.
>
> Options:
> - I could make it a module parameter: use_hostnames, and tell
> Jo to put
> options lockd use_hostnames=yes
> in /etc/modprobe.d/lockd if that is what (s)he wants.
> But that won't work if the module is compiled in (will it?).
Yes it will. See Documentation/kernel-parameters.txt for how it works.
> - I could make a sysctl /proc/sys/fs/nfs/nsm_use_hostnames
> at tell Jo to put
> fs.nfs.nsm_use_hostnames=1
> if /etc/sysctl.conf if desired.
> But that wouldn't work if lockd is a module that is loaded
> after "/usr/sbin/sysctl -p" has been run.
>
> - I could do both and tell Jo to make both changes, just in case,
> but that is rather ugly, though that is what we currently do
> for nlm_udpport, nlm_tcpport, nlm_timeout, nlm_grace_period.
>
> It occurs to me that since we have /sys/module/X/parameters,
> it wouldn't be too hard to have some functionality, possibly
> in modprobe, that looked for all the 'options' lines in
> modprobe config files, checked to see if the modules was loaded,
> and then imposed those options that could be imposed.
those options _are_ module parameters, and as such work just fine with
the modprobe config files.
> Thus we could just have a module option, just add module config
> information to /etc/modprobe.d and run
> modprobe --apply-option-to-active-modules
> at the same time as "sysctl -p" and it would all 'just work'
> whether the module were compiled in to not.
Ah, you want it after the code is loaded. That's different.
Would probably work just fine, no objection from me. Except you would
have to hack up the module-init-tools package :)
thanks,
greg k-h
On 9/1/06, Greg KH <[email protected]> wrote:
> On Fri, Sep 01, 2006 at 12:02:52PM +1000, Neil Brown wrote:
>
> > Thus we could just have a module option, just add module config
> > information to /etc/modprobe.d and run
> > modprobe --apply-option-to-active-modules
> > at the same time as "sysctl -p" and it would all 'just work'
> > whether the module were compiled in to not.
>
> Ah, you want it after the code is loaded. That's different.
>
> Would probably work just fine, no objection from me. Except you would
> have to hack up the module-init-tools package :)
>
This will be pretty hard to implement in general as quite a few module
parameters do not allow changing once set and so you will have to
virtually reload modules while doing your "modprobe --apply.." trick.
--
Dmitry
Neil Brown wrote:
> There are so many ways to feed configuration parameters into the
> kernel these days.
> There is sysctl. There is sysfs. And there are module paramters.
> (procfs? who said procfs? I certainly didn't).
>
> I have a module - let's call it 'lockd'.
> I want to make it configurable - say to be able to identify
> peers by IP address (as it currently does) or host name
> (good for multi homed peers, if you trust them).
>
> And I want Jo Sysadmin to be able to set some simple configuration
> setting somewhere and have it 'just work'.
>
I'm already working on etab (external text and binary) config interface
<http://permalink.gmane.org/gmane.linux.debian.devel.kernel/21781>.
I wish to apply it to firmwares (as for once-loaded, as for multi-loaded). It
can also be used for any type (boot, runtime) of configuration needed for many
kernel parts.
In short: there is a config provider inside kernel -- dictionary, where keys
are names of modules (even in static build), every module knows what it needs,
and thus admin knows how to construct configuration and place in location on
file system, or feed in to etab when needed. Generally, there two userspace
interfaces: bootloader (initrd=) and runtime (chardev /dev/etab). No need in
*fs, modification in module-init-tools, just a dictionary in kernel.
Sorry for my English, and say it's stupid if it is.
Thanks.
--
-o--=O`C /. .\ (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)
Greg KH wrote:
> On Fri, Sep 01, 2006 at 12:02:52PM +1000, Neil Brown wrote:
>>
>> - I could make it a module parameter: use_hostnames, and tell
>> Jo to put
>> options lockd use_hostnames=yes
>> in /etc/modprobe.d/lockd if that is what (s)he wants.
>> But that won't work if the module is compiled in (will it?).
>
> Yes it will. See Documentation/kernel-parameters.txt for how it works.
>
I must be blind today but I failed to find anything about this in mentioned
file. Nor do I see how it can possibly work. Could you please elaborate a
bit?
thank you
-andrey
On Fri, Sep 01, 2006 at 07:57:12PM +0400, Andrey Borzenkov wrote:
> Greg KH wrote:
>
> > On Fri, Sep 01, 2006 at 12:02:52PM +1000, Neil Brown wrote:
> >>
> >> - I could make it a module parameter: use_hostnames, and tell
> >> Jo to put
> >> options lockd use_hostnames=yes
> >> in /etc/modprobe.d/lockd if that is what (s)he wants.
> >> But that won't work if the module is compiled in (will it?).
> >
> > Yes it will. See Documentation/kernel-parameters.txt for how it works.
> >
>
> I must be blind today but I failed to find anything about this in mentioned
> file. Nor do I see how it can possibly work. Could you please elaborate a
> bit?
Well, it doesn't work for reading the info from the module parameter
files, sorry, it was a bit late when I wrote that. What I ment to say
is that the parameter can be set from the kernel command line at boot
time, if the module is built into the kernel.
Sorry for the confusion,
greg k-h
Neil Brown <[email protected]> wrote:
> There are so many ways to feed configuration parameters into the
> kernel these days.
;-)
> There is sysctl. There is sysfs. And there are module paramters.
> (procfs? who said procfs? I certainly didn't).
And kernel parameters.
> I have a module - let's call it 'lockd'.
> I want to make it configurable - say to be able to identify
> peers by IP address (as it currently does) or host name
> (good for multi homed peers, if you trust them).
[...]
> It occurs to me that since we have /sys/module/X/parameters,
> it wouldn't be too hard to have some functionality, possibly
> in modprobe, that looked for all the 'options' lines in
> modprobe config files, checked to see if the modules was loaded,
> and then imposed those options that could be imposed.
>
> Thus we could just have a module option, just add module config
> information to /etc/modprobe.d and run
> modprobe --apply-option-to-active-modules
> at the same time as "sysctl -p" and it would all 'just work'
> whether the module were compiled in to not.
No, please. Not across the board. That will screw up hand-tuned parameters
And in any case, make sysctl do it (it should not matter if it is module
configuration or built-in configuration, just for consistency).
[I seem to remember a similar thread perhaps one month back?]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
--
VGER BF report: U 0.5