From: Johannes Berg <johannes@sipsolutions.net>
To: Sergey Ryazanov <ryazanov.s.a@gmail.com>,
Loic Poulain <loic.poulain@linaro.org>
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
m.chetan.kumar@intel.com
Subject: Re: [RFC 3/4] wwan: add interface creation support
Date: Wed, 02 Jun 2021 09:38:15 +0200 [thread overview]
Message-ID: <15e467334b2162728de22d393860d7c01e26ea97.camel@sipsolutions.net> (raw)
In-Reply-To: <CAHNKnsRv3r=Y7fTR-kUNVXyqeKiugXwAmzryBPvwYpxgjgBeBA@mail.gmail.com> (sfid-20210602_034254_098035_0151122C)
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
next prev parent reply other threads:[~2021-06-02 7:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-01 8:05 [RFC 0/4] wwan framework netdev creation Johannes Berg
2021-06-01 8:05 ` [RFC 1/4] iosm: fix stats and RCU bugs in RX Johannes Berg
2021-06-01 8:05 ` [RFC 2/4] rtnetlink: add alloc() method to rtnl_link_ops Johannes Berg
2021-06-01 8:05 ` [RFC 3/4] wwan: add interface creation support Johannes Berg
2021-06-01 9:37 ` Loic Poulain
2021-06-01 10:35 ` Johannes Berg
2021-06-02 6:52 ` Loic Poulain
2021-06-02 8:29 ` Johannes Berg
2021-06-03 7:00 ` Loic Poulain
2021-06-03 7:02 ` Kumar, M Chetan
2021-06-02 1:42 ` Sergey Ryazanov
2021-06-02 7:38 ` Johannes Berg [this message]
2021-06-02 12:45 ` Sergey Ryazanov
2021-06-02 12:56 ` Johannes Berg
2021-06-02 15:38 ` Sergey Ryazanov
2021-06-01 8:05 ` [RFC 4/4] iosm: convert to generic wwan ops Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15e467334b2162728de22d393860d7c01e26ea97.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=loic.poulain@linaro.org \
--cc=m.chetan.kumar@intel.com \
--cc=netdev@vger.kernel.org \
--cc=ryazanov.s.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.