[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081024210128.GS7331@solarflare.com>
Date: Fri, 24 Oct 2008 22:01:30 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: Brice Goglin <brice@...i.com>, netdev@...r.kernel.org
Subject: Re: [RFC] per-nic module parameters
Stephen Hemminger wrote:
> On Fri, 24 Oct 2008 22:09:35 +0200
> Brice Goglin <brice@...i.com> wrote:
>
> > Hello,
> >
> > We're working on making myri10ge module parameters per-nic. It looks
> > like ixgb already does so with the following macro in ixgb_param.c:
> >
> > #define IXGB_PARAM_INIT { [0 ... IXGB_MAX_NIC] = OPTION_UNSET }
> > #define IXGB_PARAM(X, desc) \
> > static int __devinitdata X[IXGB_MAX_NIC+1] \
> > = IXGB_PARAM_INIT; \
> > static unsigned int num_##X = 0; \
> > module_param_array_named(X, X, int, &num_##X, 0); \
> > MODULE_PARM_DESC(X, desc);
> >
> > Is this the recommended way to implement per-nic module params? Or
> > should we do something else?
>
> Module parameters are bad. They are device specific and awkward for
> any general configuration system to deal with. As much as possible,
> please convert any module parameters to real interfaces like netlink,
> ethtool, or sysfs.
I agree in principle. However, every distribution uses modutils and allows
default module parameters to be set in the same way. So it's easy to tell
customers how to configure module parameters persistently. The same cannot
be said for ethtool, unfortunately.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists