All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Stelian Pop <stelian@popies.net>
Cc: Jeff Garzik <jgarzik@pobox.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Dominik Brodowski <linux@dominikbrodowski.de>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] drivers/net/pcmcia: use module_param() instead of MODULE_PARM()
Date: Wed, 10 Nov 2004 11:47:33 -0800	[thread overview]
Message-ID: <41927055.9030306@osdl.org> (raw)
In-Reply-To: <20041110195200.GJ2706@deep-space-9.dsnet>

Stelian Pop wrote:
> 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...

AFAIK, you are free to disagree as long as I or we can also
disagree.  :)

>>>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...

I don't have an argument with most of that, but I am concerned
about how much memory each entry requires and how useful it really
is.  IOW, if I need to know the module parameters for a module,
I can probably find that info somewhere else, like in
/etc/modprobe.conf or a script etc., so why waste memory on it?

But then there's the question of if someone else needs to know
the module parameters that were used, where do they look?
I could say:  same answer as I gave above.
Or you could say:  exposed in /sys.
If memory usage is not an issue, I'll agree.

-- 
~Randy

  reply	other threads:[~2004-11-10 19:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-04 11:27 [PATCH RESEND] pcmcia network drivers cleanup Stelian Pop
2004-11-05  2:25 ` Jeff Garzik
2004-11-05  8:32   ` Stelian Pop
2004-11-10 15:59   ` Stelian Pop
2004-11-10 16:00     ` [PATCH] drivers/net/pcmcia: use module_param() instead of MODULE_PARM() Stelian Pop
2004-11-10 16:35       ` Randy.Dunlap
2004-11-10 19:52         ` Stelian Pop
2004-11-10 19:47           ` Randy.Dunlap [this message]
2004-11-10 21:21             ` Stelian Pop
2004-11-13 22:44               ` Dominik Brodowski
2004-11-10 16:01     ` [PATCH] drivers/net/pcmcia: rework debugging Stelian Pop

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41927055.9030306@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=akpm@osdl.org \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.de \
    --cc=stelian@popies.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.