linux-kernel - Re: [PATCH] Delegate unknown module parameters to interested parties

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]

Date:	Thu, 11 Nov 2010 11:05:08 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Chris Wilson <chris@...is-wilson.co.uk>,
	Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
	linux-kernel@...r.kernel.org, fweisbec@...il.com, mingo@...hat.com
Subject: Re: [PATCH] Delegate unknown module parameters to interested parties

On Thu, 11 Nov 2010 12:26:00 am Steven Rostedt wrote:
> On Wed, 2010-11-10 at 16:21 +1030, Rusty Russell wrote:
> > On Wed, 10 Nov 2010 01:09:21 am Steven Rostedt wrote:
> > > [ Added Rusty "Module God" Russell ]
> > 
> > And I also wrote the parameter parsing code, so sending to me is probably
> > a good idea.
> > 
> > So, what's this for?  You want trace= as a standard module parameter
> 
> Yep, this way we could even enable tracepoints that are in the init
> section.

*Exactly* how would it be used though?  Please provide a synopsis for
someone unaware of what tracing does these days?

Because we could compile an extra module_parm() into the module using
modpost, for example, at a cost of an extra 16/32 bytes per module.

> But, personally, I like the generic addition. Perhaps others will hook into
> it without fear of having to hack the module code, which can be quite
> intimidating to some.

We *all* want to build infrastructure; when other coders are forced to use
it we rise up the kernel dominance hierarchy. Ook ook!  (Every Unix app has
its own config language for the same reason: the author distils the mental
sweat of the users into some kind of Elixer of Coder Hubris).

Yet abstractions obfuscate: let's resist our primal urges to add another
speed hump on the lengthening road to kernel expertese.

And this one's classicly easy: in single uses cases we always get the
infrastructure wrong for future users anyway, so let's not do it until
we have more than one user.

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/