* RFC: Harmonised parameter passing
@ 2005-03-08 14:59 Henk Vergonet
2005-03-08 15:14 ` Dmitry Torokhov
0 siblings, 1 reply; 4+ messages in thread
From: Henk Vergonet @ 2005-03-08 14:59 UTC (permalink / raw)
To: linux-kernel
Hi,
The current method of parameter passing to drivers build as a module is extremely usefull.
Modules don't have to write there own parsing code, there's a nice macro that can be used to document specifics of the parameter and so on.
Could we extend this method where we use the same methodology for inbound drivers? (Currently a lot of drivers use their own parameter parsing code when it comes to passing values at kernel boot time.)
so we could do the regular:
insmod mcd io=0x340
for modules, or with kernel boot parameters:
mcd.io=0x340
for in-kernel drivers.
My proposal would be to introduce something like:
DRIVER_PARM_DESC(variable, description);
DRIVER_PARM(variable, type, scope);
where scope can be:
PARM_SCOPE_MODULE => This parameter is used in module context.
PARM_SCOPE_KERNEL => This parameter is used in kernel context.
PARM_SCOPE_MODULE | PARM_SCOPE_KERNEL
=> This parameter is used in both kernel and module context, which should be the default if scope is omitted.
What do you think?
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: RFC: Harmonised parameter passing
2005-03-08 14:59 RFC: Harmonised parameter passing Henk Vergonet
@ 2005-03-08 15:14 ` Dmitry Torokhov
2005-03-08 15:47 ` Henk Vergonet
0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Torokhov @ 2005-03-08 15:14 UTC (permalink / raw)
To: Henk Vergonet; +Cc: linux-kernel
On Tue, 8 Mar 2005 15:59:23 +0100, Henk Vergonet
<rememberme@god.dyndns.org> wrote:
>
> Hi,
>
> The current method of parameter passing to drivers build as a module is extremely usefull.
> Modules don't have to write there own parsing code, there's a nice macro that can be used to document specifics of the parameter and so on.
>
> Could we extend this method where we use the same methodology for inbound drivers? (Currently a lot of drivers use their own parameter parsing code when it comes to passing values at kernel boot time.)
>
> so we could do the regular:
>
> insmod mcd io=0x340
>
> for modules, or with kernel boot parameters:
>
> mcd.io=0x340
>
> for in-kernel drivers.
>
Umm.. This is already done. For parameters defined with module_param()
you use <paramname>=<value> for modules and
<modulename>.<paramname>=<value> for built-in case.
> My proposal would be to introduce something like:
>
> DRIVER_PARM_DESC(variable, description);
> DRIVER_PARM(variable, type, scope);
>
> where scope can be:
> PARM_SCOPE_MODULE => This parameter is used in module context.
> PARM_SCOPE_KERNEL => This parameter is used in kernel context.
> PARM_SCOPE_MODULE | PARM_SCOPE_KERNEL
> => This parameter is used in both kernel and module context, which should be the default if scope is omitted.
>
Why would you want parameters that only work for modules? I'd consider
it a bug, not a feature, when parameter works only when code is
modularized.
--
Dmitry
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Harmonised parameter passing
2005-03-08 15:14 ` Dmitry Torokhov
@ 2005-03-08 15:47 ` Henk Vergonet
2005-03-08 15:58 ` Dmitry Torokhov
0 siblings, 1 reply; 4+ messages in thread
From: Henk Vergonet @ 2005-03-08 15:47 UTC (permalink / raw)
To: linux-kernel; +Cc: dtor_core
On Tue, Mar 08, 2005 at 10:14:32AM -0500, Dmitry Torokhov wrote:
> On Tue, 8 Mar 2005 15:59:23 +0100, Henk Vergonet
> > Could we extend this method where we use the same methodology for inbound drivers? (Currently a lot of drivers use their own parameter parsing code when it comes to passing values at kernel boot time.)
> >
> > so we could do the regular:
> >
> > insmod mcd io=0x340
> >
> > for modules, or with kernel boot parameters:
> >
> > mcd.io=0x340
> >
> > for in-kernel drivers.
> >
>
> Umm.. This is already done. For parameters defined with module_param()
> you use <paramname>=<value> for modules and
> <modulename>.<paramname>=<value> for built-in case.
I did not know, but thats good news! My research was only based on the LKM module howto.
> > My proposal would be to introduce something like:
> >
> > DRIVER_PARM_DESC(variable, description);
> > DRIVER_PARM(variable, type, scope);
> >
> > where scope can be:
> > PARM_SCOPE_MODULE => This parameter is used in module context.
> > PARM_SCOPE_KERNEL => This parameter is used in kernel context.
> > PARM_SCOPE_MODULE | PARM_SCOPE_KERNEL
> > => This parameter is used in both kernel and module context, which should be the default if scope is omitted.
> >
>
> Why would you want parameters that only work for modules? I'd consider
> it a bug, not a feature, when parameter works only when code is
> modularized.
>
I totally agree! (But I was preparing for the discussion were people
argue that they need a different set of parameters at boot time.)
One question remains though, how do you handle the initialization of
multiple instances of an inbound driver?
mcd0.io=0x340 mcd1.io=0x350
Thnx,
Henk
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: RFC: Harmonised parameter passing
2005-03-08 15:47 ` Henk Vergonet
@ 2005-03-08 15:58 ` Dmitry Torokhov
0 siblings, 0 replies; 4+ messages in thread
From: Dmitry Torokhov @ 2005-03-08 15:58 UTC (permalink / raw)
To: Henk Vergonet; +Cc: linux-kernel
On Tue, 8 Mar 2005 16:47:47 +0100, Henk Vergonet
<rememberme@god.dyndns.org> wrote:
> One question remains though, how do you handle the initialization of
> multiple instances of an inbound driver?
>
> mcd0.io=0x340 mcd1.io=0x350
>
I think the most common practice is to specify a list of addresses:
mcd.io=0x340,0x350
module_param_array() helps here.
--
Dmitry
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-03-08 15:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-08 14:59 RFC: Harmonised parameter passing Henk Vergonet
2005-03-08 15:14 ` Dmitry Torokhov
2005-03-08 15:47 ` Henk Vergonet
2005-03-08 15:58 ` Dmitry Torokhov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox