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

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2010-11-11 at 11:05 +1030, Rusty Russell wrote:
>  
> > 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?

Well, if you have a tracepoint in the module, and you want to enable it
as soon as the module is loaded, it would be nice to have that ability.

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

Note, I would have just done the hack, but I liked Chris's generic
approach. /me ook ooks Chris!


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

Adding a generic way to do global module options is a primal urge?

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

OK, we can add the hack for now. But perhaps have an archive of this
patch (maybe even sneak a link to it in the change log).

Hmm, we can just add:

LKML-Reference: <1289311867-10096-1-git-send-email-chris@chris-wilson.co.uk>


-- Steve