[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56C2140D.9090708@brocade.com>
Date: Mon, 15 Feb 2016 18:08:13 +0000
From: Robert Shearman <rshearma@...cade.com>
To: Jiri Benc <jbenc@...hat.com>
CC: <davem@...emloft.net>, <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Tom Herbert <tom@...bertland.com>, Thomas Graf <tgraf@...g.ch>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH net-next 1/3] lwtunnel: autoload of lwt modules
On 15/02/16 16:32, Jiri Benc wrote:
> On Mon, 15 Feb 2016 16:22:08 +0000, Robert Shearman wrote:
>> Yeah, it's the C preprocessor. MODULE_ALIAS_RTNL_LWT includes the string
>> for the encap type in the module alias, and since the LWT encap types
>> are defined as enums this is symbolic name. I can't see any way of
>> getting the preprocessor to convert
>> MODULE_ALIAS_RTNL_LWT(LWTUNNEL_ENCAP_MPLS) into "rtnl-lwt-MPLS", but I'm
>> open to suggestions.
>
> MODULE_ALIAS_RTNL_LWT(MPLS)?
>
> But whatever, as I said, no strong preference.
I was so hung up on the making the string match the name of the enum
that I'd discounted that, but you're right that doing that would reduce
duplication in the alias string.
>> True, but I figured that it was cleaner for the lwtunnel infra to not
>> assume whether how those modules are implemented. If you disagree, then
>> I can change to doing as you suggest.
>
> It's not completely transparent to the infrastructure anyway, the
> tunnel type needs to be added to lwtunnel_encap_str for new tunnels.
> The way I suggested, it's only added for those tunnels having the
> module alias set.
>
> Just trying to get rid of the unnecessary strings in
> lwtunnel_encap_str. There's no need to bloat kernel with them if
> they're never used.
Ok, will resubmit without the unnecessary strings in that function as
well as with your suggestion above.
Thanks for the review,
Rob
Powered by blists - more mailing lists