Re: [PATCH] drivers/net/pcmcia: use module_param() instead of MODULE_PARM()

Stelian Pop
2004-11-10T19:52:14Z

On Wed, Nov 10, 2004 at 08:35:05AM -0800, Randy.Dunlap wrote:

> Hi Stelian,

Hi.
>
> Several of these changes expose module parameters to sysfs
> (i.e., have permissions of non-zero value) without need for that IMO.
>
> This came up yesterday on the kernel-janitors mailing list.
> When asked about it, Greg KH replied:

:)

I shouldn't probably discuss Greg's advice, but...
>
> > Can someone please clarify the "official guidelines" for
> > module parameter permissions in sysfs?
>
> "When it makes sense to have it exposed to userspace"
>
> Yeah, it's vague, sorry, but it all depends.
>
> For things that can be changed on the fly, expose it.

... with a write permission. Agreed.

> For things that don't really matter, and no one will ever look them up,
> don't.
>I think the irq stuff is in the "don't" category, as almost no
> one messes with them anymore.

In this case why is this a module parameter at all ? If it doesn't
matter at all then it should get removed from all places.

In fact, I do think that all module parameter should be exposed in
/sys, and that a '0' in module_param() should really mean 0400.

It can be useful to know what parameters have been passed to a module,
and I cannot think of a single case where we want to hide this
information (and no, security doesn't really apply here. If you have
root rights than you can also look into the kernel memory and find
out the value by yourself).

The only questions one should ask himself about a module parameter is
whether:
- it is a R/O or a R/W value (and this is determined by
the code who uses this value, if it is dynamic then let
the parameter be R/W, if it's only used to make assumptions
in the init phase then it must be R/O).

- it can be shown to everybody, or only root should be able
to read the value (0400 vs 0440/0444). I'm not sure this is
really useful since /etc/modprobe.conf is generaly 0644,
but it could be in some cases...

Stelian.
--
Stelian Pop <stelian@popies.net>