lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200804040909.28983.rusty@rustcorp.com.au>
Date:	Fri, 4 Apr 2008 09:09:28 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Randy Dunlap <randy.dunlap@...cle.com>
Cc:	Tom Horsley <tom.horsley@...r.com>, linux-kernel@...r.kernel.org
Subject: Re: module parameters versus kernel command line

On Friday 04 April 2008 02:14:44 Randy Dunlap wrote:
> On Thu, 3 Apr 2008 12:04:25 -0400 Tom Horsley wrote:
> > I know that part, I'm just wondering if it would be nice to have
> > even dynamically loaded modules notice the kernel option
> > so that the "usbcore" module would see the "blinkenlights=1"
> > parameter from the kernel boot options when dynamically loaded?
> >
> > That way, you wouldn't have to stop and figure out if a module
> > was static or dynamic to decide if you need to edit the grub boot
> > line or the modprobe.conf file.
>
> OK, that makes some sense to me.
>
> Rusty added to cc for his objective viewpoint.

I agree with Randy; it has some appeal, but it's not a killer feature.

We already do the reverse: sysfs exposed parameters are the same for modules 
and builtins.  If they're modifiable (most aren't), you don't have to care 
whether it's a module or not.

But there are also minor downsides.  The first is that we currently warn about 
unused parameters (at least those containing '.').  We'd have to come up with 
something cleverer if we want to warn only about parameters which cannot be 
used by modules (ie. do it in userspace).

The second is that users might be surprised when they take 
the 'usbcore.blinkenlights' line out of their modprobe config file and it 
still applies.  Most users use everything-is-a-module distributions.

Finally, it would be logical to take all the module parameters and autogen 
them into the kernel commandline, but it will soon hit cmdline limits (hmm, 
actually on my Ubuntu Hardy system here I think I'd be OK).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ