[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15e467334b2162728de22d393860d7c01e26ea97.camel@sipsolutions.net>
Date: Wed, 02 Jun 2021 09:38:15 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>,
Loic Poulain <loic.poulain@...aro.org>
Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
m.chetan.kumar@...el.com
Subject: Re: [RFC 3/4] wwan: add interface creation support
Hi Sergey,
> Wow, this is a perfect solution! I just could not help but praise this
> proposal :)
Heh.
> When researching the latest WWAN device drivers and related
> discussions, I began to assume that implementing the netdev management
> API without the dummy (no-op) netdev is only possible using genetlink.
> But this usage of a regular device specified by its name as a parent
> for netdev creation is so natural and clear that I believe in RTNL
> again.
>
> Let me place my 2 cents. Maybe the parent device attribute should be
> made generic? E.g. call it IFLA_PARENT_DEV_NAME, with usage semantics
> similar to the IFLA_LINK attribute for VLAN interfaces. The case when
> a user needs to create a netdev on behalf of a regular device is not
> WWAN specific, IMHO. So, other drivers could benefit from such
> attribute too. To be honest, I can not recall any driver that could
> immediately start using such attribute, but the situation with the
> need for such attribute seems to be quite common.
That's a good question/thought.
I mean, in principle this is trivial, right? Just add a
IFLA_PARENT_DEV_NAME like you say, and use it instead of
IFLA_WWAN_DEV_NAME.
It'd come out of tb[] instead of data[] and in this case would remove
the need to add the additional data[] argument to rtnl_create_link() in
my patch, since it's in tb[] then.
The only thing I'd be worried about is that different implementations
use it for different meanings, but I guess that's not that big a deal?
johannes
Powered by blists - more mailing lists