Re: [PATCH v1 3/3] param: allow to selectively enable /sys/module/MOD/paramaters nodes

[Rusty Russell]

Hi David,

        I'm having real trouble parsing your descriptions.  I found it
easier to read the patches, and that'd not good.

On Wed, 26 Oct 2011 19:22:27 -0700, David Decotigny <david.decotigny@xxxxxxxxxx> wrote:
> This change defines CONFIG_SYSFS_MODULE_PARAM to prevent kernel module
> parameters from being exposed to user. When unset, /sys/module/MOD is
> populated as usual, except for the "parameters" sub-directory, which
> is not created anymore.

That's backwards.  CONFIG_SYSFS_MODULE_PARAM *enables*
/sys/module/<modname>/parameters, this implies it disables it.  Sure, it
allows it to be disabled without disabling all of CONFIG_SYSFS.

> Context: by default, when the module_param() attribute perm == 0, the
> module attribute is not exposed to user in
> /sys/module/*/parameters. Many module implementations use this
> strategy, presumably to spare some memory.

No, they use it because that was the default when I transferred them all
from the older module parameter system.  It was the safe choice.

> However, it can be
> interesting to retrieve how kernel modules are configured at run-time
> (debug, audit, etc.): it would be nice to see more modules have perm
> != 0 in order to expose their configuration pararemers to
> user.

But this patch doesn't address any of that.

> Unfortunately, this doesn't play well with memory-constrained
> systems that need sysfs but don't need this level of
> introspection. This change allows to support both use cases.

Do you have any statistics to support your assertion that this has any
significant effect on memory usage?

Your patches seem fine, but your descriptions are not straightforward!

Thanks,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/