From: Jakub Kicinski <kuba@kernel.org>
To: Ian Wienand <iwienand@redhat.com>
Cc: netdev@vger.kernel.org, "David S . Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, Tom Gundersen <teg@jklm.no>,
David Herrmann <dh.herrmann@gmail.com>
Subject: Re: [PATCH v2] net/ethernet : set default assignment identifier to NET_NAME_ENUM
Date: Tue, 5 Apr 2022 20:47:58 -0700 [thread overview]
Message-ID: <20220405204758.3ebfa82d@kernel.org> (raw)
In-Reply-To: <YkzzYxn0/04JT6Yv@fedora19.localdomain>
On Wed, 6 Apr 2022 11:56:51 +1000 Ian Wienand wrote:
> Thanks for review
>
> On Tue, Apr 05, 2022 at 12:41:03PM -0700, Jakub Kicinski wrote:
> > Can you spell out how netfront gets a different type to virtio?
> > I see alloc_etherdev_mq() in both cases.
>
> Yeah I've been doing further testing to narrow this down, and I think
> I've been confused by the renaming happening during the initrd steps.
>
> It seems that renamed devices (no matter what the driver) will have
> their name_assign_type set to NET_NAME_USER; which [1] gives away as
> coming from the rtnl_newlink path. virtio devices were renamed in
> init phase in my testing environment, which is why
> /sys/class/net/<iface>/net_name_type works for them by the time
> interactive login starts -- not because they explicitly flag
> themselves. Sorry for not recognising that earlier.
>
> > This worries me. Why is UNKNOWN and ENUM treated differently?
> > Can you point me to the code which pays attention to the assign type?
>
> Yeah, I'll have to retract that claim; it remains unclear to me why
> CentOS 8-stream does not rename netfront devices (systemd 239) and
> CentOS 9-stream does (systemd 249).
>
> systemd only seems to use NET_NAME_ENUM in an informational way to
> print a warning when you're using a .link file to set network info for
> a device that might change names [2].
>
> Perhaps this still has some utility in making that warning more
> useful?
Okay, all good then. I was worried some user space is refusing to
rename UNKNOWN. I have no objection to changing UNKNOWN -> ENUM.
We just need the commit message to be updated.
next prev parent reply other threads:[~2022-04-06 16:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 0:15 [PATCH v2] net/ethernet : set default assignment identifier to NET_NAME_ENUM Ian Wienand
2022-04-05 19:41 ` Jakub Kicinski
2022-04-06 1:56 ` Ian Wienand
2022-04-06 3:47 ` Jakub Kicinski [this message]
2022-04-06 9:36 ` [PATCH v3] " Ian Wienand
2022-04-07 5:08 ` Jakub Kicinski
2022-04-08 4:10 ` patchwork-bot+netdevbpf
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=20220405204758.3ebfa82d@kernel.org \
--to=kuba@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dh.herrmann@gmail.com \
--cc=iwienand@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=teg@jklm.no \
/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.